Evil bug in KDE's mimetype/applnk handling

[David Faure]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 01 December 2002 17:02, Matthias Welwarsky wrote:
> However, if the desktop file contains the name of the 
> service, why not take this entry instead of the filename? Of course, this is 
> still not unique.
... which is why it wouldn't help at all.

> In Arts, every component has a .mcopclass file. Plus there's a trader service 
> you can ask for a component that implements a certain interface, supports a 
> certain mimetype, can handle file with a certain extension and so on. KTrader 
> is something similar, but only for KParts, afaik, not for applications. 
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.

> Basically, for the KDE Desktop you need two things:
> a) an application/component that can handle a certain mimetype.
> You need this every time the user clicks on a document of a specific mimetype.
More than "one" application/component, in fact, but the whole sorted list,
for the "Open With" submenu. KTrader delivers this.

> 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.

> 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.
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.

> The name of  the component is _not_ relevant.
I don't agree. Mozilla != Konqueror. Mutt != KMail. etc.

> 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.

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
Get the latest KOffice - http://download.kde.org/stable/koffice-1.2/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE960IM72KcVAmwbhARAjCwAJwJ9/Z8vyo83Y//IEbiuLcbMQ3S+wCgoQJL
1bIGtFDyvFmWmbesWXEFvZo=
=JLXu
-----END PGP SIGNATURE-----