Evil bug in KDE's mimetype/applnk handling

[Matthias Welwarsky]

On Monday 02 December 2002 12:20, David Faure wrote:
> On Sunday 01 December 2002 17:02, Matthias Welwarsky wrote:

> Huh? With KTrader you can ask for an application that implements a given
> servicetype, whether that's a general "interface" or a mimetype.
> Files with a certain extension are mapped to mimetypes first, so that is
> covered too, of course.
> I admit that we haven't been using much the idea of (non-mimetype)
> servicetypes for applications (except in KOffice), but KTrader definitely
> supports it.

Cool :) So, what's the purpose of KService in that scenario? I could use 
KTrader for very much the same thing, if I understand you correctly.

> > b) an application/component that offers a certain service.
> > You need this every time the user clicks on an icon in kicker, because he
> > wants to start a browser application, a mail application, a picture
> > viewer.
>
> I don't agree here. If I click on Mozilla in kicker, I don't want Konqueror
> to start because it "is my preferred browser applications. Kicker icons
> point to actual applications, NOT to type of services. Otherwise you'd have
> no way of starting two different applications that offer the same type of
> service.

Ok, ok. Then I need a third index in the database so that I can query for the 
actual name of the application, too.

> > While the applications that handle the users request are probably the
> > same in a) and b), the approach is different.
> >
> > To fulfill this, you only need one database that contains every
> > component, with the service it implements, plus the mimetypes it can
> > handle, if any. But it needs to be double-indexed, once by mimetype, once
> > by service.
>
> And how does the "by service" index reference the services?
> That's where you need a way to identify a service.

Hm? A service is an abstract idea. It may be implemented in various 
applications. I query the database for "Webbrowser" and get a list of 
applications that implement this service. I choose my preferred application 
and the database tells me how to start it.

The .desktop file (and thus the database entry) would look like this:

service=webbrowser
application=konqueror
exec=kfmclient openProfile webbrowsing
mimetype=text/html,image/jpeg,image/gif

I can query for "service=webbrowser" or "application=konqueror", doesn't 
matter, and the trader returns all information I need to start the 
application.

You could also have a second .desktop file, that differs only in the mimetype, 
and the database would collapse both into one entry.

I admit that I need a way to start a specific application, too, but I deny 
that using the name of the .desktop file is advisable here.

> The desktopEntryPath() is almost unique enough (except for services/foo vs
> applnk/foo), but using this relies on the layout of the K menu, which is a
> very bad idea, as the past has shown. Looking by .desktop filename is the
> only solution here, but it indeed relies on no duplicates inside the
> services/ and applnk/ subtrees, hence the kopenwith patch.

You have no influence what users do with the filesystem, and you have no 
control over third party applications that install arbitrary files into 
$KDEHOME. That's why your patch does not fix the problem in general, and 
that's also why I generally dislike the idea of relying on the filename of a 
.desktop file.

The database would collect all the information from the .desktop file. You 
need to have a strategy to handle collisions. A collision occurs when you 
have the same "application" in two desktop files, with different "exec" 
properties, but that's not really a problem. You can store both entries and 
warn the user about a collision if the trader returns more than one offer for 
an application. You can offer to remove one of the choices permanently, or 
store a preference.

> > KSycoca is the database, all we need is proper access methods. They
> > really don't exist yet?
>
> They do. But it would be nonsense to use a trader query when starting a
> particular application from kicker.

You do, already, via KService. That's pretty much a trader.

regards,
	matze

-- 
Matthias Welwarsky
Fachschaft Informatik FH Darmstadt
Email: matze at stud.fbi.fh-darmstadt.de

"all software sucks equally, but some software is more equal"