Evil bug in KDE's mimetype/applnk handling

[Matthias Welwarsky]

On Sunday 01 December 2002 00:09, Waldo Bastian wrote:
> On Saturday 30 November 2002 17:47, Matthias Welwarsky wrote:
> > The concept of adressing a service by the
> > name of its desktop file looks flawed to me.
>
> You need a unique property to identify a service. I think using the desktop
> name for that is better than for example having to use something like
> "method:000000115f6765745f5f666c6f7753797374656d0000000011417274733a3a466c6
>f7753797374656d00000000020000000000000000" (method identifier used by arts)

Yes, but obviously a filename within "$KDEDIRS" is not at all unique, so this 
is a bad choice. 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.

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. 
However, the name of the .mcopclass file means nothing to the Arts' trading 
service.

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.

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.

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. The name of 
the component is _not_ relevant.

KSycoca is the database, all we need is proper access methods. They really 
don't exist yet?

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"