Re: First try of fvwm-menu-desktop which creates a "full" menu
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 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
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
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
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
