On 08/13/2017 08:22 AM, Andreas Metzler wrote:
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.
Sounds good. I've added the patch and removed the old-style menu in git.
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.
Ok, that makes sense. I deleted the blurb in d/changelog about deleting
all the maintainer scripts.
Have a good one,
Doug
