Re: First try of fvwm-menu-desktop which creates a "full" menu

[Thomas Funk]

Hi Dan,

I've made a Fvwm install session at a friend of mine and we found a
small but important bug at menu choosing in fvwm-menu-desktop.in.

He has an Ubuntu Studio 11.10 system. Default desktop is Xfce. There're
3(!) menu location:
$HOME/.config/menus: no menus
/etc/xdg/menus: kde-information.menu, kde4-applications.menu,
applications.menu, xfce-applications.menu
/usr/share/ubuntustudio-menu/menus: applications.menu, 
xfce-applications.menu


The /usr/share/ubuntustudio-menu/menus/applications.menu is a copy of
/etc/xdg/menus/applications.menu and the xfce-applications.menu is a link
to it.

The actual implementation deletes from /etc/xdg/menus applications.menu
and xfce-applications.menu which isn't correct - only the users
files have higher priority than the system ones (Xdg spec). The others
in contrast have lower prio than the system ones because we have noticed
that some sub menus are missed in the /usr/share/ubuntustudio-menu/menus/
xfce-applications.menu - as it is a link to applications.menu and not to
/etc/xdg/menus/xfce-applications.menu which is the newest but it was
removed! From that point of view the files in
/usr/share/ubuntustudio-menu/menus must not deleted from the /etc/xdg/menus
list.

With the attached patch the old behaviour is changed like above described.
and /etc/xdg/menus/xfce-applications.menu appears correctly in the list
again.

As we don't know if in the third location important menus are found I have
commented out the else branch. So these files are listed also in
fvwm-menu-desktop-config.fpl

I hope the explanations were comprehensible ... if not ask.

Thomas

--- /media/daten/shared/sourcen/cvs/fvwm/bin/fvwm-menu-desktop.in	2012-07-28 02:59:08.872390035 +0200
+++ fvwm-menu-desktop.in.py	2012-07-28 03:42:07.193278385 +0200
@@ -243,10 +243,13 @@
 desktop_dict = {}
 if not found_menus == 0:
 all_menus = []
-# remove all menus in /etc/xdg/menus imenudict['/etc/xdg/menus']menudict['/etc/xdg/menus']f exist in user dir
+# remove all menus in /etc/xdg/menus if exist in user dir
 for path in menudict.keys():
 if not path == '/etc/xdg/menus':
-menudict['/etc/xdg/menus'] = menudict['/etc/xdg/menus'] - menudict[path]
+if path == os.path.join(os.getenv("HOME"), '.config/menus'):
+menudict['/etc/xdg/menus'] = menudict['/etc/xdg/menus'] - menudict[path]
+#else:
+#menudict[path] = menudict[path] - menudict['/etc/xdg/menus']
 for menu in list(menudict[path]):
 all_menus.append(path + '/' + menu)
 

Re: First try of fvwm-menu-desktop which creates a "full" menu

[Thomas Funk]

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

[Dan Espen]

Thomas Adam  writes:

> On 25 July 2012 18:38, Thomas Funk  wrote:
>>> Dan Espen wrote:
>>> Thomas Adam made some comments about using FvwmPerl.  Is that resolved?
>
> No -- and as such, until it starts to use perllib and/or FvwmPerl,
> it's not ready.  There is *no* reason why we wouldn't dog-food our own
> implementation of interfacing to FVWM, other than the individual
> developer concerned didn't understand it.  We _have_ a framework to do
> all of the functionality the code currently uses; it's high-time we
> use it.
>
>> I've fixed all what Thomas suggested except the part to do the complete
>> stuff with the perllib framework. That needs a little bit more time.
>
> But that's the entirety of this file, as far as I am concerned.  A
> pretty important part, too.
>
>> I hope it is ok for Thomas that you want to commit it because it's only
>> an interim solution.
>
> Until this is fixed, I would rather this wasn't put in CVS at all.  As
> I've mentioned my time is limited, but if I have to roll up my sleeves
> and take responsibility for this, I don't mind.  I'd rather not
> though, but either way, someone should let me know if I have to.

Okay having read the FvwmPerl man page I see that "TF" has followed the
usage pattern in the tests/perl/xmessage.fpl example.

