Thomas Adam wrote:
>>On Fri, Jun 29, 2012 at 10:17:23PM +0200, Thomas Funk wrote:
>> No, it's not faulty
>> Extract from Desktop Menu Specification V1.0
>> File locations
>> $XDG_CONFIG_DIRS/menus/${XDG_MENU_PREFIX}applications.menu
>> :
>> Implementations may chose to use .menu files with other names for tasks
>> or menus other than the main application menu. Such usage is not
covered
>> by this specification.
>But we know that distros vary on this. So I think some concensus through
>clarification is needed here.
You're right. But how should we do this? applications.menu,
preferences.menu or settings.menu are individual menus. How can we map
them? With different fvwm-menu-desktop calls? Merge them in one menu?
I think we have to define first which menus are possible available:
- applications.menu
- preferences.menu
- settings.menu
- ... more?
and these all with the ${XDG_MENU_PREFIX} if set ...
>>> Shouldn't there be a xxx-settings.menu and a
>>> xxx-documentation menu?
>> If a distro think it should exist one sure. On my Debian system a
>> gnome-settings.menu and a kde4-information.menu but they are optional.
>> If a user wants them, no prob - should implement it in her/his config.
>>
>> We should give the user the ability to get an applications menu.
>> All others are the users beer. Sure, we should give her/him the
possibility
>> to access these menus and fvwm-menu-desktop do this.
>Yes. I've yet to see *anyone* do this.
Ok, then we have to do it, too ... shit, why is all so complicated ;-)
>>> If there were, the menu prefix would make sense.
>>> Maybe no prefix for the distro default, and
>>> xxx- prefixes for each desktop package.
>> You're right. Normally the ${XDG_MENU_PREFIX} is empty by default.
Only if
>No. It's *likely* to be empty, but I know many people who set this,
myself
>included. Don't make undue assumptions.
I don't set it manually. For a DE it is not a problem - gnome use all menus
with gnome- prefix but what should we do? Fvwm hasn't its own fvwm-xxx.menus
The only thing is to implement {XDG_MENU_PREFIX} in fvwm-menu-desktop.
>> I've checked 7 distros (Debian, Redhat, Ubuntu, Mandriva, Fedora,
>> OpenSuse) with different versions and on all ${XDG_MENU_PREFIX}
isn't set.
>> Therefore fvwm-xdg-menu and fvwm-menu-desktop.in doesn't check it.
>Err, but they should. Gentoo set this. Don't try and be preemptive.
It's
>in the spec that it's honoured. *Honour* it.
If only one DE is installed it is not needed per spec. And that's the
problem
Fvwm doesn't know which DE is installed per default. How will we find
out what is installed? We can check /usr/share/xsessions or the equivalent
of KDE but sometimes more than on .desktop files are installed in these
directories and the ${XDG_MENU_PREFIX} is not set ...
>>> Maybe what I'm seeing in Fedora is just a Fedora issue.
>> Maybe. But I've checked the applications-gnome.menu and
applications.menu
>> under your system (F17 hopefully ^^) and they are 95% identical. So for
>> me I address the question - why this discussion? We create for
95-98% of the
>> distros an application menu. Perhaps for 100. If not, the user have to
>> look deeper in her/his system and the fvwm-menu-desktop help. Then he
>> must change the command and get the menu she/he wants....
>No, they shouldn't care, which means either the menus contravene the XDG
>spec, or we do. We should find out.
Ok, will think about it ...
>> @Thomas:
>>> ...this has to state that it would override whatever XDG_MENU_PREFIX
>>> might be set to.
>> This happens if we implement the $XDG_MENU_PREFIX, yes. But at the
moment
>> we must set this manually to get e.g. a gnome-applications.menu. But
>> normally
>> the applications.menu reflects the most applications installed on a
system.
>Then this is likely broken, and before I release the next FVWM version, I
>will be auditing fvwm-menu-desktop with a fine comb. If you're in doubt,
>ask those who implemented and designed the XDG spec.
>
>I'll give you a month, because after that, I'd like to release the
next FVWM
>version.
Thanks to set me a time limit ...
Will give my best ... as ever ...
Thomas
