Evil bug in KDE's mimetype/applnk handling

[David Faure]

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

On Monday 02 December 2002 22:04, Matthias Welwarsky wrote:
> Ok, ok. Then I need a third index in the database so that I can query for the 
> actual name of the application, too.

The name of _one_ application doesn't need an index, KService::name() returns it.
If you meant querying an application by name, that's exactly what you're objecting to
in the first place :)

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

Ok, here's the heart of the misunderstanding. What you call service is what KIO
calls "service type".
The "service type" (e.g. web browser) is the abstract idea, that can be implemented
in various services (applications, or components).
I was assuming you knew the basic concepts/names we were talking about here -
cf http://developer.kde.org/documentation/library/kdeqt/kde3arch/services.html

>I query the database for "Webbrowser" and get a list of 
> applications that implement this service [type]. I choose my preferred application 
> and the database tells me how to start it.
Yes. This is what you want to happen when you enter a URL,
but NOT when you start konqueror from kicker.

> The .desktop file (and thus the database entry) would look like this:
> 
> service=webbrowser
servicetypes=
> application=konqueror
name=
> exec=kfmclient openProfile webbrowsing
> mimetype=text/html,image/jpeg,image/gif
yes.

> 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.
.... but you're not proposing a better solution either.

> You have no influence what users do with the filesystem
The location of things doesn't matter here, only the naming does.

> and you have no 
> control over third party applications that install arbitrary files into 
> $KDEHOME.
They are not allowed to install a konqueror.desktop
Just as they choose binary names that don't collide with KDE binaries,
they won't choose .desktop filenames that collide with the KDE ones.

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

> 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
.. which is exactly what the code in KOpenWith detects.

> 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.
Like the user profile, which stores preferences?

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

You are confusing things here. A KService (i.e. a component or application)
can either be returned by a trader query ("give me an app that handles text/html")
_or_ by direct creation from a .desktop file (like kicker does, since it knows
what's the .desktop file behind each button/menu-entry).

PS: I have fixed the bug that started this thread, now.

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

iD8DBQE96+SQ72KcVAmwbhARApKuAJwOL8O+KKBa7gi5qKi5M57kTVHdJACfVY+Z
8x+RvOXxOIM3esHlRbEGe4I=
=MG9k
-----END PGP SIGNATURE-----