It looks like the only interaction this module needs with Fvwm is to
send the completed FvwmForm to Fvwm for execution.  The module does this
using the FvwmPerl "::command" interface.

What's wrong with that?

It looks like it could have been written as a script in /bin and
been invoked with Piperead to get the same effect.

-- 
Dan Espen

Re: First try of fvwm-menu-desktop which creates a "full" menu

[Dan Espen]

Thomas Funk  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 Adam]

On 25 July 2012 18:38, Thomas Funk  wrote:
>> Dan Espen wrote:
>> Thomas Adam made some comments about using FvwmPerl.  Is that resolved?

No -- and as such, until it starts to use perllib and/or FvwmPerl,
it's not ready.  There is *no* reason why we wouldn't dog-food our own
implementation of interfacing to FVWM, other than the individual
developer concerned didn't understand it.  We _have_ a framework to do
all of the functionality the code currently uses; it's high-time we
use it.

> I've fixed all what Thomas suggested except the part to do the complete
> stuff with the perllib framework. That needs a little bit more time.

But that's the entirety of this file, as far as I am concerned.  A
pretty important part, too.

> I hope it is ok for Thomas that you want to commit it because it's only
> an interim solution.

Until this is fixed, I would rather this wasn't put in CVS at all.  As
I've mentioned my time is limited, but if I have to roll up my sleeves
and take responsibility for this, I don't mind.  I'd rather not
though, but either way, someone should let me know if I have to.

Kindly,

-- Thomas Adam

Re: First try of fvwm-menu-desktop which creates a "full" menu

[Thomas Funk]

"Dan Espen"  wrote
> I think it's time for me to commit this fpl file.

before you can do it, two things should be done:
1. convert it to unix format. Thunderbird saved it in Dos format :S
   (that was the problem why it doesn't run under my VM ...)
2. I found one missing double quote (the last one hopefully). Please
   add it at the end of line 96:
   *FvwmForm-Desktop: Text \" (in pixels. Default is 24)\"

> 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?

To the same place as your FvwmForm-Desktop -> /usr/share/fvwm/
Btw. Your old FvwmForm-Desktop should be deleted because it gets in the
way of the dynamic created FvwmForm-Desktop. Or we must rename all the
FvwmForm-Desktop lines in fvwm-menu-desktop-config.fpl like
FvwmForm-DesktopConfig or so.

About a help for this tool - I thought it is self explaining. There's a
help button in the form which calls the fvwm-menu-desktop help if the user
is in doubt.

> Thomas Adam made some comments about using FvwmPerl.  Is that resolved?
I've fixed all what Thomas suggested except the part to do the complete
stuff with the perllib framework. That needs a little bit more time.

I hope it is ok for Thomas that you want to commit it because it's only
an interim solution.

Thomas

Re: First try of fvwm-menu-desktop which creates a "full" menu

[Dan Espen]

Thomas Funk  writes:

> "Dan Espen"  wrote:
>> Thomas Funk  writes:
>>
>>> "Dan Espen"  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

[Dan Espen]

Thomas Funk  writes:

> 2012/7/18 Dan Espen :
>> 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 :
>> Over here:
>>
>> 
> 
>> 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]

2012/7/18 Dan Espen :
> 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 :
> Over here:
>
> 


> 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.

Thomas

Re: First try of fvwm-menu-desktop which creates a "full" menu

[Thomas Funk]

"Dan Espen"  wrote:
> Thomas Funk  writes:
>
>> "Dan Espen"  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 
# 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;

Re: First try of fvwm-menu-desktop which creates a "full" menu

[Dan Espen]

Thomas Funk  writes:

> "Dan Espen"  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

[Thomas Funk]

"Dan Espen"  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

[Dan Espen]

Thomas Funk  writes:

> 2012/7/23 Dan Espen :
>> 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

[Thomas Adam]

On Mon, Jul 23, 2012 at 10:08:05AM +0200, Thomas Funk wrote:
> 2012/7/23 Dan Espen :
> > 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]

2012/7/23 Dan Espen :
> 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

[Dan Espen]

Thomas Funk  writes:

> Dan Espen  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://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

[Thomas Funk]

Dan Espen  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

[Dan Espen]

Thomas Funk  writes:

> Dan Espen  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

[Thomas Funk]

Dan Espen  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. Defa

