CVS dane: * fvwm-menu-desktop.in: fix usage.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: dane12/06/29 19:45:59 Modified files: bin: Tag: branch-2_6 ChangeLog fvwm-menu-desktop.in modules: Tag: branch-2_6 ChangeLog modules/FvwmForm: Tag: branch-2_6 FvwmForm-Desktop Log message: * fvwm-menu-desktop.in: fix usage. * FvwmForm/FvwmForm-Desktop: Support --with-titles, --size, --theme.
CVS dane: * fvwm-menu-desktop.in: fix usage.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: dane12/06/29 19:45:59 Modified files: bin: Tag: branch-2_6 ChangeLog fvwm-menu-desktop.in modules: Tag: branch-2_6 ChangeLog modules/FvwmForm: Tag: branch-2_6 FvwmForm-Desktop Log message: * fvwm-menu-desktop.in: fix usage. * FvwmForm/FvwmForm-Desktop: Support --with-titles, --size, --theme.
Re: [Patch] fvwm-menu-desktop improvements
Thomas Funk writes:
(Please on replies to fvwm-workers,
assume everyone is subscribed and just reply to fvwm-workers.)
> 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 ...
Exactly. The only issue the XDG spec addresses is "applications".
That's one of the things I say is "faulty".
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 ...
Checking for the distro default should be obvious.
That's the plain "applications.menu" file.
(The one without a prefix.)
I'm just using common sense though, I don't see that in the XDG spec.
--
Dan Espen
Re: [Patch] fvwm-menu-desktop improvements
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
Re: [Patch] fvwm-menu-desktop improvements
On Fri, Jun 29, 2012 at 10:17:23PM +0200, Thomas Funk wrote:
> "Dan Espen" wrote:
> >Still giving the whole issue some thought.
> >Still seems to me like:
> >
> >The XDG spec is faulty. It treats xxx-applications like a special
> >case, but completely ignores any other root menu.
> 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.
> >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.
> >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.
> Extract from Desktop Menu Specification V1.0
> File locations
> $XDG_CONFIG_DIRS/menus/${XDG_MENU_PREFIX}applications.menu
> :
> Systems that offer multiple desktop environments and that want to use
> distinct menu layouts in the different environments can use differently
> prefixed .menu files. In this case the $XDG_MENU_PREFIX environment
> variable must be set by the system to reflect the .menu file that is
> being used.
>
> 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.
> >I see that Gentoo claims to have a gnome-applications.menu.
> On my Debian system there's also a gnome-applications.menu in
> $HOME/.config/menus/ Therefore I've implemented in my fvwm-xdg-menu the
> mtime check. That works on my system, but on a Xubuntu system from a
> friend of mine the xfce-settings.menu was found because this menu was
> changed as the last one ... so you see, not really practicable...
Anything based on mtime is flawed. Don't use it. Seriously.
> >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.
> @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.
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Re: [Patch] fvwm-menu-desktop improvements
"Dan Espen" wrote:
>Still giving the whole issue some thought.
>Still seems to me like:
>
>The XDG spec is faulty. It treats xxx-applications like a special
>case, but completely ignores any other root menu.
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.
>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.
>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
Extract from Desktop Menu Specification V1.0
File locations
$XDG_CONFIG_DIRS/menus/${XDG_MENU_PREFIX}applications.menu
:
Systems that offer multiple desktop environments and that want to use
distinct menu layouts in the different environments can use differently
prefixed .menu files. In this case the $XDG_MENU_PREFIX environment
variable must be set by the system to reflect the .menu file that is
being used.
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.
>I see that Gentoo claims to have a gnome-applications.menu.
On my Debian system there's also a gnome-applications.menu in
$HOME/.config/menus/ Therefore I've implemented in my fvwm-xdg-menu the
mtime check. That works on my system, but on a Xubuntu system from a
friend of mine the xfce-settings.menu was found because this menu was
changed as the last one ... so you see, not really practicable...
>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
@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.
Thomas
Re: [Patch] fvwm-menu-desktop improvements
Thomas Funk writes: > "Dan Espen" wrote: >>Seems to me, the best way fvwm can interface with this mess >>is to just treat the whole name as one thing. > > What about this: > we rename > --desktop to --menu-prefix > --menu-type to --menu-name > > In the help the following is written: > --menu-prefix PREFIX Menu prefix following the xdg standard like: > gnome-, kde4-, xfce-, lxde-, debian-, > etc. Default is empty > --menu-name NAME applications (default), settings, > preferences, etc. > For non xdg compliant menus the complete > name should use > without the trailing '.menu' e.g. > 'applications-gnome' or 'gnomecc' > > What do you thinking? Could this a compromise? Still giving the whole issue some thought. Still seems to me like: The XDG spec is faulty. It treats xxx-applications like a special case, but completely ignores any other root menu. Shouldn't there be a xxx-settings.menu and a xxx-documentation menu? If there were, the menu prefix would make sense. Maybe no prefix for the distro default, and xxx- prefixes for each desktop package. I see that Gentoo claims to have a gnome-applications.menu. Maybe what I'm seeing in Fedora is just a Fedora issue. Might be time to subscribe to the xdg list. This might take a while... -- Dan Espen
Re: [Patch] fvwm-menu-desktop improvements
On 29 June 2012 16:34, Thomas Funk wrote: > "Dan Espen" wrote: >>Seems to me, the best way fvwm can interface with this mess >>is to just treat the whole name as one thing. > > What about this: > we rename > --desktop to --menu-prefix > --menu-type to --menu-name I don't really care, except that: > In the help the following is written: > --menu-prefix PREFIX Menu prefix following the xdg standard like: > gnome-, kde4-, xfce-, lxde-, debian-, ...this has to state that it would override whatever XDG_MENU_PREFIX might be set to. -- Thomas Adam
Re: [Patch] fvwm-menu-desktop improvements
"Dan Espen" wrote: >Seems to me, the best way fvwm can interface with this mess >is to just treat the whole name as one thing. What about this: we rename --desktop to --menu-prefix --menu-type to --menu-name In the help the following is written: --menu-prefix PREFIX Menu prefix following the xdg standard like: gnome-, kde4-, xfce-, lxde-, debian-, etc. Default is empty --menu-name NAME applications (default), settings, preferences, etc. For non xdg compliant menus the complete name should use without the trailing '.menu' e.g. 'applications-gnome' or 'gnomecc' What do you thinking? Could this a compromise? Thomas
