On 2017-08-13 Doug Torrance <dtorra...@piedmont.edu> wrote: > On 08/07/2017 08:51 AM, Andreas Metzler wrote: >> On 2017-07-29 Andreas Metzler <ametz...@bebt.de> wrote: >>> On 2017-07-29 Andreas Metzler <ametz...@bebt.de> wrote: [...] >>>> #1 Providing a new full menu in /etc/GNUstep/Defaults/WMRootMenu does >>>> not make the new content available to users. Anybody who has started >>>> wmaker before will continue using ~/GNUstep/Defaults/WMRootMenu which >>>> references "menu.hook". So I think we need to provide a file named >>>> menu.hook in wmaker's search path with the new content. >>> [...] >>>> Afaict #1 only has an imperfect solution, shipping the menu in >>>> /usr/share/WindowMaker/menu.hook. [...]
>>> which does not seem to work, since with a WMRootMenu consisting of >>> "menu.hook" >>> wmaker expects the menu.hook file to contain a menu file in plain-text, >>> i.e. non proplist format. > >> Okay. Plan C (commited to GIT for review): >> * Revert WMRootMenu to contain just "menu.hook". >> * Convert dynamic menu to old style format and install it as >> /etc/GNUstep/Defaults/menu.Debian >> * Symlink /etc/GNUstep/Defaults/menu.Debian to >> /usr/share/WindowMaker/menu.hook to let WMRootMenu use it. >> * Ship dynamic plmenu in wmaker-common examples. > I just submitted a patch upstream which would allow WMRootMenu to point to > the new menu in proplist format. If we include the patch, then we wouldn't > need to ship both formats, and we could use your "imperfect solution" from > above. I am all for not shipping two formats, but also firmly believe that our menu should live in /etc/. > Is menu.hook (or whatever we end up calling it) really a configuration file? > WMRootMenu definitely is, but there are tons of of other menu files already > in /usr/share/WindowMaker. These just serve as defaults/examples, and > aren't configuring anything unless WMRootMenu points to them. They are a little bit more than examples, they are also fallbacks if the normal menu is unreadable. > So I think > there's an argument for putting menu.hook in /usr/share/WindowMaker, > pointing WMRootMenu to it, and not violating policy. I think that makes it unnecessary hard for a sysadmin to customize the menu. If menu.hook lives in /etc [1] he/she just edits the menu and stuff works. If not he/she needs to edit /etc/GNUstep/Defaults/WMRootMenu *and* needs to make sure that ~/GNUstep/Defaults/WMRootMenu of every user is updated. > Out of curiosity, why not use dpkg-maintscript-helper to remove > appearance.menu and menu.hook as you did for wmappearance and menu-methods? Afaiui dpkg-maintscript-helper only handles dpkg-conffiles. cu Andreas [1] With either a symlink in /usr/share reinstating 50_def_config_paths.diff to have it be used. -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'