Evil bug in KDE's mimetype/applnk handling

[Waldo Bastian]

On Saturday 30 November 2002 11:20, Matthias Welwarsky wrote:
> Hi,
>
> Just stumbled over an ugly bug in KDE's application launcher. A user can
> make his/her desktop unusable with some simple mouseclicks that are
> alltogether completely rational.
>
> Easy to reproduce: Take a random file on your desktop, I have some ZIP
> files lying around there, RMB->Edit File Type, and assign "konqueror" as
> the primary application link. Not a bad idea all in all, konqueror can
> handle ZIP files through the zip:// ioslave quite nicely.
>
> Then click on the Browser icon in kicker - oops, nothing happens any more.
>
> Tracked the problem down to kfmclients openProfile method, which tries to
> start konqueror through
> KApplication::startServiceByDesktopPath("konqueror.desktop").
>
> Now, unfortunately, by assigning konqueror to application/x-zip, you
> created a $KDEHOME/share/applnk/konqueror.desktop, which KLauncher picks up
> happily.

> So, where's the bug? I'm not sure which component it should be assigned to.
> To me, it seems wrong that KLauncher picks up a file under applnk when
> explicitely asked to start a service. Others may say the the applnk concept
> is wrong and that mimetype->application links should be stored in the
> mimetype files...
>
> Any opinions?

applnk and services share the same namespace so creating a konqueror.desktop 
applnk if there is already a konqueror.desktop service is a bad idea. Either 
it should use another name for the applnk file, or it should modify the 
konqueror.desktop service instead of creating a new one under applnk.

Cheers,
Waldo
-- 
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com