Re: First try of fvwm-menu-desktop which creates a "full" menu

[Dan Espen]

Thomas Funk  writes:

> Dan Espen  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]

Dan Espen  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 me

Re: First try of fvwm-menu-desktop which creates a "full" menu

[Dan Espen]

Thomas Adam  writes:

> On Thu, Jul 19, 2012 at 05:48:25PM -0400, Dan Espen wrote:
>> Thomas Adam  writes:
>> 
>> > On 19 July 2012 22:11, Dan Espen  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

[Dan Espen]

Thomas Funk  writes:

> Am 19.07.2012 22:38, schrieb Dan Espen:
>> Thomas Funk  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]

On Thu, Jul 19, 2012 at 05:48:25PM -0400, Dan Espen wrote:
> Thomas Adam  writes:
> 
> > On 19 July 2012 22:11, Dan Espen  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

[Dan Espen]

Thomas Adam  writes:

> On 19 July 2012 22:11, Dan Espen  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

[Thomas Funk]

Am 19.07.2012 22:38, schrieb Dan Espen:
> Thomas Funk  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]

On 19 July 2012 22:11, Dan Espen  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

[Dan Espen]

Thomas Funk  writes:

> Dan Espen  wrote:
>> Thomas Funk  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

[Thomas Funk]

Dan Espen  wrote:
> Thomas Funk  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

[Dan Espen]

Thomas Funk  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]

Thomas Funk  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

[Dan Espen]

Thomas Funk  writes:

> Dan Espen  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

[Thomas Funk]

> Thomas Funk  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]

Dan Espen  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?

Thomas

Re: First try of fvwm-menu-desktop which creates a "full" menu

[Dan Espen]

Thomas Funk  writes:

> 2012/7/17 Dan Espen  wrote:
>> Thomas Adam  writes:
>>
>>> On Mon, Jul 16, 2012 at 06:23:17PM -0400, Dan Espen wrote:
 Thomas Adam  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]

2012/7/17 Dan Espen  wrote:
> Thomas Adam  writes:
>
>> On Mon, Jul 16, 2012 at 06:23:17PM -0400, Dan Espen wrote:
>>> Thomas Adam  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

[Dan Espen]

Thomas Adam  writes:

> On Mon, Jul 16, 2012 at 06:23:17PM -0400, Dan Espen wrote:
>> Thomas Adam  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]

Am 17.07.2012 00:26, schrieb Thomas Adam:

On Mon, Jul 16, 2012 at 06:23:17PM -0400, Dan Espen wrote:

Thomas Adam  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.

-- Thomas Adam

But that means we have to create a "daemon" who checks all the 
distributions special
ways. Will be a big challenge ... Or do you mean only a few ones like 
Debian, Fedora,
SuSE, Slackware, BSD, Gentoo, Solaris ... It's the same as to find out 
which is the
main desktop on the system. And the maintenance also. Every time 
checking if a distri

has changed their way here ...

Re: First try of fvwm-menu-desktop which creates a "full" menu

[Thomas Adam]

On Mon, Jul 16, 2012 at 06:23:17PM -0400, Dan Espen wrote:
> Thomas Adam  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.

-- 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

[Dan Espen]

Thomas Adam  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 Funk]

Thomas Adam wrote:
> 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
>
I looked into the documentation, but the examples are mostly for
building modules not using the scripting part. You're right it isn't
completely correct but it shows how I imagine it. And for testing it
can be used. I will overwork it. Thanks for the tips and hints :-)

Thomas

Btw what do you think about the --insert-in-menu part? could this be
interested?

Re: First try of fvwm-menu-desktop which creates a "full" menu

[Thomas Adam]

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 Funk]

Thomas Adam wrote:
> 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?
Because I don't know how to do this. On the other hand I have assumed
this part from Dan.

>> package Test;
> Will need better namespacing.
that's right. I have assumed this from a FvwmPerl script I found on the
web.

>> use File::Basename;
>> use strict;
> use warnings;
ok, will take it.

>> #open(MSG ,">>[path]/log.txt") || die "Error $!";
>>
>> my $all = `fvwm-menu-desktop --get-menus all`;
>> #print MSG "$all";
>>
>> my $selected = `fvwm-menu-desktop --get-menus selected`;
> How long do these commands take to run in backticks?  If long, 
perhaps use

