Re: First try of fvwm-menu-desktop which creates a full menu
Hi Dan,
attached is a small improvement patch for fvwm-menu-desktop.in. It
changing the top menu entries to better looking titles.
Before:
DestroyMenu FvwmMenu
AddToMenu FvwmMenu FvwmMenu Title
+ Kde4-applications Popup FvwmKde4-applications
+ Preferences Popup FvwmPreferences
+ Settings Popup FvwmSettings
+ Start-here Popup FvwmStart-here
+ System-settings Popup FvwmSystem-settings
after:
DestroyMenu FvwmMenu
AddToMenu FvwmMenu FvwmMenu Title
+ Kde4 Applications Popup FvwmKde4 Applications
+ Preferences Popup FvwmPreferences
+ Settings Popup FvwmSettings
+ Start Here Popup FvwmStart Here
+ System Settings Popup FvwmSystem Settings
Thomas
--- /media/daten/shared/sourcen/cvs/fvwm/bin/fvwm-menu-desktop.in 2012-07-23 18:32:18.108252482 +0200
+++ fvwm-menu-desktop.in.py 2012-07-27 11:10:16.720543498 +0200
@@ -415,8 +415,10 @@
# create a top title list
top_titles = []
for file in menulist:
-name = file.replace('.menu', '').split('/')
-top_titles.append(name[-1][0].upper()+name[-1][1:])
+# extract and split the filename and set first char of each word to capital
+name_parts = file.replace('.menu', '').split('/')[-1].split('-')
+name_parts = [name[0].replace(name[0], name[0].upper())+name[1:] for name in name_parts]
+top_titles.append(' '.join(name_parts))
# create the submenus
new_toptitles = []
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: I am willing to do the job of rewriting it but I need help. If you could take some of your spare time to give me hints and answer questions fairly would be fine. What I want to say is, that i want an open, honest and constructive discussion about the programming and functionality of the module and not RTFM - I do this every time before I asking. So if you're willing to be a mentor in a sense I am ready to programming it. Looks like I should educate myself too. Back when I'm a bit smarter. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: 2012/7/18 Dan Espen des...@verizon.net: I'm guessing dbus or some other abomination does the job for the desktops... I've checked the internet for finding infos how the Distributions/ Desktops do the automatic menu update process. Here're my results: Debian: When a package that wants to add/remove something to/from the menu tree gets installed/removed, it will run update-menus in its postinst/postrm script. http://www.debian.org/doc/packaging-manuals/menu.html/ch2.html - see chapter 2.1 http://www.debian.org/doc/packaging-manuals/menu.html/ch4.html - See chapter 4.2 KDE: Use kbuildsycoca4 to update the configuration cache in KDE https://bbs.archlinux.org/viewtopic.php?id=64514 Gnome: found nothing about how they do it. I send an email to the LinuxMint developers because they made their own menu (mintmenu) but got no response back yet. Xfce: Before 4.8 they use libxfce4menu. In the sources there're comments that they use filesystem monitoring - down line 171 http://bazaar.launchpad.net/~vcs-imports/libxfce4menu/trunk/view/head:/STATUS Since 4.8 garcon is used. Also with filesystem monitoring - http://wiki.xfce.org/dev/garcon In the Xfce wiki page (http://wiki.xfce.org/howto/customize-menu) they said also that xfdesktop session starts, changes to the menu file are implemented immediately. (for Xfdesktop 4.5 or higher) Or reload xfdesktop Fluxbox and other WMs: Per default no automatic update. User have to do this manually. The thoughts doing this over dbus or other stuff: found nothing about specific messages used by package systems to inform tools to start menu updating. Summary: - Debian do updating Debian specific - not usable - depends on package mgmt. - Some DEs do updating specific too via daemons - too much dependencies - Xfce do filesystem monitoring/scanning - Other WMs don't update automatically - No event messages available to initialize menu updating Looks deflating. 2012/7/23 Dan Espen des...@verizon.net: Over here: http://crunchbanglinux.org/forums/topic/5370/how-to-set-up-a-dynamic-xdg-menu-for-openbox/ http://tinyurl.com/84jdvcy I see they are talking about using inotify to know when menus have been updated. Not something I'd recommend. Manual update still seems preferable (to me). inotify sounds interesting but another dependency again. I still prefer the filesystem scan by ourself if at all. I found the idea in the sources of Marchfluxmenu: They do this with 'ls /usr/share/applications/*.desktop | wc -l'. They remember the count and if it changed a menu update starts. One directory is enough for them because they use the applications menu only. But I am not sure if this is enough for our menus. Must check this first. But if so a scan tooks milliseconds and the load is insignificant. We could do a scan perhaps every minute. This could be enough to rebuild the menus without recognition by the user. Another advantage is no dependency with dbus and other 'abomination' as you said. We need no entries for daemons to register us, no restarts of them and so forth ... Personally I haven't either a problem with manual nor with automatic updating. Both have their own charm ... But for a automatic menus update we need another solution - a module as Thomas suggested. Excellent work. Lots of people expect their system to be able to go to sleep, hence my dislike for polling. Sounds to me like Debian has it right. (Specifically invoking a process after menus change.) I wouldn't be surprised to see a solution being implemented in other distros in due time. In the mean time, I think we're fine as is. Again, personal issues piling up. Forgive me for dragging my feet on patch application. I'll try to get to it ASAP. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: Dan Espen des...@verizon.net wrote: Thomas Funk t.funk...@googlemail.com writes: Dan Espen des...@verizon.net wrote Also a fixed fvwm-menu-desktop-config.fpl because there were some missing double quotes (I don't know why they were absent ... shit happens) I think it's time for me to commit this fpl file. It comes without Makefile.am consideration or even a place to put it. Which directory do you see it being in? Doesn't it need a man page? Thomas Adam made some comments about using FvwmPerl. Is that resolved? I'm not all that familiar with FvwmPerl myself. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
2012/7/23 Dan Espen des...@verizon.net: I don't understand. If you do this: + I Test (f $[FVWM_USERDIR]/.menu) Read $[FVWM_USERDIR]/.menu + I TestRC (!Match) PipeRead 'fvwm-menu-desktop --insert-in-menu MenuRoot \\ $[FVWM_USERDIR]/.menu \\ + echo Read $[FVWM_USERDIR]/.menu' Then the menu only gets regenerated when the file $[FVWM_USERDIR]/.menu goes away. I don't see how that helps at all. This is not the important part. With AddToMenu MenuRoot Root Menu Title + FuncXdgMenusInRoot you must restart because the root menu and the entry + FuncXdgMenusInRoot generates a static menu. But if you use a dynamic root menu like this: AddToMenu MenuRoot DynamicPopupAction FuncMenuRoot DestroyFunc FuncMenuRoot AddToFunc FuncMenuRoot + I DestroyMenu MenuRoot + I AddToMenu MenuRoot DynamicPopupAction FuncMenuRoot + I AddToMenu MenuRoot Root Menu Title + I Popup XdgMenus and also a dynamic XdgMenus menu: AddToMenu XdgMenus DynamicPopupAction FuncXdgMenusInRoot DestroyFunc FuncXdgMenusInRoot AddToFunc FuncXdgMenusInRoot + I DestroyMenu XdgMenus + I AddToMenu XdgMenus DynamicPopupAction FuncXdgMenusInRoot then you can execute Regenerate menus without a restart. The trick is, that Regenerate menus does a Read after execution of fvwm-menu-desktop. so the new generated menu is instantly available if the user pops up the root menu. The two Test lines are only to guarantee that a .menu is red and if not exist generated and red while poping up the root menu. I gave a thought at night to the patch and discovered that the example with + FuncXdgMenusInRoot should be deleted because it shows a way the user doesn't use anymore if he read the example below. Or should we let it for the sake of completness? Thomas
Re: First try of fvwm-menu-desktop which creates a full menu
On Mon, Jul 23, 2012 at 10:08:05AM +0200, Thomas Funk wrote: 2012/7/23 Dan Espen des...@verizon.net: I don't understand. If you do this: + I Test (f $[FVWM_USERDIR]/.menu) Read $[FVWM_USERDIR]/.menu + I TestRC (!Match) PipeRead 'fvwm-menu-desktop --insert-in-menu MenuRoot \\ $[FVWM_USERDIR]/.menu \\ + echo Read $[FVWM_USERDIR]/.menu' Then the menu only gets regenerated when the file $[FVWM_USERDIR]/.menu goes away. I don't see how that helps at all. This is not the important part. With AddToMenu MenuRoot Root Menu Title + FuncXdgMenusInRoot you must restart because the root menu and the entry + FuncXdgMenusInRoot generates a static menu. But if you use a dynamic root menu like this: AddToMenu MenuRoot DynamicPopupAction FuncMenuRoot Don't destroy the same menu you're about to (re)create. -- Thomas Adam
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.funk...@googlemail.com writes: 2012/7/23 Dan Espen des...@verizon.net: I don't understand. If you do this: + I Test (f $[FVWM_USERDIR]/.menu) Read $[FVWM_USERDIR]/.menu + I TestRC (!Match) PipeRead 'fvwm-menu-desktop --insert-in-menu MenuRoot \\ $[FVWM_USERDIR]/.menu \\ + echo Read $[FVWM_USERDIR]/.menu' Then the menu only gets regenerated when the file $[FVWM_USERDIR]/.menu goes away. I don't see how that helps at all. This is not the important part. With AddToMenu MenuRoot Root Menu Title + FuncXdgMenusInRoot you must restart because the root menu and the entry + FuncXdgMenusInRoot generates a static menu. But if you use a dynamic root menu like this: AddToMenu MenuRoot DynamicPopupAction FuncMenuRoot DestroyFunc FuncMenuRoot AddToFunc FuncMenuRoot + I DestroyMenu MenuRoot + I AddToMenu MenuRoot DynamicPopupAction FuncMenuRoot + I AddToMenu MenuRoot Root Menu Title + I Popup XdgMenus and also a dynamic XdgMenus menu: AddToMenu XdgMenus DynamicPopupAction FuncXdgMenusInRoot DestroyFunc FuncXdgMenusInRoot AddToFunc FuncXdgMenusInRoot + I DestroyMenu XdgMenus + I AddToMenu XdgMenus DynamicPopupAction FuncXdgMenusInRoot then you can execute Regenerate menus without a restart. The trick is, that Regenerate menus does a Read after execution of fvwm-menu-desktop. so the new generated menu is instantly available if the user pops up the root menu. The two Test lines are only to guarantee that a .menu is red and if not exist generated and red while poping up the root menu. I gave a thought at night to the patch and discovered that the example with + FuncXdgMenusInRoot should be deleted because it shows a way the user doesn't use anymore if he read the example below. Or should we let it for the sake of completness? Using --insert-in-menu MyMenu, I get this: AddToMenu MyMenu + Kde4-applications Popup FvwmKde4-applications + Preferences Popup FvwmPreferences + Settings Popup FvwmSettings + Start-here Popup FvwmStart-here + System-settings Popup FvwmSystem-settings + Nop + Regenerate XDG Menu(s) Module FvwmPerl -l fvwm-menu-desktop-config.fpl If I run this twice, MyMenu will have all these entries appended to MyMenu twice. I'd have to destroy the menu and recreate it to get any other outcome. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Dan Espen des...@verizon.net wrote Using --insert-in-menu MyMenu, I get this: AddToMenu MyMenu + Kde4-applications Popup FvwmKde4-applications + Preferences Popup FvwmPreferences + Settings Popup FvwmSettings + Start-here Popup FvwmStart-here + System-settings Popup FvwmSystem-settings + Nop + Regenerate XDG Menu(s) Module FvwmPerl -l fvwm-menu-desktop-config.fpl If I run this twice, MyMenu will have all these entries appended to MyMenu twice. I'd have to destroy the menu and recreate it to get any other outcome. Can you post how you've implemented it in the MyMenu? If you've deleted + I DestroyMenu XdgMenus because of my last email to Thomas then do it back. I have problems on my VM with creating menus and must check this first. On my Debian system at home all works fine with the new snippet. Thomas
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.funk...@googlemail.com writes: Dan Espen des...@verizon.net wrote Using --insert-in-menu MyMenu, I get this: AddToMenu MyMenu + Kde4-applications Popup FvwmKde4-applications + Preferences Popup FvwmPreferences + Settings Popup FvwmSettings + Start-here Popup FvwmStart-here + System-settings Popup FvwmSystem-settings + Nop + Regenerate XDG Menu(s) Module FvwmPerl -l fvwm-menu-desktop-config.fpl If I run this twice, MyMenu will have all these entries appended to MyMenu twice. I'd have to destroy the menu and recreate it to get any other outcome. Can you post how you've implemented it in the MyMenu? If you've deleted + I DestroyMenu XdgMenus because of my last email to Thomas then do it back. I have problems on my VM with creating menus and must check this first. On my Debian system at home all works fine with the new snippet. I typed in the command: python fvwm-menu-desktop.in --insert-in-menu MyMenu I then searched the output for MyMenu. The lines above are the only references to MyMenu. If I paste the lines above into FvwmTalk twice and then enter PopUp MyMenu I see a menu with all it's entries duplicated. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Dan Espen des...@verizon.net wrote:
Thomas Funk t.funk...@googlemail.com writes:
Dan Espen des...@verizon.net wrote
Using --insert-in-menu MyMenu, I get this:
AddToMenu MyMenu
+ Kde4-applications Popup FvwmKde4-applications
+ Preferences Popup FvwmPreferences
+ Settings Popup FvwmSettings
+ Start-here Popup FvwmStart-here
+ System-settings Popup FvwmSystem-settings
+ Nop
+ Regenerate XDG Menu(s) Module FvwmPerl -l
fvwm-menu-desktop-config.fpl
If I run this twice, MyMenu will have all these entries appended to
MyMenu twice. I'd have to destroy the menu and recreate it to get any
other outcome.
Can you post how you've implemented it in the MyMenu? If you've deleted
+ I DestroyMenu XdgMenus
because of my last email to Thomas then do it back. I have problems
on my
VM with creating menus and must check this first. On my Debian system at
home all works fine with the new snippet.
I typed in the command:
python fvwm-menu-desktop.in --insert-in-menu MyMenu
I then searched the output for MyMenu.
The lines above are the only references to MyMenu.
If I paste the lines above into FvwmTalk twice
and then enter PopUp MyMenu
I see a menu with all it's entries duplicated.
Yes, that's correct cause no DestroyMenu MyMenu exists in the generated
menu. But that has to be. If you have a static/normal menu called
MyMenu then you create it like this in .config:
DestroyMenu MyMenu
AddToMenu MyMenu
+ A_Title Title
+ Entry1 FuncSomething
+ Entry2 Popup SomeMenu
If you want to add something to MyMenu you do it like
AddToMenu MyMenu
+ Another_Entry1 Popup SomeOtherMenu
+ Another_App Exec exec foo
If you add this part again like you do with FvwmTalk you've duplicated
entries.
But if you use the dynamic example all works fine. I've added the patch
again but without + I DestroyMenu XdgMenus in FuncXdgMenusInRoot as
Thomas pointed out. Thanks Thomas :-)
Also a fixed fvwm-menu-desktop-config.fpl because there were some
missing double quotes (I don't know why they were absent ... shit happens)
Thomas
--- /media/daten/shared/sourcen/cvs/fvwm/bin/fvwm-menu-desktop.1.in 2012-07-22 12:25:57.772773990 +0200
+++ fvwm-menu-desktop.1 2012-07-23 22:31:40.817613594 +0200
@@ -86,9 +86,10 @@
.IP \fB\-\-insert\-in\-menu\fR \fINAME\fR
Option to insert generated menu(s) \fBIN\fR a menu \fINAME\fR (its
top title). Note that this 0ption does not work correctly with the
-Regnerate Menus menu entry since items insserted into a menu cannot be
-removed (currently). If you use this option and want to update your menus,
-restart fvwm.
+Regnerate Menus menu entry in a normal built menu since items insserted
+into such a menu cannot be removed (currently). If you use this option
+there and want to update your menus, you have to restart fvwm. A better
+way is to use dynamic menus (see the example in the USAGE section).
.IP \fB\-\-get\-menus\fR \fIall\fR|\fIdesktop\fR
Prints a space separated list of full menu paths. \fIall\fR is all menus
@@ -213,7 +214,8 @@
.EE
.RE
-or if you want to show the menus directly in the Root menu use this:
+or if you want to show the menus directly in a normal Root menu use
+this:
.RS
.EX
@@ -226,6 +228,32 @@
+ I Test (f $[FVWM_USERDIR]/.menu) Read $[FVWM_USERDIR]/.menu
+ I TestRC (!Match) PipeRead 'fvwm-menu-desktop --insert-in-menu MenuRoot \\
$[FVWM_USERDIR]/.menu \\
+ echo Read $[FVWM_USERDIR]/.menu'
+.EE
+.RE
+
+The problem here is, that you have to restart fvwm because items insserted
+into such a menu cannot be removed. For that BOTH menus must be dynamically:
+
+.RS
+.EX
+AddToMenu MenuRoot DynamicPopupAction FuncMenuRoot
+
+DestroyFunc FuncMenuRoot
+AddToFunc FuncMenuRoot
++ I DestroyMenu MenuRoot
++ I AddToMenu MenuRoot DynamicPopupAction FuncMenuRoot
++ I AddToMenu MenuRoot Root Menu Title
++ I Popup XdgMenus
+
+AddToMenu XdgMenus DynamicPopupAction FuncXdgMenusInRoot
+
+DestroyFunc FuncXdgMenusInRoot
+AddToFunc FuncXdgMenusInRoot
++ I AddToMenu XdgMenus DynamicPopupAction FuncXdgMenusInRoot
++ I Test (f $[FVWM_USERDIR]/.menu) Read $[FVWM_USERDIR]/.menu
++ I TestRC (!Match) PipeRead 'fvwm-menu-desktop --insert-in-menu MenuRoot \\
+ $[FVWM_USERDIR]/.menu \\
echo Read $[FVWM_USERDIR]/.menu'
.EE
.RE
# This script generates a FvwmForm similar to the FvwmForm-Desktop by
# Dan Espen but insert the found xdg menus dynamically into the Form
# before processed.
# Author: Thomas Funk t.f...@web.de
# Version: 1.2
package MenuConfig;
use File::Basename;
use strict;
use warnings;
#open(MSG ,[path]/log.txt) || die Error $!;
my $all = `fvwm-menu-desktop --get-menus all`;
my $selected = `fvwm-menu-desktop --get-menus desktop`;
my @all_filelist = split(/ /,$all);
my @selected_filelist = split(/ /,$selected);
my %all_menus = ();
my %selected__menus = ();
my $max_length = 0;
foreach my $path (@selected_filelist) {
my ($filename,
Re: First try of fvwm-menu-desktop which creates a full menu
Dan Espen des...@verizon.net wrote: Nice. Regarding this section: \ .SH ERRORS AND WARNINGS \ \fBfvwm-menu-desktop\fR prints errors and warnings to STDERR. So these \ messages could be redirect to e.g. ~/.xsessions-errors: \ .RS \ .EX \ fvwm-menu-desktop $FVWM_USERDIR/.menu 2 ~/.xsession-errors \ .EE \ .RE Everything I run under fvwm already redirects to ~/.xsession-errors. (I send it somewhere else, but same idea.) Point is, isn't all error output, from everything under Fvwm already going to an error file? I don't think we need that section. No problem. As I see you've commented this part out already. Btw. you've wrote in --insert-in-menu NAME: ... Note that this 0ption does not work correctly with the Regnerate Menus menu entry since items insserted into a menu cannot be removed (currently). If you use this option and want to update your menus, restart fvwm. This applies only for normal menus. If you use for both DynamicPopupAction fvwm must not restarted. I've wrote the additions for the manpage in the attached patch. Thomas --- /media/daten/shared/sourcen/cvs/fvwm/bin/fvwm-menu-desktop.1.in 2012-07-22 12:25:57.772773990 +0200 +++ fvwm-menu-desktop.1 2012-07-23 00:51:00.611988135 +0200 @@ -86,9 +86,10 @@ .IP \fB\-\-insert\-in\-menu\fR \fINAME\fR Option to insert generated menu(s) \fBIN\fR a menu \fINAME\fR (its top title). Note that this 0ption does not work correctly with the -Regnerate Menus menu entry since items insserted into a menu cannot be -removed (currently). If you use this option and want to update your menus, -restart fvwm. +Regnerate Menus menu entry in a normal built menu since items insserted +into such a menu cannot be removed (currently). If you use this option +there and want to update your menus, you have to restart fvwm. The only +way is to use dynamic menus (see the example in the USAGE section). .IP \fB\-\-get\-menus\fR \fIall\fR|\fIdesktop\fR Prints a space separated list of full menu paths. \fIall\fR is all menus @@ -213,7 +214,8 @@ .EE .RE -or if you want to show the menus directly in the Root menu use this: +or if you want to show the menus directly in a normal Root menu use +this: .RS .EX @@ -226,6 +228,33 @@ + I Test (f $[FVWM_USERDIR]/.menu) Read $[FVWM_USERDIR]/.menu + I TestRC (!Match) PipeRead 'fvwm-menu-desktop --insert-in-menu MenuRoot \\ $[FVWM_USERDIR]/.menu \\ + echo Read $[FVWM_USERDIR]/.menu' +.EE +.RE + +The problem here is, that you have to restart fvwm because items insserted +into such a menu cannot be removed. For that BOTH menus must be dynamically: + +.RS +.EX +AddToMenu MenuRoot DynamicPopupAction FuncMenuRoot + +DestroyFunc FuncMenuRoot +AddToFunc FuncMenuRoot ++ I DestroyMenu MenuRoot ++ I AddToMenu MenuRoot DynamicPopupAction FuncMenuRoot ++ I AddToMenu MenuRoot Root Menu Title ++ I Popup XdgMenus + +AddToMenu XdgMenus DynamicPopupAction FuncXdgMenusInRoot + +DestroyFunc FuncXdgMenusInRoot +AddToFunc FuncXdgMenusInRoot ++ I DestroyMenu XdgMenus ++ I AddToMenu XdgMenus DynamicPopupAction FuncXdgMenusInRoot ++ I Test (f $[FVWM_USERDIR]/.menu) Read $[FVWM_USERDIR]/.menu ++ I TestRC (!Match) PipeRead 'fvwm-menu-desktop --insert-in-menu MenuRoot \\ + $[FVWM_USERDIR]/.menu \\ echo Read $[FVWM_USERDIR]/.menu' .EE .RE
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: Dan Espen des...@verizon.net wrote: Btw. you've wrote in --insert-in-menu NAME: ... Note that this 0ption does not work correctly with the Regnerate Menus menu entry since items insserted into a menu cannot be removed (currently). If you use this option and want to update your menus, restart fvwm. This applies only for normal menus. If you use for both DynamicPopupAction fvwm must not restarted. I've wrote the additions for the manpage in the attached patch. I don't understand. If you do this: + I Test (f $[FVWM_USERDIR]/.menu) Read $[FVWM_USERDIR]/.menu + I TestRC (!Match) PipeRead 'fvwm-menu-desktop --insert-in-menu MenuRoot \\ $[FVWM_USERDIR]/.menu \\ + echo Read $[FVWM_USERDIR]/.menu' Then the menu only gets regenerated when the file $[FVWM_USERDIR]/.menu goes away. I don't see how that helps at all. Over here: http://crunchbanglinux.org/forums/topic/5370/how-to-set-up-a-dynamic-xdg-menu-for-openbox/ http://tinyurl.com/84jdvcy I see they are talking about using inotify to know when menus have been updated. Not something I'd recommend. Manual update still seems preferable (to me). I don't think insert-in-menu is a problem, in fact it's pretty nice. I just wanted to point out it's limitation. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Dan Espen des...@verizon.net wrote: Haven't you been doing CVS updates? Sorry, used fvwm-menu-desktop.1 instead of fvwm-menu-desktop.1.in Correct patch attached. Thomas --- /media/daten/shared/sourcen/cvs/fvwm/bin/fvwm-menu-desktop.1.in 2012-07-11 16:45:31.0 +0200 +++ fvwm-menu-desktop.1 2012-07-21 12:18:11.617683854 +0200 @@ -20,88 +20,86 @@ fvwm-menu-desktop \- Reads XDG menu files and creates Fvwm menus .SH SYNOPSIS - fvwm-menu-desktop -[ \fB\-\-help\fR|\fB\-h\fR|\fB\-?\fR ] -[ \fB\-\-verbose\fR|\fB\-v\fR ] +[ \fB\-\-help\fR|\fB\-h\fR ] +[ \fB\-\-version\fR|\fB\-v\fR ] [ \fB\-\-install\-prefix\fR \fIDIR\fR ] [ \fB\-\-desktop\fR \fINAME\fR ] -[ \fB\-\-title\fR \fINAME\fR ] +[ \fB\-\-menu\-type\fR \fINAME\fR ] +[ \fB\-\-theme\fR \fINAME\fR ] +[ \fB\-\-with\-titles\fR|\fB\-w\fR ] [ \fB\-\-enable\-mini\-icons\fR ] +[ \fB\-\-size\fR|\fB\-s\fR \fINUM\fR ] +[ \fB\-\-title\fR|\fB\-t\fR \fINAME\fR ] +[ \fB\-\-insert\-in\-menu\fR \fINAME\fR ] +[ \fB\-\-get\-menus\fR \fIall\fR|\fIdesktop\fR ] +[ \fB\-\-set\-menus\fR \fImenu_paths\fR ] +[ \fB\-\-verbose\fR ] + .SH DESCRIPTION -This is a python script which parses XDG menus definitions to build +This is a python script which parses XDG menus definitions to build corresponding fvwm menus. -.SH USAGE -To add the XDG application menu to the Utilities menu -add the following to your fvwm config file (.fvwm/config): -.EX - ... -AddToMenu Utilities Application Menu Popup FvwmMenu -PipeRead 'fvwm-menu-desktop' -.EE - -By default fvwm-menu-desktop -builds the applications menu -and the menu is named FvwmMenu. - -.EX -AddToMenu Utilities KDE User Menu Popup kde\-user -AddToMenu kde\-user -+ DynamicPopupAction PipeRead 'fvwm-menu-desktop --desktop kde-user --enable-mini-icons [other options]' -.EE - -If you think that fvwm-menu-desktop slows your startup too much do -not use PipeRead. Instead run fvwm-menu-desktop -and -redirect the menu to a file and Read that file in -your .fvwm2rc file. -Another possibility is to use DynamicPopupAction -(with fvwm menu), the menu will be built only if -you pop up the menu. The -following menu creates a kde\-all menu which contains the user menu -which is built each time you pop up kde\-all and contains a pop up -to the system menu which is built only the first time you pop it up. -.EX -AddToMenu kde\-all -+ DynamicPopupAction FuncRecreateKdeAll - -AddToMenu kde\-sys -+ DynamicPopupAction PipeRead 'fvwm-menu-desktop \\ -\-\-desktop kde\-sys [options, but \-\-destroy-type d* or n*]' - -AddToFunc FuncRecreateKdeAll \\ -I PipeRead 'fvwm-menu-desktop \\ -\-\-desktop kde\-user \-\-enable\-mini\-icons \-\-name kde\-all \\ -\-\-destroy-type dynamic [options you like]' -+ I AddToMenu kde\-all Nop -+ I AddToMenu kde\-all Kde System%mini/mini\-k.xpm% Popup kde\-sys -.EE - .SH OPTIONS .IP Main Options .IP \fB\-\-help\fR Show the help and exit. -.IP \fB\-\-verbose\fR -Run verbosely. + +.IP \fB\-\-version\fR +Show the version and exit. + .IP \fB\-\-install-prefix\fR \fIDIR\fR -Optional parameter to override the default location -for XDG menu definitions. The default location is /etc/xdg/menus. +Optional parameter to override the default locations for XDG menu +definitions. Related to the xdg specification the default location is +/etc/xdg/menus and $HOME/.config/menus if exist. + .IP \fB\-\-desktop\fR \fINAME\fR -The name of the menus you want to generate. -The default is application. -.IP \fB\-\-title\fR \fINAME\fR -Define the menu title of the top menu. Default -is Gnome System Menu for gnome\-sys, Gnome User Menu for -gnome\-user, Gnome Red Hat Menu for gnome\-redhat, -Gnome Mandriva Menu for gnome\-mandriva. For KDE the -default is given by KDE itself (or are similar to GNOME title). -.IP \fB\-\-name\fR \fINAME\fR -Define the menu name of the top menu. Default is the \-\-desktop -name if you use one above. +Optional parameter to override the \fINAME\fR of the main desktop +environment installed on the system. If a system offers multiple +desktop environments $XDG_MENU_PREFIX is typically set and is +ignored if \-\-desktop is denoted. Possible names are: \fIgnome\fR, +\fIkde\fR, \fIxfce\fR, \fIlxde\fR, \fIdebian\fR, etc. + +.IP \fB\-\-menu\-type\fR \fINAME\fR +Defines which type of menus should be found. Possible \fINAME\fR types +could be: \fIapplications\fR, \fIsettings\fR, \fIpreferences\fR, etc. + +Note that if the specified menu type doesn't exist the generated menu +is empty! + +.IP \fB\-\-theme\fR \fINAME\fR +Defines the used icon theme. Default is \fIgnome\fR but all others +found in /usr/share/icons could be used except the \fIhicolor\fR theme +because it's the default fallback theme if no icon is found. + +.IP \fB\-\-with\-titles\fR|\fB\-w\fR +If this option is set menus are generated with titles. Default is no +titles. + +.IP \fB\-\-title\fR|\fB\-t\fR \fINAME\fR +Option to define the menu title \fINAME\fR of the top menu used by Fvwms +\fBPopup\fR command. Default is FvwmMenu. + +.IP
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: Dan Espen des...@verizon.net wrote TF: All I really need is the words. I can add (t)groff/man markup as needed. Thanks for your accommodation but I've finished it already. Patch Nice. Regarding this section: \ .SH ERRORS AND WARNINGS \ \fBfvwm-menu-desktop\fR prints errors and warnings to STDERR. So these \ messages could be redirect to e.g. ~/.xsessions-errors: \ .RS \ .EX \ fvwm-menu-desktop $FVWM_USERDIR/.menu 2 ~/.xsession-errors \ .EE \ .RE Everything I run under fvwm already redirects to ~/.xsession-errors. (I send it somewhere else, but same idea.) Point is, isn't all error output, from everything under Fvwm already going to an error file? I don't think we need that section. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Dan Espen des...@verizon.net wrote TF: All I really need is the words. I can add (t)groff/man markup as needed. Thanks for your accommodation but I've finished it already. Patch is attached ^^ Please review it for grammar and phrase errors. I don't see get-menus in the man page. added. I think you want the option to be: --get-menus all | desktop with an error for any other value. Your fix is excellent! And 'desktop' is absolutely suitable :-) Rule of thumb, NEVER use the word will in documentation. eliminated except two. Thomas --- /media/daten/shared/sourcen/cvs/fvwm/bin/fvwm-menu-desktop.1 2012-01-02 19:25:49.120033746 +0100 +++ fvwm-menu-desktop.1 2012-07-21 00:16:50.485774334 +0200 @@ -1,5 +1,5 @@ .\ t -.\ @(#)fvwm-2.6.4 (not released yet) +.\ @(#)fvwm-2.6.6 (not released yet) .de EX \Begin example .ne 5 .if n .sp 1 @@ -14,461 +14,257 @@ .if t .sp .5 .. .ta .3i .6i .9i 1.2i 1.5i 1.8i -.TH fvwm-menu-desktop 1 (not released yet) (2.6.4) Fvwm Fvwm Modules +.TH fvwm-menu-desktop 1 (not released yet) (2.6.6) Fvwm Fvwm Modules .UC .SH NAME -fvwm-menu-desktop \- builds GNOME and KDE menus and style commands for fvwm +fvwm-menu-desktop \- Reads XDG menu files and creates Fvwm menus -.SH SYNOPSIS +.SH SYNOPSIS fvwm-menu-desktop -[ \fB\-\-help\fR|\fB\-h\fR|\fB\-?\fR ] -[ \fB\-\-version\fR|\fB\-v\fR|\fB\-V\fR ] +[ \fB\-\-help\fR|\fB\-h\fR ] +[ \fB\-\-version\fR|\fB\-v\fR ] [ \fB\-\-install\-prefix\fR \fIDIR\fR ] [ \fB\-\-desktop\fR \fINAME\fR ] -[ \fB\-\-type\fR NAME\fR ] -[ \fB\-\-fvwmgtk\-alias\fR \fINAME\fR ] -[ \fB\-\-title\fR \fINAME\fR ] -[ \fB\-\-name\fR \fINAME\fR ] -[ \fB\-\-merge-user-menu\fR ] +[ \fB\-\-menu\-type\fR \fINAME\fR ] +[ \fB\-\-theme\fR \fINAME\fR ] +[ \fB\-\-with\-titles\fR|\fB\-w\fR ] [ \fB\-\-enable\-mini\-icons\fR ] -[ \fB\-\-enable\-tran\-mini\-icons\fR ] -[ \fB\-\-mini\-icons\-path\fR \fIDIR\fR ] -[ \fB\-\-png\-icons\-path\fR \fIDIR\fR ] -[ \fB\-\-tran\-mini\-icons\-path\fR \fIDIR\fR ] -[ \fB\-\-check-mini\-icons\fR \fIPATH\fR ] -[ \fB\-\-icon\-toptitle\fR -\fImicon\fR:\fIlaw\fR:\fIplace\fR:\fIside_pic\fR:\fIcolor\fR ] -[ \fB\-\-icon\-title\fR -\fImicon\fR:\fIlaw\fR:\fIplace\fR:\fIside_pic\fR:\fIcolor\fR ] -[ \fB\-\-icon\-folder\fR \fImicon\fR:\fIlaw\fR:\fIplace\fR ] -[ \fB\-\-icon\-app\fR \fImicon\fR:\fIlaw\fR:\fIplace\fR ] -[ \fB\-\-wm\-icons\fR ] -[ \fB\-\-enable\-style\fR ] -[ \fB\-\-enable\-tran\-style\fR ] -[ \fB\-\-icon-style\fR \fImicon\fR:\fIicon\fR:\fIlaw\fR ] -[ \fB\-\-icons\-path\fR \fIDIR\fR ] -[ \fB\-\-tran\-icons\-path\fR \fIDIR\fR ] -[ \fB\-\-check-icons\fR \fIPATH\fR ] -[ \fB\-\-submenu\-name\-prefix\fR \fIname\fR ] -[ \fB\-\-dir\fR \fIDIR\fR ] -[ \fB\-\-destroy\-type\fR \fIFLAG\fR ] -[ \fB\-\-xterm\fR \fICMD\fR ] -[ \fB\-\-lang\fR \fINAME\fR ] -[ \fB\-\-utf8\fR ] -[ \fB\-\-uniconv\fR \fIcharset\fR ] -[ \fB\-\-uniconv-exec\fR \fIexec\fR ] -[ \fB\-\-menu-style\fR \fIname\fR ] -[ \fB\-\-no\-check\-app\fR ] -[ \fB\-\-time\-limit\fR \fINUM\fR ] -[ \fB\-\-kde_config\fR \fIcommand\fR ] +[ \fB\-\-size\fR|\fB\-s\fR \fINUM\fR ] +[ \fB\-\-title\fR|\fB\-t\fR \fINAME\fR ] +[ \fB\-\-insert\-in\-menu\fR \fINAME\fR ] +[ \fB\-\-get\-menus\fR \fIall\fR|\fIdesktop\fR ] +[ \fB\-\-set\-menus\fR \fImenu_paths\fR ] +[ \fB\-\-verbose\fR ] + .SH DESCRIPTION -This is a perl script which parses XDG (GNOME or KDE) menus definitions to build -corresponding fvwm menus. The script can also -build icon and mini\-icon style commands for the applications. +This is a python script which parses XDG menus definitions to build +corresponding fvwm menus. + +.SH OPTIONS + +.IP Main Options + +.IP \fB\-\-help\fR +Show the help and exit. + +.IP \fB\-\-version\fR +Show the version and exit. + +.IP \fB\-\-install-prefix\fR \fIDIR\fR +Optional parameter to override the default locations for XDG menu +definitions. Related to the xdg specification the default location is +/etc/xdg/menus and $HOME/.config/menus if exist. + +.IP \fB\-\-desktop\fR \fINAME\fR +Optional parameter to override the \fINAME\fR of the main desktop +environment installed on the system. If a system offers multiple +desktop environments $XDG_MENU_PREFIX is typically set and is +ignored if \-\-desktop is denoted. Possible names are: \fIgnome\fR, +\fIkde\fR, \fIxfce\fR, \fIlxde\fR, \fIdebian\fR, etc. + +.IP \fB\-\-menu\-type\fR \fINAME\fR +Defines which type of menus should be found. Possible \fINAME\fR types +could be: \fIapplications\fR, \fIsettings\fR, \fIpreferences\fR, etc. + +Note that if the specified menu type doesn't exist the generated menu +is empty! + +.IP \fB\-\-theme\fR \fINAME\fR +Defines the used icon theme. Default is \fIgnome\fR but all others +found in /usr/share/icons could be used except the \fIhicolor\fR theme +because it's the default fallback theme if no icon is found. + +.IP \fB\-\-with\-titles\fR|\fB\-w\fR +If this option is set menus are generated with titles. Default is no +titles. + +.IP \fB\-\-title\fR|\fB\-t\fR \fINAME\fR +Option to define the menu title \fINAME\fR of the
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: Dan Espen des...@verizon.net wrote TF: All I really need is the words. I can add (t)groff/man markup as needed. Thanks for your accommodation but I've finished it already. Patch is attached ^^ Please review it for grammar and phrase errors. That appears to be a patch against the old version of the man page. Haven't you been doing CVS updates? -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: Try the examples in the manpage you requested to get an overview about the look and feel of the different display possibilities. The page is created with asciidoc but in Groff format so you can look into it with man ^^ The man page is a LOT less readable than I expected it to be. Does every period have to be escaped? Not real happy with the result. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: Hi Dan! I've attached the advised patch related to your last CVS version of fvwm-menu-desktop. It includes the needed functionality to response to the attached configuration tool for fvwm-menu-desktop. Two new options: - get-menus [selected, all] to send the found menus to the config gui - set-menus [filelist] to tell fvwm-menu-desktop which menus should be build The usage prompt for get-menus says it prints a comma separated list, but I get a space separated list. The usage prompt says selected is an option but it looks like anything other than all is what it looks for. I'm not clear on what the selected option is doing. You're English it pretty good. No such word as founded though. Rule of thumb, NEVER use the word will in documentation. Always describe features as already there. Committing the menu-desktop changes for now. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Dan Espen des...@verizon.net wrote: Thomas Funk t.f...@web.de writes: Try the examples in the manpage you requested to get an overview about the look and feel of the different display possibilities. The page is created with asciidoc but in Groff format so you can look into it with man ^^ The man page is a LOT less readable than I expected it to be. Does every period have to be escaped? Not real happy with the result. What do you mean with Does every period have to be escaped ? Do you mean the man page file itself or if you use $./man fvwm-menu-desktop.1 I can send you the asciidoc file. It's plain text with some asciidoc formatings. I have no clue how to write groff. So I use the easier way via asciidoc. Thomas
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: Dan Espen des...@verizon.net wrote: Thomas Funk t.f...@web.de writes: Try the examples in the manpage you requested to get an overview about the look and feel of the different display possibilities. The page is created with asciidoc but in Groff format so you can look into it with man ^^ The man page is a LOT less readable than I expected it to be. Does every period have to be escaped? Not real happy with the result. What do you mean with Does every period have to be escaped ? Do you mean the man page file itself or if you use $./man fvwm-menu-desktop.1 I can send you the asciidoc file. It's plain text with some asciidoc formatings. I have no clue how to write groff. So I use the easier way via asciidoc. I guess I mis-understood. If you are writing the man page as asciidoc, that's what should get checked in. I'm guessing the other fvwm developers are okay with going to asciidoc? -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
On 19 July 2012 22:11, Dan Espen des...@verizon.net wrote: I'm guessing the other fvwm developers are okay with going to asciidoc? No. I have an attempt at this, but it's not finished. We either use groff or nothing, and I don't mean groff backported from some conversion tool. If you don't know groff, start learning. The alternative approach is to put the fvwm-menu-desktop under docbook's control. These are the only two options. -- Thomas Adam
Re: First try of fvwm-menu-desktop which creates a full menu
Am 19.07.2012 22:38, schrieb Dan Espen: Thomas Funk t.f...@web.de writes: Hi Dan! I've attached the advised patch related to your last CVS version of fvwm-menu-desktop. It includes the needed functionality to response to the attached configuration tool for fvwm-menu-desktop. Two new options: - get-menus [selected, all] to send the found menus to the config gui - set-menus [filelist] to tell fvwm-menu-desktop which menus should be build The usage prompt for get-menus says it prints a comma separated list, but I get a space separated list. Uups, forgot to change to 'space separated list'. Would you change it, please? The usage prompt says selected is an option but it looks like anything other than all is what it looks for. I'm not clear on what the selected option is doing. Yes, right. You can use every word you want but it needs a word because I sample in parsemenus() for not get_menus == '' (it's for both). As the user doesn't know it I decided to use 'selected' for the other possibility. You're English it pretty good. No such word as founded though. Thanks for the compliment :-) I try to reduce the german part of my english to a bearable level with talking and writing ^^ Rule of thumb, NEVER use the word will in documentation. Always describe features as already there. Ah, ok. Not known. Thanks for the tip. Thomas
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Adam tho...@fvwm.org writes: On 19 July 2012 22:11, Dan Espen des...@verizon.net wrote: I'm guessing the other fvwm developers are okay with going to asciidoc? No. I have an attempt at this, but it's not finished. We either use groff or nothing, and I don't mean groff backported from some conversion tool. If you don't know groff, start learning. I thought since you were making the attempt, you thought asciidoc would be a good direction to go in. The alternative approach is to put the fvwm-menu-desktop under docbook's control. These are the only two options. Okay with me. TF: All I really need is the words. I can add (t)groff/man markup as needed. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
On Thu, Jul 19, 2012 at 05:48:25PM -0400, Dan Espen wrote: Thomas Adam tho...@fvwm.org writes: On 19 July 2012 22:11, Dan Espen des...@verizon.net wrote: I'm guessing the other fvwm developers are okay with going to asciidoc? No. I have an attempt at this, but it's not finished. We either use groff or nothing, and I don't mean groff backported from some conversion tool. If you don't know groff, start learning. I thought since you were making the attempt, you thought asciidoc would be a good direction to go in. Yes it will be when it's ready. It's pretty much done, bar some plugging in scripts so it builds. But until I can finish that and then rip out the other docs, having it in Asciidoc means we can't use it, and that's bad. -- 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: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: Am 19.07.2012 22:38, schrieb Dan Espen: Thomas Funk t.f...@web.de writes: Hi Dan! I've attached the advised patch related to your last CVS version of fvwm-menu-desktop. It includes the needed functionality to response to the attached configuration tool for fvwm-menu-desktop. Two new options: - get-menus [selected, all] to send the found menus to the config gui - set-menus [filelist] to tell fvwm-menu-desktop which menus should be build The usage prompt for get-menus says it prints a comma separated list, but I get a space separated list. Uups, forgot to change to 'space separated list'. Would you change it, please? As you probably know by now, I did. The usage prompt says selected is an option but it looks like anything other than all is what it looks for. I'm not clear on what the selected option is doing. Yes, right. You can use every word you want but it needs a word because I sample in parsemenus() for not get_menus == '' (it's for both). As the user doesn't know it I decided to use 'selected' for the other possibility. I don't see get-menus in the man page. I think you want the option to be: --get-menus all | desktop with an error for any other value. Rule of thumb, NEVER use the word will in documentation. Always describe features as already there. Ah, ok. Not known. Thanks for the tip. Pet peeve. We tend to write documentation describing new features as this will do X, but when the reader sees it, it does do X. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Adam tho...@fvwm.org writes: On Thu, Jul 19, 2012 at 05:48:25PM -0400, Dan Espen wrote: Thomas Adam tho...@fvwm.org writes: On 19 July 2012 22:11, Dan Espen des...@verizon.net wrote: I'm guessing the other fvwm developers are okay with going to asciidoc? No. I have an attempt at this, but it's not finished. We either use groff or nothing, and I don't mean groff backported from some conversion tool. If you don't know groff, start learning. I thought since you were making the attempt, you thought asciidoc would be a good direction to go in. Yes it will be when it's ready. It's pretty much done, bar some plugging in scripts so it builds. But until I can finish that and then rip out the other docs, having it in Asciidoc means we can't use it, and that's bad. If we add an asciidoc file, I'd expect the Makefile to be modified to produce the man page or html as required. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
2012/7/17 Dan Espen des...@verizon.net wrote: Thomas Adam tho...@fvwm.org writes: On Mon, Jul 16, 2012 at 06:23:17PM -0400, Dan Espen wrote: Thomas Adam tho...@fvwm.org writes: On Mon, Jul 16, 2012 at 11:35:20PM +0200, Thomas Funk wrote: Regenerate Menu(s) Why can this not be an on-disk cache or something instead of requiring the user to care to regenerate the menus? The purpose of Regenerate Menus is to get a new menu after you've installed a new package. A cache would only make the problem worse. Actually, no. Effectively this is what Debian does with its menuing system and it works just fine. I see no reason why we need an explicit regeneration of these menus. I'm not following. If I install a new package, say Evolution, it won't be in the Fvwm menus. Not until the menu is regenerated. How is a user supposed to get a new menu with Evolution in it? I've looked a little around and the easiest way is to scan the $XDG_DATA_HOME ($HOME/.local/share) and $XDG_DATA_DIRS (/usr/local/share/, /usr/share/) periodically if .desktop files are added/removed there. For that an own module for menu creation/changing/updating will be beneficial ;-). Due to the fact that I am working on that stuff I would start with such a module. But could take a little while ;-) ... In the meantime it would be fine if anybody who's interested in helping would test fvwm-menu-desktop and report bugs here on the list. Dan, I will send you a small bugfix patch for the actual CVS version. The fixes are in the last patch included but as this is a proof of concept would be better to seperate them. Thomas
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.funk...@googlemail.com writes: 2012/7/17 Dan Espen des...@verizon.net wrote: Thomas Adam tho...@fvwm.org writes: On Mon, Jul 16, 2012 at 06:23:17PM -0400, Dan Espen wrote: Thomas Adam tho...@fvwm.org writes: On Mon, Jul 16, 2012 at 11:35:20PM +0200, Thomas Funk wrote: Regenerate Menu(s) Why can this not be an on-disk cache or something instead of requiring the user to care to regenerate the menus? The purpose of Regenerate Menus is to get a new menu after you've installed a new package. A cache would only make the problem worse. Actually, no. Effectively this is what Debian does with its menuing system and it works just fine. I see no reason why we need an explicit regeneration of these menus. I'm not following. If I install a new package, say Evolution, it won't be in the Fvwm menus. Not until the menu is regenerated. How is a user supposed to get a new menu with Evolution in it? I've looked a little around and the easiest way is to scan the $XDG_DATA_HOME ($HOME/.local/share) and $XDG_DATA_DIRS (/usr/local/share/, /usr/share/) periodically if .desktop files are added/removed there. Polling for changes? Nope, I'd rather require specific user action. For that an own module for menu creation/changing/updating will be beneficial ;-). Due to the fact that I am working on that stuff I would start with such a module. But could take a little while ;-) ... In the meantime it would be fine if anybody who's interested in helping would test fvwm-menu-desktop and report bugs here on the list. Dan, I will send you a small bugfix patch for the actual CVS version. The fixes are in the last patch included but as this is a proof of concept would be better to seperate them. Okay. As you've seen I'm a bit slow to look at these things. I haven't looked at your latest work yet. I will get to it though. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.funk...@googlemail.com wrote:
Dan, I will send you a small bugfix patch for the actual CVS
version. The
fixes are in the last patch included but as this is a proof of concept
would be better to seperate them.
Okay. As you've seen I'm a bit slow to look at these things.
I haven't looked at your latest work yet.
I will get to it though.
Attached the patch for
- fixing bug, that empty menus were generated
- fix your fixme for Regenerate Applications Menu
- add forgotten --version
- add forgotten -t for title option
- update help
Thomas
--- /media/daten/shared/sourcen/cvs/fvwm/bin/fvwm-menu-desktop.in 2012-07-13 13:14:31.428392223 +0200
+++ fvwm-menu-desktop.in.p4.1.py 2012-07-18 00:20:03.011125095 +0200
@@ -97,7 +97,7 @@
try:
opts, args = getopt.getopt(sys.argv[1:], hs:t:vw,
- [help, verbose, enable-mini-icons, with-titles, verbose,
+ [help, verbose, enable-mini-icons, with-titles, verbose, version,
desktop=, size=, theme=, install-prefix=, menu-type=, title=]+obs_args+equaled_obs_parms)
except getopt.GetoptError, err:
# print help information and exit:
@@ -105,6 +105,7 @@
print usage
sys.exit(2)
global verbose, force, size, theme, icon_dir, top, install_prefix, menu_type, with_titles, menu_entry_count
+version = 2.0
verbose = False
force = False
desktop=''
@@ -123,11 +124,14 @@
elif o in (-h, --help) :
print usage
sys.exit()
+elif o in (--version) :
+print fvwm-menu-desktop version + version
+sys.exit()
elif o in (--enable-mini-icons) :
force=True
elif o in (--desktop) :
desktop=a
-elif o in (--title) :
+elif o in (-t, --title) :
top=a
elif o in (--install-prefix) :
if a and not os.path.isabs(a):
@@ -364,6 +368,7 @@
printtext('+ %s%s %s' % (name, iconfile, command))
def parsemenus(menulist, desktop):
+global menu_entry_count
if len(menulist) == 1:
# user defines only one special menu
parsemenu(xdg.Menu.parse(menulist[0]), top)
@@ -385,6 +390,7 @@
if not menu_entry_count == 0:
new_toptitles.append(title)
new_menulist.append(menu)
+menu_entry_count = 0
else:
vprint( Menu is empty - won't be used!)
@@ -402,8 +408,10 @@
def parsemenu(menu, name=, title=):
global menu_entry_count
m = re.compile('%[A-Z]?', re.I) # Pattern for %A-Z (meant for %U)
+gen_name = ''
if not name :
name = menu.getPath()
+gen_name = menu.getPath(True)
if not title:
title = name
printtext('DestroyMenu %s' % name)
@@ -422,15 +430,16 @@
menu_entry_count += 1
else:
printtext('# not supported: ' + str(entry))
+
+if gen_name == 'System':
+printmenu(Regenerate XDG Menu(s), system-software-update, FvwmForm FvwmForm-Desktop )
+
printtext('')
for entry in menu.getEntries():
if isinstance(entry, xdg.Menu.Menu):
parsemenu(entry)
-if (re.search('.*System Tools$',name)) : # fixme, find a better way to do this?
-printmenu(Regenerate Applications Menu, , FvwmForm FvwmForm-Desktop )
-
usage=
A script which parses xdg menu definitions to build
the corresponding fvwm menus.
@@ -443,13 +452,13 @@
For the system wide menus use /etc/xdg/menus/
--desktop NAMEdesktop name to build menus for:
gnome, kde, xfce, lxde, debian, etc.
---menu-type NAME applications (default), settings, preferences, etc.
+--menu-type NAME applications, settings, preferences, etc.
--theme NAME gnome (default), oxygen, etc. Don't use hicolor.
It's the default fallback theme if no icon will be found.
-w, --with-titles generate menus with titles.
--enable-mini-icons enable mini-icons in menu
--s, --sizeset size of mini-icons in menu. Default is 24.
---title NAME menu title of the top menu used by Popup command.
+-s, --size NUMset size of mini-icons in menu. Default is 24.
+-t, --title NAME menu title of the top menu used by Popup command.
Default is FvwmMenu
-v, --verbose run and display debug info on STDERR
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: Dan Espen des...@verizon.net wrote: Polling for changes? Nope, I'd rather require specific user action. Suggestion: First step We release fvwm-menu-desktop as is or with my last patch and the reworked FvwmPerl script - user must update manually the menu(s) Second step In the next or ensuing release with the FvwmMenu module which polls e.g. every 5 min /usr/share/applications, /usr/local/share/applications and $HOME/.local/share for changes. This poll takes not much cpu load and time. I've tested this with time find /usr/share/applications -name *.desktop |wc -l 189 real0m0.088s user0m0.000s sys 0m0.004s And if the count in/decrease it starts a silent regenerate. So, user doesn't need updating after installing/removing a new package. But can regenerate manually already. Okay. As you've seen I'm a bit slow to look at these things. I haven't looked at your latest work yet. I will get to it though. And ... what do you think about this proof of concept apart from that it is a little bit slow (will test Thomas' suggestion with IPC::Run) and not FvwmPerl like? I'm guessing dbus or some other abomination does the job for the desktops... -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
2012/7/16 Dan Espen des...@verizon.net wrote: The code to generate all menus looks like it needs work. I find the same menus repeated in multiple places. Yes I saw that but the multiple appearances are a result of the xml menus by themselve. Depending whether they are used for, the menus are generated as the sources were. One possibility could be to create the menus and then search for double entries, eliminate them and if a menu is empty delete it. But the actual menu built process took on my Dual core system 10-15 seconds (with icon conversion). With this selection certainly 25-30. For me too long. And for slower machines far too much. I realize the XDG spec isn't helping but would some trimming be in order? Personally I thought that fvwm-menu-desktop shall provide a possibility for the user to choose the menus she/he wants. And that's what the tool does. But we shouldn't strip down the menus. In the next days I will present a fvwm-menu-desktop config tool based on FvwmPerl which shows all founded menus on the system and let the user decide which menu/menus she/he wants to create and how. Perhaps that would be sufficient enough ... Thomas
Re: First try of fvwm-menu-desktop which creates a full menu
On 16 July 2012 15:37, Thomas Funk t.funk...@googlemail.com wrote: 2012/7/16 Dan Espen des...@verizon.net wrote: The code to generate all menus looks like it needs work. I find the same menus repeated in multiple places. Yes I saw that but the multiple appearances are a result of the xml menus by themselve. Depending whether they are used for, the menus are generated as the sources were. Isn't this in the XDG spec as to which menus appear where, in categories? I'm sure it is. One possibility could be to create the menus and then search for double entries, eliminate them and if a menu is empty delete it. But the actual No. That's just admitting to not wanting to fix the problem. :) In the next days I will present a fvwm-menu-desktop config tool based on FvwmPerl which shows all founded menus on the system and let the user decide which menu/menus she/he wants to create and how. That might be useful longer-term, but I think I'd rather see the basics of this menu generation working first of all. -- Thomas Adam
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Adam tho...@fvwm.org writes: On 16 July 2012 15:37, Thomas Funk t.funk...@googlemail.com wrote: 2012/7/16 Dan Espen des...@verizon.net wrote: The code to generate all menus looks like it needs work. I find the same menus repeated in multiple places. Yes I saw that but the multiple appearances are a result of the xml menus by themselve. Depending whether they are used for, the menus are generated as the sources were. Isn't this in the XDG spec as to which menus appear where, in categories? I'm sure it is. One possibility could be to create the menus and then search for double entries, eliminate them and if a menu is empty delete it. But the actual No. That's just admitting to not wanting to fix the problem. :) ? In the next days I will present a fvwm-menu-desktop config tool based on FvwmPerl which shows all founded menus on the system and let the user decide which menu/menus she/he wants to create and how. That might be useful longer-term, but I think I'd rather see the basics of this menu generation working first of all. The basics work pretty well. I really think the XDG folks have paid little attention to the concept of a main menu or any organization at that level. On my Fedora system I have Preferences as a top level menu now. I also have Settings at the same level. Inside Settings are Preferences and Administration. Which Preferences should be removed? Despite the duplication, the current default of generating everything at least gets me at all the menus the other desktops support. I hate hunting for the right GUI configuration tool when I can't figure out the right command line tool. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Dan Espen des...@verizon.net wrote: On my Fedora system I have Preferences as a top level menu now. I also have Settings at the same level. Inside Settings are Preferences and Administration. Which Preferences should be removed? What I could imagine is, to scan the xml menus and build our own Fvwm xml menu and then generate this with the python process. But which menu should the main one to extend? How does the parsing of the files are running? and in which data structure do we organize it? No small undertaking ... Thomas
Re: First try of fvwm-menu-desktop which creates a full menu
Hi Dan!
I've attached the advised patch related to your last CVS version of
fvwm-menu-desktop. It includes the needed functionality to response to
the attached configuration tool for fvwm-menu-desktop. Two new options:
- get-menus [selected, all] to send the found menus to the config gui
- set-menus [filelist] to tell fvwm-menu-desktop which menus should be
build
Also another option --insert-in-menu NAME. This was formed while writing
the manpage you requested. Normally the menus are located in a menu as
sub menus. This is ok but it looks quiet better if they appear directly
in e.g. the root menu - less one level.
Normally:
Root Menu
-
XDG Menus Gnome-applications
Gnome-settings
Gnomecc
--
Regenerate Menu(s)
With this option:
Root Menu
-
Gnome-applications
Gnome-settings
Gnomecc
--
Regenerate Menu(s)
This works also for single menus. With the applications menu for example
it moves all sub menus into the Root menu like in other DEs:
Root Menu
-
Office
Debian
System
Multimedia
:
The only difference to multiple menus is, that the 'Regeneration Menu'
entry will be omitted because if you want a series of single menus it
would look strange if the regeneration menu appears each time after a
menu.
About your 'Regeneration Menu' - it has been moved from 'Systems' to the
bottom of the top menu because it's not easy to find it. In Fedora it's
really a problem you know ...
It's only a nomination by me. Thoughts about this thingi are welcome.
Try the examples in the manpage you requested to get an overview about
the look and feel of the different display possibilities. The page is
created with asciidoc but in Groff format so you can look into it with
man ^^
Also attached is the config tool. It's based on FvwmPerl and creates a
FvwmForm-Desktop related to the available menus on the system. I'm not
the Perl Monger so code could be optimized. If you or Thomas would have
a look into the Perl part it would be nice.
I've implemented in this patch the --version parameter too because it
was forgotten. About the numbering - I set it to 2.0. Or should we use
the old format: 2.6.6?
also a bug fix for empty menus. I forgot to reset the counter after a
menu build. Therfore empty menus appear anyway.
Thomas
--- fvwm-menu-desktop.in.orig 2012-07-14 02:26:57.332795696 +0200
+++ fvwm-menu-desktop.in.py 2012-07-16 22:17:49.459889445 +0200
@@ -43,6 +43,7 @@
import os
from xdg.DesktopEntry import *
import fnmatch
+import time
def main ():
@@ -97,14 +98,17 @@
try:
opts, args = getopt.getopt(sys.argv[1:], hs:t:vw,
- [help, verbose, enable-mini-icons, with-titles, verbose,
-desktop=, size=, theme=, install-prefix=, menu-type=, title=]+obs_args+equaled_obs_parms)
+ [help, verbose, enable-mini-icons, with-titles, version,
+desktop=, size=, theme=, install-prefix=, menu-type=,
+title=, get-menus=, set-menus=, insert-in-menu=]+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, menu_type, with_titles, menu_entry_count
+global verbose, force, size, theme, icon_dir, top, install_prefix, menu_type, menu_list_length
+global with_titles, menu_entry_count, get_menus, timestamp, set_menus, printmode, insert_in_menu
+version = 2.0
verbose = False
force = False
desktop=''
@@ -112,10 +116,15 @@
theme='gnome'
icon_dir=~/.fvwm/icons
top='FvwmMenu'
+insert_in_menu = False
install_prefix = ''
menu_type = ''
with_titles = False
menu_entry_count = 0
+menu_list_length = 0
+get_menus = ''
+printmode = True
+set_menus = []
for o, a in opts:
if o == -v:
@@ -123,12 +132,27 @@
elif o in (-h, --help) :
print usage
sys.exit()
+elif o in (--version) :
+print fvwm-menu-desktop version + version
+sys.exit()
elif o in (--enable-mini-icons) :
force=True
+elif o in (--insert-in-menu) :
+top=a
+insert_in_menu = True
elif o in (--desktop) :
desktop=a
-elif o in (--title) :
+elif o in (-t, --title) :
top=a
+elif o in (--get-menus) :
+get_menus=a
+printmode = False
+elif o in (-s,--size) :
+size = int(a)
+elif o in (--set-menus) :
+if a[-1] == ' ':
+a = a[:-1]
+set_menus=a.split(' ')
elif o in (--install-prefix) :
if
Re: First try of fvwm-menu-desktop which creates a full menu
On Mon, Jul 16, 2012 at 11:57:43PM +0200, Thomas Funk wrote: How? No examples found ... What is it you can't infer from the following? man FvwmPerl and: http://fvwm.org/documentation/perllib/ I'm really really short on time at the moment, but you need to use either or both of the above, because the perl script as-is isn't quite right yet. I'm sure it works, but we have frameworks for dealing with this without reinventing the wheel, so let's use them. -- 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: First try of fvwm-menu-desktop which creates a full menu
Thomas Adam tho...@fvwm.org writes: On Mon, Jul 16, 2012 at 11:35:20PM +0200, Thomas Funk wrote: Regenerate Menu(s) Why can this not be an on-disk cache or something instead of requiring the user to care to regenerate the menus? The purpose of Regenerate Menus is to get a new menu after you've installed a new package. A cache would only make the problem worse. I'm guessing that there is some way you can get auto-notification of a menu update but I don't know what that is. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Adam tho...@fvwm.org writes: On Mon, Jul 16, 2012 at 06:23:17PM -0400, Dan Espen wrote: Thomas Adam tho...@fvwm.org writes: On Mon, Jul 16, 2012 at 11:35:20PM +0200, Thomas Funk wrote: Regenerate Menu(s) Why can this not be an on-disk cache or something instead of requiring the user to care to regenerate the menus? The purpose of Regenerate Menus is to get a new menu after you've installed a new package. A cache would only make the problem worse. Actually, no. Effectively this is what Debian does with its menuing system and it works just fine. I see no reason why we need an explicit regeneration of these menus. I'm not following. If I install a new package, say Evolution, it won't be in the Fvwm menus. Not until the menu is regenerated. How is a user supposed to get a new menu with Evolution in it? -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.funk...@googlemail.com writes: 2012/7/6 Dan Espen des...@verizon.net wrote: The code to generate all menus looks like it needs work. I find the same menus repeated in multiple places. For example, with no arguments: AddToMenu FvwmStart-here + Preferences Popup Preferences AddToMenu FvwmSettings + Preferences Popup Preferences I realize the XDG spec isn't helping but would some trimming be in order? -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Dan Espen des...@verizon.net wrote:
So maybe you can clean up this version a bit more
and submit as a patch?
Attached. It's diffed against the latest CVS version of fvwm-menu-desktop.in
This popped out:
This can't be right:
if len(menulist) == 0:
sys.stderr.write(install_prefix+/+desktop+-+menu_type+.menu not
available on this system. Exiting...\n)
For example:
python fvwm-menu-desktop.in.py --menu-type notfound
/debian-notfound.menu not available on this system. Exiting...
Fixed.
Not sure what this is:
python fvwm-menu-desktop.in.py --menu-type system-settings
Traceback (most recent call last):
File fvwm-menu-desktop.in.py, line 470, in module
main()
File fvwm-menu-desktop.in.py, line 170, in main
menulist, desktop = getmenulist(desktop, menu_type)
File fvwm-menu-desktop.in.py, line 285, in getmenulist
desktop_dict[de_highest].add(menu)
KeyError: 'debian'
This happens because the the 'others' and 'none' were ignored in the
weighting. I did that before I sorted the keys to prevent that in the
first loop 'none' or 'others' are the start menus. And so in your case
debian was the winner but hasn't any menu and therefore no dict entry
exists. Only 'others'. So no key 'debian' - KeyError: 'debian'
Fixed.
1. We have less chance of losing the #!@PYTHON@ line.
In the CVS version #!/usr/bin/python is set instead of #!@PYTHON@
Should changed back?
Meanwhile, the man page is about half done.
Updated the fvwm-menu-desktop help also.
If we go this route,
it would be nice if you included some of the comments
you made. At least for me, not all of this was obvious.
Done.
Also I fixed some issues I found while testing:
- The not working regex with trailing slash in install-prefix
interpretation.
- Eliminate '%' behind menu entries if no icon will be found.
- Wrong conditional expression which tests the availability of
$XDG_MENU_PREFIX.
Thomas
--- fvwm-menu-desktop.orig.py 2012-07-03 22:56:01.316247721 +0200
+++ Old/fvwm-menu-desktop.in.p4.py 2012-07-09 23:55:48.005438739 +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',
@@ -97,14 +97,14 @@
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)
+ [help, verbose, enable-mini-icons, with-titles, verbose,
+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
print usage
sys.exit(2)
-global verbose, force, size, theme, icon_dir, top, install_prefix, menu_type, with_titles
+global verbose, force, size, theme, icon_dir, top, install_prefix, menu_type, with_titles, menu_entry_count
verbose = False
force = False
desktop=''
@@ -112,9 +112,10 @@
theme='gnome'
icon_dir=~/.fvwm/icons
top='FvwmMenu'
-install_prefix = '/etc/xdg/menus/'
-menu_type = 'applications'
+install_prefix = ''
+menu_type = ''
with_titles = False
+menu_entry_count = 0
for o, a in opts:
if o == -v:
@@ -125,14 +126,15 @@
elif o in (--enable-mini-icons) :
force=True
elif o in (--desktop) :
-#?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
# add trailing slash if not there already
-if (not re.search('.*[.]/$',a)) : # no trailing slash
-a=a+'/'
+if not a[-1] == '/' : # trailing slash
+a=a + '/'
install_prefix = a
elif o in (-s,--size) :
@@ -143,33 +145,177 @@
menu_type = a
elif o in (-w,--with-titles) :
with_titles = True
+elif o in (--verbose) :
+verbose = True
elif o in (str(dashed_obs_args+dashed_obs_parms)) :
# Ignore
sys.stderr.write( Warning: Arg +o+ is obsolete and ignored\n )
else:
assert False, unhandled option
+
+xdg_menu_prefix = (os.environ['XDG_MENU_PREFIX'] if os.environ.has_key('XDG_MENU_PREFIX') else '')
-check=install_prefix+desktop+menu_type+'.menu'
-menu = checkmenu(check)
+# First check if no user
Re: First try of fvwm-menu-desktop which creates a full menu
2012/7/6 Dan Espen des...@verizon.net wrote: Your code is pretty ingenious, and it solves the single biggest issue I had with the xdg spec. Ie. if finds all the menus a WM might want to make visible to the user. I'm very pleased to hear that the implementation suits your needs :-) If we go this route, it would be nice if you included some of the comments you made. At least for me, not all of this was obvious. Will do that then. I was thinking of leaving the choice of menus to generate up to the user. Of course the distros could do the logical thing and create a single menu hierarchy or at least set some rules. Yes, I thought the same. Not known how to do it with FvwmForm or FvwmScript but I could implement an option in fvwm-menu-desktop to printout a string with menus found on the system like --show-menus=[all, de-selected] and then the user can select/deselect via checkboxes which menus she/he wants to display. For that I have to rewrite the --desktop and --menu-type functionality to handle lists then. You'd want something like fvwm-menu-directory front ending FvwmForm. With fvwm-menu-desktop it's better because the menus can checked if they're empty. I got a little feedback from the xdg folks: ... It doesn't sound to me like they are going to address the issue in the near term. Yep, looks so. I'd like to implement what's best for Fvwm. That's also my intend. If XDG gets it's act together later we can replace what we've done with something simpler. I don't think they will change it in the future anymore. So maybe you can clean up this version a bit more and submit as a patch? I've submitted the patch in another email - Second try ... but afterwards it was silly to put it in another thread because it belongs to this one. Sorry about that. Won't be happen anymore. Would you answer that email in this thread then? Or is this yet impossible now? Thanks for your efforts, and I'm getting a few python lessons along the way... You're welcome ^^ Thomas
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: Dan Espen des...@verizon.net writes: It' works over file weighting because it's too complicated to check distribution relevant paths for finding the default desktop. Can you explain the weighting in terms a user would understand. I read the code once and still didn't have a clue. Your code is pretty ingenious, and it solves the single biggest issue I had with the xdg spec. Ie. if finds all the menus a WM might want to make visible to the user. If we go this route, it would be nice if you included some of the comments you made. At least for me, not all of this was obvious. I was thinking of leaving the choice of menus to generate up to the user. Of course the distros could do the logical thing and create a single menu hierarchy or at least set some rules. Yes, I thought the same. Not known how to do it with FvwmForm or FvwmScript but I could implement an option in fvwm-menu-desktop to printout a string with menus found on the system like --show-menus=[all, de-selected] and then the user can select/deselect via checkboxes which menus she/he wants to display. For that I have to rewrite the --desktop and --menu-type functionality to handle lists then. You'd want something like fvwm-menu-directory front ending FvwmForm. I got a little feedback from the xdg folks: DE I just don't get the logic of having a standard for DE just the applications category. I believe the rationale is that only applications.menu is reserved by the spec, and XDG_MENU_PREFIX was a way to handle conflicts between different applications.menu shipped by different desktops. No other menu name is defined in the spec, and so we were instead relying on the fact that desktops would not create conflicts. That being said, I don't think I'd be opposed to using XDG_MENU_PREFIX for all .menu files. We should just make sure that it doesn't create any compatibility issue. It doesn't sound to me like they are going to address the issue in the near term. I'd like to implement what's best for Fvwm. If XDG gets it's act together later we can replace what we've done with something simpler. So maybe you can clean up this version a bit more and submit as a patch? Thanks for your efforts, and I'm getting a few python lessons along the way... -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: Hi, attached is my first try of a fvwm-menu-desktop which creates a menu with all desktop related menus (if they have entries). Interesting. It' works over file weighting because it's too complicated to check distribution relevant paths for finding the default desktop. Can you explain the weighting in terms a user would understand. I read the code once and still didn't have a clue. It works under OpenSuse, Fedora, Mandriva and Debian fine and creates a menu with a structure like this: Fedora 14 example Root: Documentation Gnome-applications Gnome-screensavers Gnomecc Preferences Server-settings Settings Start-here System-settings I was thinking of leaving the choice of menus to generate up to the user. Of course the distros could do the logical thing and create a single menu hierarchy or at least set some rules. This popped out: This can't be right: if len(menulist) == 0: sys.stderr.write(install_prefix+/+desktop+-+menu_type+.menu not available on this system. Exiting...\n) For example: python fvwm-menu-desktop.in.py --menu-type notfound /debian-notfound.menu not available on this system. Exiting... ^^^ Not sure what this is: python fvwm-menu-desktop.in.py --menu-type system-settings Traceback (most recent call last): File fvwm-menu-desktop.in.py, line 470, in module main() File fvwm-menu-desktop.in.py, line 170, in main menulist, desktop = getmenulist(desktop, menu_type) File fvwm-menu-desktop.in.py, line 285, in getmenulist desktop_dict[de_highest].add(menu) KeyError: 'debian' I've attached the complete file and not a patch because too much changed and it's easier for testing ^^ Not good. Doesn't contain the Usage fixes I recently committed. I'm not sure how you're testing, but there's a hint at the bottom of the file that Emacs reacts to. If you test that way there are 2 benefits: 1. We have less chance of losing the #!@PYTHON@ line. 2. Diffs will work without me having to change the file names. The other functionality with --desktop=whatever_desktop_name, --menu-type=whatever_menu_name or/and --install-prefix=whatever_path should work also. Dan, I don't know if applications-gnome.menu would be created. In my simulation it is listed but there could be problems with the xdg-automatism. See here: http://lists.fedoraproject.org/pipermail/devel/2011-August/155342.html https://bugzilla.redhat.com/show_bug.cgi?id=754845 I see. If it's been declared a bug, and it looks like it, we can just ignore applications-gnome because it will probably go away. And I found a very interesting entry at the end here: http://people.gnome.org/~walters/0001-Ship-applications-gnome.menu.patch which could be explain the change from gnome-applications.menu to applications-gnome.menu: +* Mon Apr 11 2011 Colin Walters walt...@verbum.org - 3.0.0-2 +- Ship applications-gnome.desktop; we don't want GNOME 3 to use redhat-menus. I must be dull. Can't see why they did that. I've subscribed to the xdg mailing list, asked my question. Still waiting for an answer. Meanwhile, the man page is about half done. -- Dan Espen
