Evil bug in KDE's mimetype/applnk handling
matze at stud.fbi.fh-darmstadt.de
Mon Dec 2 21:04:42 GMT 2002
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
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:
exec=kfmclient openProfile webbrowsing
I can query for "service=webbrowser" or "application=konqueror", doesn't
matter, and the trader returns all information I need to start the
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
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.
Fachschaft Informatik FH Darmstadt
Email: matze at stud.fbi.fh-darmstadt.de
"all software sucks equally, but some software is more equal"
More information about the kde-core-devel