Thomas Funk <t.f...@web.de> writes:
> Hi,
>
> attached is my first try of a fvwm-menu-desktop which creates a menu
> with all desktop related menus (if they have entries).
Interesting.
> It' works over file weighting because it's too complicated to check
> distribution relevant paths for finding the default desktop.
Can you explain the weighting in terms a user would understand.
I read the code once and still didn't have a clue.
> It works under OpenSuse, Fedora, Mandriva and Debian fine and creates
> a menu with a structure like this:
> Fedora 14 example
> Root:
> Documentation >
> Gnome-applications >
> Gnome-screensavers >
> Gnomecc >
> Preferences >
> Server-settings >
> Settings >
> Start-here >
> System-settings >
I was thinking of leaving the choice of menus to generate up to
the user. Of course the distros could do the logical thing
and create a single menu hierarchy or at least set some rules.
This popped out:
This can't be right:
if len(menulist) == 0:
sys.stderr.write(install_prefix+"/"+desktop+"-"+menu_type+".menu not
available on this system. Exiting...\n")
For example:
python fvwm-menu-desktop.in.py --menu-type notfound
/debian-notfound.menu not available on this system. Exiting...
^^^^^^^^^^^^^^^
Not sure what this is:
python fvwm-menu-desktop.in.py --menu-type system-settings
Traceback (most recent call last):
File "fvwm-menu-desktop.in.py", line 470, in <module>
main()
File "fvwm-menu-desktop.in.py", line 170, in main
menulist, desktop = getmenulist(desktop, menu_type)
File "fvwm-menu-desktop.in.py", line 285, in getmenulist
desktop_dict[de_highest].add(menu)
KeyError: 'debian'
>
> I've attached the complete file and not a patch because too much changed
> and it's easier for testing ^^
Not good. Doesn't contain the Usage fixes I recently committed.
I'm not sure how you're testing, but there's a hint at the bottom
of the file that Emacs reacts to. If you test that way there are 2
benefits:
1. We have less chance of losing the #!@PYTHON@ line.
2. Diffs will work without me having to change the file names.
> The other functionality with --desktop=<whatever_desktop_name>,
> --menu-type=<whatever_menu_name> or/and --install-prefix=<whatever_path>
> should work also.
>
> Dan, I don't know if applications-gnome.menu would be created. In my
> simulation
> it is listed but there could be problems with the xdg-automatism. See here:
> http://lists.fedoraproject.org/pipermail/devel/2011-August/155342.html
> https://bugzilla.redhat.com/show_bug.cgi?id=754845
I see. If it's been declared a bug, and it looks like it,
we can just ignore "applications-gnome" because it will probably go away.
> And I found a very interesting entry at the end here:
> http://people.gnome.org/~walters/0001-Ship-applications-gnome.menu.patch
> which could be explain the change from gnome-applications.menu to
> applications-gnome.menu:
> +* Mon Apr 11 2011 Colin Walters <walt...@verbum.org> - 3.0.0-2
> +- Ship applications-gnome.desktop; we don't want GNOME 3 to use
> redhat-menus.
I must be dull. Can't see why they did that.
I've subscribed to the xdg mailing list, asked my question.
Still waiting for an answer.
Meanwhile, the man page is about half done.
--
Dan Espen
