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
Re: [Patch] fvwm-menu-desktop improvements
"Dan Espen" wrote:
>I see:
>File locations
>Files involved in this specification are located according to the
>"desktop base directory specification".
>
>Here are the files defined by this specification:
>$XDG_CONFIG_DIRS/menus/${XDG_MENU_PREFIX}applications.menu
>
>But on my Fedora system, I have
>/etc/xdg/menus/applications-gnome.menu
>
>Which is part of the gnome-menus-3.2.0.1-1.fc16.i686
>package. Looks like it doesn't care about that rule.
>
>Then there are all the other menus in the xdg/menus area.
>They don't end in "applications" either.
These are optional menus. The main menu is applications.menu
>I mean, I see it in the xdg spec and I see what you'd like to do with
>accessing "applications". But I don't see how this fits with the
>other xdg menus we might want to access which don't have rules like this.
fvwm-menu-desktop is absolutely xdg compliant
--desktop fits ${XDG_MENU_PREFIX} like gnome-, kde4-, xfce-, lxde-
--menu-type specifies the type like applications, preferences, settings
and for non compliant menus all other named stuff ...
And we can map *ALL* menus - compliant and non compliant ones:
applications-gnome.menu
--menu-type=applications-gnome
applications.menu
*standard* (no parameter needs to set)
documentation.menu
--menu-type=documentation
gnomecc.menu
--menu-type=gnomecc
kde4-applications.menu
--desktop=kde4(-)
kde-information.menu
--desktop=kde(-) --menu-type=information
preferences.menu
--menu-type=preferences
server-settings.menu
--desktop=server(-) --menu-type=settings OR
--menu-type=server-settings
settings.menu
--menu-type=settings --title=FvwmSettings
start-here.menu
--desktop=start(-) --menu-type=here OR
--menu-type=start-here
system-settings.menu
--desktop=system(-) --menu-type=settings
applications-gnome.menu
--desktop=applications(-) --menu-type=gnome
kde4-applications.menu
--desktop=kde4(-)
Okay, it's not nice how the parameters are misused but menus like
applications-gnome.menu are poor also. And they doesn't follow the xdg spec.
>Not happy with the whole scheme.
>Convince me not to dump it.
What we can do is to rename the parameters like
--desktop -> --menu-prefix
--menu-type -> --menu-postfix
>Seems to me, the best way fvwm can interface with this mess
>is to just treat the whole name as one thing.
To merge --desktop and --menu-type to e.g --menu-name would anul the
xdg automatism.
All systems that I've analyzed has an applications.menu (except Debian)
and they use mostly a {gnome,kde4,kde,xfce,lxde,...}-applications.menu
for each installed desktop environment. Also for system wide menus like
preferences, settings: no ${XDG_MENU_PREFIX} infront and if there is a desktop
specific one they added the desktop name (kde4-settings). From that
point of view
all is ok with the implementation in fvwm-menu-desktop (except that we not check
the Env var ${XDG_MENU_PREFIX} as is described in the xdg spec).
The only thing what I would do is, if you prefer the complete prefix as an
argument renaming --desktop to --menu-prefix because --desktop associates
to use a desktop name *without* a trailing '-'
Thomas
Btw about renaming ... we should rename the following parameters for better
understanding:
--size -> --icon-size or --mini-icon-size
--with-titles -> --with-menu-titles
With the last one I am in doubt. It's every time a tightrope walk between
short as possible and a maximum of expressiveness.
Re: [Patch] fvwm-menu-desktop improvements
Dan Espen wrote: >I had some testing issues there. >I don't remember what they were but I got something like > >--desktop gnome- > >to work and left that comment behind. > >Is there an xdg rule that makes '-' special? --desktop with '-' is the $XDG_MENU_PREFIX >Seem to be saying that we should treat the whole name >as one thing. For the users point of view --desktop=gnome is easier to remember than --desktop=gnome- It could happen that the '-' will be forgotten. For that I append it inside fvwm-menu-desktop. My personal preference is --desktop=gnome. But the other part is also ok for me. Thomas Btw. If you decide for 'gnome-' don't forget to add the '-' in the help.
Re: [Patch] fvwm-menu-desktop improvements
Thomas Funk writes: > Dan Espen wrote: > About your comment in fvwm-menu-desktop.in in cvs > #?desktop=a + '-' I had some testing issues there. I don't remember what they were but I got something like --desktop gnome- to work and left that comment behind. Is there an xdg rule that makes '-' special? I have these .menu files on FC 16: applications-gnome.menu applications.menu documentation.menu gnomecc.menu kde4-applications.menu kde-information.menu preferences.menu server-settings.menu settings.menu start-here.menu system-settings.menu These 2: applications-gnome.menu kde4-applications.menu Seem to be saying that we should treat the whole name as one thing. -- Dan Espen
Re: [Patch] fvwm-menu-desktop improvements
Dan Espen wrote:
>Could you redo patch 3 in light of current CVS.
Attached.
>The way checkmenu wipes out it's input,
>the value of "menu" in the abort message is always
>None. Gives me a syntax error.
You're right. Changed it from 'check' to
'install_prefix+desktop+menu_type+".menu ..."'
because check could changed to 'debian-menu.menu' and that could
irritate a user:
--desktop not set and menu-type not set - normally 'applications.menu'
should appear
and not 'debian-menu.menu' ...
About your comment in fvwm-menu-desktop.in in cvs
#?desktop=a + '-'
The '-' is important because if desktop is not empty and the menu name
will be built
then the following happens:
check=install_prefix+desktop+menu_type+'.menu'
check='/etc/xdg/menus/'+'gnome'+'applications'+'.menu'
-> /etc/xdg/menus/gnomeapplications.menu
if the '-' will be inserted into the check string and desktop is empty
this will be built:
/etc/xdg/menus/-applications.menu
-> no applications.menu will be found anymore
I've added a forgotten check - if user wants explicitly build a debian
menu (--desktop=debian)
the menu-type must change:
if desktop == 'debian-':
menu_type = 'menu'
Also, if a user wants a preference, settings or what else menu he/she
must change the
title of the top menu name used by Popup command. I reanimated --title
which was used
in the past for that. Hope these two adds are ok.
>Could you add something to usage for --desktop and --menu-type.
Yep, done ^^
Thomas
--- ../cvs/fvwm/bin/fvwm-menu-desktop.in 2012-06-27 19:41:57.303273477 +0200
+++ fvwm-menu-desktop.in.py 2012-06-27 23:27:55.164621906 +0200
@@ -42,6 +42,7 @@
import os.path
import os
from xdg.DesktopEntry import *
+import fnmatch
def main ():
@@ -81,7 +82,6 @@
'png-icons-path',
'submenu-name-prefix',
'time-limit',
- 'title',
'tran-icons-path',
'tran-mini-icons-path',
'type',
@@ -98,7 +98,7 @@
try:
opts, args = getopt.getopt(sys.argv[1:], "hs:t:vw",
["help", "verbose", "enable-mini-icons", "with-titles",
-"desktop=", "size=", "theme=", "install-prefix=", "menu-type="]+obs_args+equaled_obs_parms)
+"desktop=", "size=", "theme=", "install-prefix=", "menu-type=", "title="]+obs_args+equaled_obs_parms)
except getopt.GetoptError, err:
# print help information and exit:
print str(err) # will print something like "option -a not recognized"
@@ -112,7 +112,7 @@
theme='gnome'
icon_dir="~/.fvwm/icons"
top='FvwmMenu'
-install_prefix = '/etc/xdg/menus/'
+install_prefix = ''
menu_type = 'applications'
with_titles = False
@@ -125,8 +125,9 @@
elif o in ("--enable-mini-icons") :
force=True
elif o in ("--desktop") :
-#?desktop=a + '-'
-desktop=a
+desktop=a + '-'
+elif o in ("--title") :
+top=a
elif o in ("--install-prefix") :
if a and not os.path.isabs(a):
assert False, "install-prefix must be an absolute path"
@@ -149,27 +150,41 @@
else:
assert False, "unhandled option"
-check=install_prefix+desktop+menu_type+'.menu'
+if desktop == 'debian-':
+menu_type = 'menu'
+
+check=desktop+menu_type+'.menu'
menu = checkmenu(check)
-if menu == None and menu_type == 'applications':
+if menu == None and desktop == '' and menu_type == 'applications':
# it could be a Debian system
-check = install_prefix + 'debian-menu.menu'
+check = 'debian-menu.menu'
menu = checkmenu(check)
if menu == None:
-# fixme, no point in trying to print "None".
-sys.stderr.write(check+" not available on this system. Exiting...\n")
+sys.stderr.write(install_prefix+desktop+menu_type+".menu not available on this system. Exiting...\n")
sys.exit()
else:
parsemenu(xdg.Menu.parse(menu), top)
-def checkmenu(menu):
-if not os.path.exists(menu):
-menu = None
+def checkmenu(menu_name):
+stop = False
+menu = None
+if install_prefix == '':
+for dir in xdg_config_dirs:
+dir = dir + '/menus'
+if os.path.exists(dir):
+dir_list = os.listdir(dir)
+for filename in fnmatch.filter(dir_list, menu_name):
+menu = os.path.join(dir, filename)
+stop = True
+if stop == True:
+break
+else:
+if os.path.exists(install_prefix+menu):
+menu = install_prefix+menu
return menu
-
def printtext(text):
print text.encode("utf-8")
@@ -191,9 +206,6 @@
if not os.path.isdir(os.path.expanduser(icon_dir)):
os.system("mkdir " + os.path.expanduser(icon_dir))
-
Re: [Patch] fvwm-menu-desktop improvements
Thomas Funk writes: > Shame on me :S ... an if loop in checkmenu() is get out of > place. Attached a fresh fvwm-menu-desktop.in.p3.patch > > I've tested the last fvwm-menu-desktop.in (with p1-3) on OpenSuse 11.4 > and Mandriva2010. Works out of the box ^^ Could you redo patch 3 in light of current CVS. The way checkmenu wipes out it's input, the value of "menu" in the abort message is always None. Gives me a syntax error. Could you add something to usage for --desktop and --menu-type. -- Dan Espen
Re: [Patch] fvwm-menu-desktop improvements
Shame on me :S ... an if loop in checkmenu() is get out of place.
Attached a fresh fvwm-menu-desktop.in.p3.patch
I've tested the last fvwm-menu-desktop.in (with p1-3) on OpenSuse 11.4
and Mandriva2010. Works out of the box ^^
Thomas
--- Old/fvwm-menu-desktop.in.p2.py 2012-06-24 14:52:46.900522522 +0200
+++ fvwm-menu-desktop.py 2012-06-24 15:53:14.083372640 +0200
@@ -41,6 +41,7 @@
import xdg.Locale
import os.path
import os
+import fnmatch
from xdg.DesktopEntry import *
@@ -112,7 +113,7 @@
theme='gnome'
icon_dir="~/.fvwm/icons"
top='FvwmMenu'
-install_prefix = '/etc/xdg/menus/'
+install_prefix = ''
menu_type = 'applications'
with_titles = False
@@ -148,11 +149,11 @@
else:
assert False, "unhandled option"
-menu = checkmenu(install_prefix+desktop+menu_type+'.menu')
+menu = checkmenu(desktop+menu_type+'.menu')
if menu == None and menu_type == 'applications':
# it could be a Debian system
-menu = checkmenu(install_prefix + 'debian-menu.menu')
+menu = checkmenu('debian-menu.menu')
if menu == None:
sys.stderr.write( menu + " not available on this system. Exiting...\n" )
@@ -160,9 +161,22 @@
else:
parsemenu(xdg.Menu.parse(menu), top)
-def checkmenu(menu):
-if not os.path.exists(menu):
-menu = None
+def checkmenu(menu_name):
+stop = False
+menu = None
+if install_prefix == '':
+for dir in xdg_config_dirs:
+dir = dir + '/menus'
+if os.path.exists(dir):
+dir_list = os.listdir(dir)
+for filename in fnmatch.filter(dir_list, menu_name):
+menu = os.path.join(dir, filename)
+stop = True
+if stop == True:
+break
+else:
+if os.path.exists(install_prefix+menu):
+menu = install_prefix+menu
return menu
def printtext(text):
[Patch] fvwm-menu-desktop improvements
Hi Dan,
I've attached 2 patches again.
fvwm-menu-desktop.in.p2.patch - only improvements. Should be patched
after the first patch.
- I've added two new options:
'--menu-type' and changed '--desktop' to it's named behavior.
Before:
--desktop=applications/gnome-applications [applications]
Now:
--desktop=gnome/kde/xfce ['']
--menu-type=applications/preferences/settings [applications]
'-w' or '--with-titles'
I like menus with titles, so this option enables them :-)
Also, if no applications.menu found it will search for debian-menu.menu.
If all fails a message will print to stderr.
fvwm-menu-desktop.in.p3.patch - implements the full xdg spec. Should be
patched after patch 2
- Now fvwm-menu-desktop.in searches in the xdg directories. I've changed
--install-prefix='/etc/xdg/menus' to --install-prefix='' but if user
wants to search in a specific path it can be used anyway. Then the xdg
way will not used.
I know, patches over patches ... but now it works hopefully on all systems.
I haven't changed the help because I don't know what of these changes
you agree with.
Thomas
--- Old/fvwm-menu-desktop.in.p1.py 2012-06-24 14:36:09.002394717 +0200
+++ Old/fvwm-menu-desktop.in.p2.py 2012-06-24 14:52:46.900522522 +0200
@@ -96,23 +96,25 @@
dashed_obs_parms.append('--'+a)
try:
-opts, args = getopt.getopt(sys.argv[1:], "hs:t:v",
- ["help", "verbose", "enable-mini-icons",
-"desktop=", "size=", "theme=", "install-prefix="]+obs_args+equaled_obs_parms)
+opts, args = getopt.getopt(sys.argv[1:], "hs:t:vw",
+ ["help", "verbose", "enable-mini-icons", "with-titles",
+"desktop=", "size=", "theme=", "install-prefix=", "menu-type="]+obs_args+equaled_obs_parms)
except getopt.GetoptError, err:
# print help information and exit:
print str(err) # will print something like "option -a not recognized"
print usage
sys.exit(2)
-global verbose, force, size, theme, icon_dir, top, install_prefix
+global verbose, force, size, theme, icon_dir, top, install_prefix, menu_type, with_titles
verbose = False
force = False
-desktop='applications'
+desktop=''
size=24
theme='gnome'
icon_dir="~/.fvwm/icons"
top='FvwmMenu'
install_prefix = '/etc/xdg/menus/'
+menu_type = 'applications'
+with_titles = False
for o, a in opts:
if o == "-v":
@@ -123,7 +125,7 @@
elif o in ("--enable-mini-icons") :
force=True
elif o in ("--desktop") :
-desktop=a
+desktop=a + '-'
elif o in ("--install-prefix") :
if a and not os.path.isabs(a):
assert False, "install-prefix must be an absolute path"
@@ -136,25 +138,32 @@
size = int(a)
elif o in ("--theme") :
theme = a
+elif o in ("--menu-type") :
+menu_type = a
+elif o in ("-w","--with-titles") :
+with_titles = True
elif o in (str(dashed_obs_args+dashed_obs_parms)) :
# Ignore
sys.stderr.write( "Arg "+o+" is obsolete and ignored\n" )
else:
assert False, "unhandled option"
-# If desktop lacks a trailing .menu, put one there.
-if (not re.search('.*[.]menu$',desktop)) : # no trailing .menu
- desktop=desktop+'.menu'
-menu=install_prefix+desktop
-# If desktop arg has leading slash, it's a full path
-if (desktop[0] == '/'):
-menu=desktop
+menu = checkmenu(install_prefix+desktop+menu_type+'.menu')
-if os.path.exists(menu):
-parsemenu(xdg.Menu.parse(menu), top)
-else:
-print menu + " not available on this system. Exiting..."
+if menu == None and menu_type == 'applications':
+# it could be a Debian system
+menu = checkmenu(install_prefix + 'debian-menu.menu')
+if menu == None:
+sys.stderr.write( menu + " not available on this system. Exiting...\n" )
+sys.exit()
+else:
+parsemenu(xdg.Menu.parse(menu), top)
+
+def checkmenu(menu):
+if not os.path.exists(menu):
+menu = None
+return menu
def printtext(text):
print text.encode("utf-8")
@@ -207,7 +216,10 @@
if not name:
name = menu.getPath()
printtext('DestroyMenu "%s"' % name)
-printtext('AddToMenu "%s"' % name)
+if with_titles:
+printtext('AddToMenu "%s" "%s" Title' % (name, name))
+else:
+printtext('AddToMenu "%s"' % name)
for entry in menu.getEntries():
if isinstance(entry, xdg.Menu.Menu):
printmenu(entry.getName(), entry.getIcon(),
--- Old/fvwm-menu-desktop.in.p2.py 2012-06-24 14:52:46.900522522 +0200
+++ fvwm-menu-desktop.py 2012-06-24 14:52:59.104693184 +0200
@@ -41,6 +41,7 @@
import xdg.Locale
