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.

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. So I think there's an argument for putting menu.hook in /usr/share/WindowMaker, pointing WMRootMenu to it, and not violating policy.

Out of curiosity, why not use dpkg-maintscript-helper to remove appearance.menu and menu.hook as you did for wmappearance and menu-methods?

Have a good one,
Doug

Reply via email to