Re: First try of fvwm-menu-desktop which creates a full menu
2012/7/17 Dan Espen des...@verizon.net wrote: Thomas Adam tho...@fvwm.org writes: On Mon, Jul 16, 2012 at 06:23:17PM -0400, Dan Espen wrote: Thomas Adam tho...@fvwm.org writes: On Mon, Jul 16, 2012 at 11:35:20PM +0200, Thomas Funk wrote: Regenerate Menu(s) Why can this not be an on-disk cache or something instead of requiring the user to care to regenerate the menus? The purpose of Regenerate Menus is to get a new menu after you've installed a new package. A cache would only make the problem worse. Actually, no. Effectively this is what Debian does with its menuing system and it works just fine. I see no reason why we need an explicit regeneration of these menus. I'm not following. If I install a new package, say Evolution, it won't be in the Fvwm menus. Not until the menu is regenerated. How is a user supposed to get a new menu with Evolution in it? I've looked a little around and the easiest way is to scan the $XDG_DATA_HOME ($HOME/.local/share) and $XDG_DATA_DIRS (/usr/local/share/, /usr/share/) periodically if .desktop files are added/removed there. For that an own module for menu creation/changing/updating will be beneficial ;-). Due to the fact that I am working on that stuff I would start with such a module. But could take a little while ;-) ... In the meantime it would be fine if anybody who's interested in helping would test fvwm-menu-desktop and report bugs here on the list. Dan, I will send you a small bugfix patch for the actual CVS version. The fixes are in the last patch included but as this is a proof of concept would be better to seperate them. Thomas
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.funk...@googlemail.com writes: 2012/7/17 Dan Espen des...@verizon.net wrote: Thomas Adam tho...@fvwm.org writes: On Mon, Jul 16, 2012 at 06:23:17PM -0400, Dan Espen wrote: Thomas Adam tho...@fvwm.org writes: On Mon, Jul 16, 2012 at 11:35:20PM +0200, Thomas Funk wrote: Regenerate Menu(s) Why can this not be an on-disk cache or something instead of requiring the user to care to regenerate the menus? The purpose of Regenerate Menus is to get a new menu after you've installed a new package. A cache would only make the problem worse. Actually, no. Effectively this is what Debian does with its menuing system and it works just fine. I see no reason why we need an explicit regeneration of these menus. I'm not following. If I install a new package, say Evolution, it won't be in the Fvwm menus. Not until the menu is regenerated. How is a user supposed to get a new menu with Evolution in it? I've looked a little around and the easiest way is to scan the $XDG_DATA_HOME ($HOME/.local/share) and $XDG_DATA_DIRS (/usr/local/share/, /usr/share/) periodically if .desktop files are added/removed there. Polling for changes? Nope, I'd rather require specific user action. For that an own module for menu creation/changing/updating will be beneficial ;-). Due to the fact that I am working on that stuff I would start with such a module. But could take a little while ;-) ... In the meantime it would be fine if anybody who's interested in helping would test fvwm-menu-desktop and report bugs here on the list. Dan, I will send you a small bugfix patch for the actual CVS version. The fixes are in the last patch included but as this is a proof of concept would be better to seperate them. Okay. As you've seen I'm a bit slow to look at these things. I haven't looked at your latest work yet. I will get to it though. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.funk...@googlemail.com wrote:
Dan, I will send you a small bugfix patch for the actual CVS
version. The
fixes are in the last patch included but as this is a proof of concept
would be better to seperate them.
Okay. As you've seen I'm a bit slow to look at these things.
I haven't looked at your latest work yet.
I will get to it though.
Attached the patch for
- fixing bug, that empty menus were generated
- fix your fixme for Regenerate Applications Menu
- add forgotten --version
- add forgotten -t for title option
- update help
Thomas
--- /media/daten/shared/sourcen/cvs/fvwm/bin/fvwm-menu-desktop.in 2012-07-13 13:14:31.428392223 +0200
+++ fvwm-menu-desktop.in.p4.1.py 2012-07-18 00:20:03.011125095 +0200
@@ -97,7 +97,7 @@
try:
opts, args = getopt.getopt(sys.argv[1:], hs:t:vw,
- [help, verbose, enable-mini-icons, with-titles, verbose,
+ [help, verbose, enable-mini-icons, with-titles, verbose, version,
desktop=, size=, theme=, install-prefix=, menu-type=, title=]+obs_args+equaled_obs_parms)
except getopt.GetoptError, err:
# print help information and exit:
@@ -105,6 +105,7 @@
print usage
sys.exit(2)
global verbose, force, size, theme, icon_dir, top, install_prefix, menu_type, with_titles, menu_entry_count
+version = 2.0
verbose = False
force = False
desktop=''
@@ -123,11 +124,14 @@
elif o in (-h, --help) :
print usage
sys.exit()
+elif o in (--version) :
+print fvwm-menu-desktop version + version
+sys.exit()
elif o in (--enable-mini-icons) :
force=True
elif o in (--desktop) :
desktop=a
-elif o in (--title) :
+elif o in (-t, --title) :
top=a
elif o in (--install-prefix) :
if a and not os.path.isabs(a):
@@ -364,6 +368,7 @@
printtext('+ %s%s %s' % (name, iconfile, command))
def parsemenus(menulist, desktop):
+global menu_entry_count
if len(menulist) == 1:
# user defines only one special menu
parsemenu(xdg.Menu.parse(menulist[0]), top)
@@ -385,6 +390,7 @@
if not menu_entry_count == 0:
new_toptitles.append(title)
new_menulist.append(menu)
+menu_entry_count = 0
else:
vprint( Menu is empty - won't be used!)
@@ -402,8 +408,10 @@
def parsemenu(menu, name=, title=):
global menu_entry_count
m = re.compile('%[A-Z]?', re.I) # Pattern for %A-Z (meant for %U)
+gen_name = ''
if not name :
name = menu.getPath()
+gen_name = menu.getPath(True)
if not title:
title = name
printtext('DestroyMenu %s' % name)
@@ -422,15 +430,16 @@
menu_entry_count += 1
else:
printtext('# not supported: ' + str(entry))
+
+if gen_name == 'System':
+printmenu(Regenerate XDG Menu(s), system-software-update, FvwmForm FvwmForm-Desktop )
+
printtext('')
for entry in menu.getEntries():
if isinstance(entry, xdg.Menu.Menu):
parsemenu(entry)
-if (re.search('.*System Tools$',name)) : # fixme, find a better way to do this?
-printmenu(Regenerate Applications Menu, , FvwmForm FvwmForm-Desktop )
-
usage=
A script which parses xdg menu definitions to build
the corresponding fvwm menus.
@@ -443,13 +452,13 @@
For the system wide menus use /etc/xdg/menus/
--desktop NAMEdesktop name to build menus for:
gnome, kde, xfce, lxde, debian, etc.
---menu-type NAME applications (default), settings, preferences, etc.
+--menu-type NAME applications, settings, preferences, etc.
--theme NAME gnome (default), oxygen, etc. Don't use hicolor.
It's the default fallback theme if no icon will be found.
-w, --with-titles generate menus with titles.
--enable-mini-icons enable mini-icons in menu
--s, --sizeset size of mini-icons in menu. Default is 24.
---title NAME menu title of the top menu used by Popup command.
+-s, --size NUMset size of mini-icons in menu. Default is 24.
+-t, --title NAME menu title of the top menu used by Popup command.
Default is FvwmMenu
-v, --verbose run and display debug info on STDERR
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: Dan Espen des...@verizon.net wrote: Polling for changes? Nope, I'd rather require specific user action. Suggestion: First step We release fvwm-menu-desktop as is or with my last patch and the reworked FvwmPerl script - user must update manually the menu(s) Second step In the next or ensuing release with the FvwmMenu module which polls e.g. every 5 min /usr/share/applications, /usr/local/share/applications and $HOME/.local/share for changes. This poll takes not much cpu load and time. I've tested this with time find /usr/share/applications -name *.desktop |wc -l 189 real0m0.088s user0m0.000s sys 0m0.004s And if the count in/decrease it starts a silent regenerate. So, user doesn't need updating after installing/removing a new package. But can regenerate manually already. Okay. As you've seen I'm a bit slow to look at these things. I haven't looked at your latest work yet. I will get to it though. And ... what do you think about this proof of concept apart from that it is a little bit slow (will test Thomas' suggestion with IPC::Run) and not FvwmPerl like? I'm guessing dbus or some other abomination does the job for the desktops... -- Dan Espen
