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