> IPC::Run?
Not very long. fvwm-menu-desktop takes longer to collect the menus

>> #print MSG "$selected";
>> 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, $directories, $suffix) = fileparse($path, 
qr/\.[^.]*/);

> Why qr?
Because it was so in the original. Not much scripts exist for FvwmPerl
unfortunately. I tried it and it works ...

>> push (@{$selected__menus{$directories}}, $filename);
>> }
>>
>> my $i = 1;
>> foreach my $path (@all_filelist) {
>> my $name = "MEN" . $i;
>> my ($filename, $directories, $suffix) = fileparse($path, 
qr/\.[^.]*/);

>> push (@{$all_menus{$directories}{$i}}, $filename);
>> push (@{$all_menus{$directories}{$i}}, $name);
>> push (@{$all_menus{$directories}{$i}}, "off");
> push (@{...}, ($foo, $bar, "hello"));
will check that

>> if (exists $selected__menus{$directories}) {
>>  foreach my $hit (@{$selected__menus{$directories}}) {
> Better:
>
> foreach my $foo (...)
> {
> next if !defined $bar;
> ...
> }
Ok, will check it also

>>  }
>>  }
>> }
>> $max_length = length($filename) if ($max_length < 
length($filename));

>> $i++;
>> }
>>
>> my $fvwmform_commands = "
>> *FvwmForm-Desktop: WarpPointer
>> *FvwmForm-Desktop: Title\"fvwm-menu-desktop options\"
>> *FvwmForm-Desktop: Linecenter
>> *FvwmForm-Desktop: Text\"-- Multiple Menu 
--\"

>> *FvwmForm-Desktop: Line
>> ";
>
> You need to use FvwmPerl here for this.
?
How?
No examples found ...

Re: First try of fvwm-menu-desktop which creates a "full" menu

[Thomas Adam]

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?

> package Test;

Will need better namespacing.

> use File::Basename;
> use strict;

use warnings;

> 
> #open(MSG ,">>[path]/log.txt") || die "Error $!";
> 
> my $all = `fvwm-menu-desktop --get-menus all`;
> #print MSG "$all";
> 
> my $selected = `fvwm-menu-desktop --get-menus selected`;

How long do these commands take to run in backticks?  If long, perhaps use
IPC::Run?

> #print MSG "$selected";
> 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, $directories, $suffix) = fileparse($path, qr/\.[^.]*/);

Why qr?

> push (@{$selected__menus{$directories}}, $filename);
> }
> 
> my $i = 1;
> foreach my $path (@all_filelist) {
> my $name = "MEN" . $i;
> my ($filename, $directories, $suffix) = fileparse($path, qr/\.[^.]*/);
> push (@{$all_menus{$directories}{$i}}, $filename);
> push (@{$all_menus{$directories}{$i}}, $name);
> push (@{$all_menus{$directories}{$i}}, "off");

push (@{...}, ($foo, $bar, "hello"));

> if (exists $selected__menus{$directories}) {
>  foreach my $hit (@{$selected__menus{$directories}}) {

Better:

foreach my $foo (...)
{
next if !defined $bar;
...
}

>  }
>  }
> }
> $max_length = length($filename) if ($max_length < length($filename));
> $i++;
> }
> 
> my $fvwmform_commands = "
> *FvwmForm-Desktop: WarpPointer
> *FvwmForm-Desktop: Title  \"fvwm-menu-desktop options\"
> *FvwmForm-Desktop: Line   center
> *FvwmForm-Desktop: Text   \"-- Multiple Menu 
> --\"
> *FvwmForm-Desktop: Line   
> ";


You need to use FvwmPerl here for this.

-- 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]

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

Re: First try of fvwm-menu-desktop which creates a "full" menu

[Thomas Funk]

Dan Espen  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

[Dan Espen]

Thomas Adam  writes:

> On 16 July 2012 15:37, Thomas Funk  wrote:
>> 2012/7/16 Dan Espen  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

[Thomas Adam]

On 16 July 2012 15:37, Thomas Funk  wrote:
> 2012/7/16 Dan Espen  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 Funk]

2012/7/16 Dan Espen  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

[Dan Espen]

Thomas Funk  writes:

