Evil bug in KDE's mimetype/applnk handling
matze at stud.fbi.fh-darmstadt.de
Sun Dec 1 16:02:31 GMT 2002
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
>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
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?
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