Identifying desktop menu items

[Waldo Bastian]

On Thursday 24 April 2003 06:08, John Firebaugh wrote:
> Hi,
>
> I'm the maintainer of the KDE panel (kicker). I've recently noticed that
> adding support in KDE for the XDG menu specification has caused a
> regression in kicker. Specifically, paths to .desktop files (for example,
> to identify which .desktop file an application launcher button corresponds
> to) are now being stored in configuration files as absolute paths into the
> $prefix/share/applications directory. This is undesired, since we want to
> application launcher button to work even if the prefix changes or a
> personal copy of the .desktop file is created. My question is, what is the
> preferred way to store this information? As paths relative to
> $prefix/share/applications? 

Yes, that's unfortunate indeed. I can't return relative paths for 
$prefix/share/applications by default since relative paths used to be relative to 
$prefix/share/applnk, so code that wouldn't know about $prefix/share/applications 
would break if I returned relative paths for $prefix/share/applications as well, it wouldn't 
know how to find such file.

What might work is if, from a KStandardDirs point of view, I merge $prefix/share/applications
with $prefix/share/applnk. Then I could return relative paths for both. Not sure if that has any
unforeseen consequences.

What you could also do in kicker is to store the name of the desktop file only 
(e.g. "konsole") instead of the relative path (e.g. "System/konsole.desktop")
In fact that is what I did in ContainerArea::defaultContainerConfig, it converts 
"System/konsole.desktop" to "konsole" and then looks that up with 
KService::serviceByDesktopName(desktopName);

You should only do this for files under $prefix/share/applnk or $prefix/share/applications. 
KStandardDirs can tell you whether a file is relative to that with 
KStandardDirs::relativeLocation(...), unfortunately that one doesn't have support for
$prefix/share/applications yet. Will add that.

> What are the legacy compatibility implications
> here? What needs to happen in KDE service type classes to expose this
> information?
>
> -John

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