> 2012/7/6 Dan Espen  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

[Thomas Funk]

Dan Espen  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 
>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_pref

Re: First try of fvwm-menu-desktop which creates a "full" menu

[Thomas Funk]

2012/7/6 Dan Espen  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

[Dan Espen]

Thomas Funk  writes:

> Dan Espen  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]

Dan Espen  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.

No prob ;-)
First it collects all menu files found on the system in the menudict 
dictionary (like a hash in perl)


def getmenulist(desktop, menu_type):
menudict = {}
config_dirs = []
if not install_prefix == '':
config_dirs = [install_prefix]
else:
config_dirs = xdg_config_dirs
It uses the built-in variable xdg_config_dirs from python-xdg. If 
install-prefix is set it will use only this

path.

for dir in config_dirs:
if install_prefix == '':
dir = dir + '/menus'
if os.path.exists(dir):
filelist = set([])
dir_list = os.listdir(dir)
pattern = '*'+desktop+'*'+menu_type+'*.menu'
for filename in fnmatch.filter(dir_list, pattern):
filelist.add(filename)

menudict[dir] = filelist
It skips all paths which not available. The menudict dictionary has a 
unsorted list (set) for the values.

After filling it looks like this (example of my Debian system):
menudict ={'/home/tf/.config/menus' : set(['gnome-settings.menu', 
'gnome-applications.menu']),
'/etc/xdg/menus' : set(['kde4-applications.menu', 
'kde4-information.menu',
'lxde-applications.menu', 'debian-menu.menu', 
'gnomecc.menu',

'gnome-applications.menu']) }

for path in menudict.keys():
if not path == '/etc/xdg/menus':
menudict['/etc/xdg/menus'] = menudict['/etc/xdg/menus'] - 
menudict[path]
Now I'm removing all double entries in /etc/xdg/menus if they exist in 
the users menu path already

