Proposal: Menu Spec Changes

[Waldo Bastian]

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

On Thursday 24 July 2003 22:57, Havoc Pennington wrote:
> On Thu, Jul 24, 2003 at 10:51:13PM +0200, Waldo Bastian wrote:
> > > We really need a test suite to validate our implementations...  I
> > > tried to talk Jeremy White into writing one but he wasn't biting. ;-)
> >
> > Yes. Is your stuff available somewhere?
>
> It's in cvs under desktop-menu, but it's not really very exciting.
> A lame python script plus a small bit of test data.
>
> > I don't see any substantial benefit of using it for KDELegacyDir. There
> > will be namespace issues during transition but I don't think a prefix
> > will be the right solution to fix it. Part of my hesitation comes from
> > the fact that I think it would be ok if actual KDE applications would be
> > prefixed with "kde" but it makes no sense to have third party apps such
> > as realplayer be prefixed with "kde" just because they happen to install
> > themselves to
> > $KDEDIR/share/applnk. In fact that would just prolong the pains of a
> > transition because the next time realplayer installs under
> > .../applications, it suddenly looses its prefix.
> >
> > As for support for prefix in general, I don't know if there are that many
> > legacy style menus out there, beyond the ones used by GNOME and KDE to
> > warrant the additional complexity.
>
> OK, we can take this out then, it's OK with me.
>
> > Talking about transition, do you have a diff or some other overview of
> > the KDE .desktop files that RedHat renamed?
>
> It's just "if doesn't start with 'kde' prepend 'kde-'", i.e. just
> desktop-file-install doing its thing.
> (desktop-file-install takes a "--vendor kde" argument which then
> gets prepended if the file doesn't already have it)
>
> The same thing is run for all .desktop files in the distribution, just
> with different --vendor arguments. I think we used redhat- for stuff
> from us, and gnome- for GNOME, and net- for random stuff.

Ah, it's all coming back to me now. For some reason I thought you guys had 
only prefixed the trivial ones like mouse.deskop with kde- If you indeed want 
to vigorously use "vendor" prefixes than we do need the prefix for the legacy 
dirs indeed.

Sorry for changing my mind so often :-}

To illustrate, see http://lists.kde.org/?l=kfm-devel&m=105905877309453&w=2
The user there has the following desktop files:
a) $KDEDIR/share/applnk/Graphics/kghostview.desktop
b) $KDEDIR/share/applications/kghostview.desktop
c) $KDEHOME/share/applnk/Graphics/kghostview.desktop

Those .desktop files all refer to the same application and only one of those 
should be actually used. When we now add a prefix when installing to 
.../applications, it would become:
a) $KDEDIR/share/applnk/Graphics/kghostview.desktop
b) $KDEDIR/share/applications/kde-kghostview.desktop
c) $KDEHOME/share/applnk/Graphics/kghostview.desktop

And in order to still recognize these files as refering to the same 
application, we need to inform the LegacyDir about the "kde-" prefix.

So if the concensus is that we indeed want to use vendor prefixes (which has 
merit IMO) then we do need the prefix for LegacyDir, and the prefix for the 
KDELegacyDir would then be "kde-".

I think the spec should provide some guidelines for prefixes as well then.

In addition for that I would like to call for 
$KDEDIR/share/applications/kde/kghostview.desktop
being treated equal to
$KDEDIR/share/applications/kde-kghostview.desktop
as I mentioned in 
https://www.redhat.com/archives/xdg-list/2003-March/msg00085.html

Maybe we can introduce the notion of "desktop-file ID". All .desktop files 
used here as example would then have the same "desktop-file ID", namely 
"kde-kghostview.desktop". And the "desktop-file ID" is what is used in 
<Include> and <Exclude> statements then.

Cheers,
Waldo
- -- 
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/IHQeN4pvrENfboIRAp/LAKCoIwpnt53mS8RCSM+u8u6D1Tj97gCeMZ5r
K20QRSgS2KZOqNeo98SsL68=
=uD/F
-----END PGP SIGNATURE-----