because the xdg spec said:
"The first file found in the search path should be used; other files are 
ignored. This implies that if the
user has their own |${XDG_MENU_PREFIX}|applications.menu, it replaces 
the system wide one. (Though the

user's menu may explicitly merge the system wide one.) "

With unsorted list you can delete parts very easily:
menudict['/etc/xdg/menus'] - menudict['/home/tf/.config/menus' ]
set(['kde4-applications.menu', 'kde4-information.menu', 
'lxde-applications.menu', 'debian-menu.menu',
'gnomecc.menu', 'gnome-applications.menu']) - 
set(['gnome-settings.menu', 'gnome-applications.menu'])


menudict['/etc/xdg/menus'] => set(['kde4-applications.menu', 
'kde4-information.menu',
 
'lxde-applications.menu', 'debian-menu.menu', 'gnomecc.menu'])


In the next step the menus will be sorted based on the desktop 
environments. I've used the following DEs: 'gnome', 'kde', 'xfce', 
'lxde'. Also 'debian' because mostly this menu will be implemented as a 
sub menu in the -applications.menu and should'nt appear in 'others' 
which holds all other non DE
menus (found on SuSE a yast-settings.menu). And last but not least 
'none' which take the rest.
Perhaps there're other prefixes from other WMs but mostly they use 
existing ones.


desktop_dict = {}
weight_dict = {}
if desktop == '':
DEs = ['gnome', 'kde', 'xfce', 'lxde', 'debian', 'others', 'none']
else:
DEs = [desktop]
If --desktop is defined only this one will be taken

for de in DEs:
menus = set([])
user_menus = 0
system_menus = 0
filled = False
for path in menudict.keys():
if de == 'none':
pattern = '*'
elif de == 'others':
pattern = '*-*'
else:
pattern = '*'+de+'*'
menu_names = fnmatch.filter(menudict[path], pattern)
I do the file search with fnmatch.filter which returns a list of files 
the pattern matches. First the DEs are
searched using the '*'+de+'*' pattern then the others pattern will used 
and at the end the none ('*').


if not len(menu_names) == 0:
filled = True
for name in menu_names:
menus.add(path+'/'+name)
menudict[path] = menudict[path]-set(menu_names)
Here I delete each found DE menu from the actual path. So, the menus 
will be reduced loop by loop.

Example:
'gnome':
menudict['/etc/xdg/menus']-set(['gnomecc'])
menudict[set(['kde4-applications.menu', 'kde4-information.menu',  
'lxde-applications.menu',
   'debian-menu.menu', 
'gnomecc.menu'])]-set(['gnomecc'])


menudict['/etc/xdg/menus'] => menudict[set(['kde4-applications.menu', 
'kde4-information.menu',

'lxde-applications.menu', 'debian-menu.menu'])]


if not path == '/etc/xdg/menus':
user_menus = len(menu_names)
else:
system_menus = len(menu_names)
At this point I count the menus found in the users and systems menu pat

Re: First try of fvwm-menu-desktop which creates a "full" menu

[Dan Espen]

Thomas Funk  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 
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=,
> --menu-type= or/and --install-prefix=
> 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  - 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

First try of fvwm-menu-desktop which creates a "full" menu

[Thomas Funk]

Hi,

attached is my first try of a fvwm-menu-desktop which creates a menu
with all desktop related menus (if they have entries).

It' works over file weighting because it's too complicated to check
distribution relevant paths for finding the default desktop.

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've attached the complete file and not a patch because too much changed
and it's easier for testing ^^

With --verbose debug messages will be printed out to std.err. So, if
something doesn't work correctly a helpful printout exist.

The other functionality with --desktop=,
--menu-type= or/and --install-prefix=
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

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  - 3.0.0-2
+- Ship applications-gnome.desktop; we don't want GNOME 3 to use 
redhat-menus.



Thomas

#!/usr/bin/python
 
# Modification History

# Changed on 01/26/12 by Dan Espen (dane):
# Make compatible with fvwm-menu-desktop.
# Restored DestroyMenu, needed for reload menus.
# Remove bug, was printing iconpath on converted icons
# Replace obsolete optparse, use getopt instead
# Change from command line arg for applications.menu
# change to using ?$XDG_MENU_PREFIX or theme? fixme
# - use "Exec exec" for all commands, remove option.

# fixme, fix documentation, FvwmForm-Desktop, usage prompt is wrong
# change, mini icons are enabled by default.
# there are rescalable icons.
# themes not working: "hicolor" is a required theme  I see lots of themes but none seem to affect much


# Author: Piotr Zielinski (http://www.cl.cam.ac.uk/~pz215/)
# Licence: GPL 2
# Date: 03.12.2005

# This script takes names of menu files conforming to the XDG Desktop
# Menu Specification, and outputs their FVWM equivalents to the
# standard output.
#
#   http://standards.freedesktop.org/menu-spec/latest/

# This script requires the python-xdg module, which in Debian can be
# installed by typing
#
#   apt-get install python-xdg
#
# On Fedora, python-xdg is installed by default.

import sys
import getopt
import xdg.Menu
import xdg.IconTheme
import xdg.Locale
import os.path
import os
from xdg.DesktopEntry import *
import fnmatch


def main ():

description = """
Generate Fvwm Menu from xdg files.
Standard output is a series Fvwm commands."""

obs_args=['check-app',
  'enable-style',
  'enable-tran-style',
  'fvwm-icons',
  'kde_config',
  'mini-icon-path',
  'merge-user-menu',
  'su_gui',
  'utf8',
  'wm-icons']
dashed_obs_args=[]
for a in obs_args :
dashed_obs_args.append('--'+a)

obs_parms=['check-icons',
   'check-mini-icon',
   'destroy-type',
   'dir',
   'fvwmgtk-alias',
   'icon-app',
   'icon-folder',
   'icon-style',
   'icon-title',
   'icon-toptitle',
   'icons-path',
   'lang',
   'menu-style',
   'name',
   'png-icons-path',
   'submenu-name-prefix',
   'time-limit',
   'tran-icons-path',
   'tran-mini-icons-path',
   'type',
   'uniconv-exec',
   'uniconv',
   'xterm']
equaled_obs_parms=[]
for a in obs_parms :
equaled_obs_parms.append(a+'=')
dashed_obs_parms=[]
for a in obs_parms :
dashed_obs_parms.append('--'+a)

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)
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
verbose = False
force = False
desktop=''
size=24
theme='gnome'
icon_dir="~/.fvwm/icons"
top='FvwmMenu'
install_prefix = ''
menu_type = ''
with_titles =