This was made redundant by defining pkgconfigdir and pkgconfig_DATA. On
some systems (with automake < 1.15), this caused a build failure, e.g., [1]:
/usr/bin/install -c -m 644 wmlib.pc /«BUILDDIR»/wmaker-0.95.7+201601230517/
debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig/
/usr/bin/install -c -m 644 wmlib.pc '/«BUILDDIR»/wmaker-0.95.7+201601230517/
debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig'
/usr/bin/install: cannot create regular file '/«BUILDDIR»/
wmaker-0.95.7+201601230517/debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig/
wmlib.pc': File exists
Also change the definition of DISTCLEANFILES to pkgconfig_DATA to match
the Makefiles for WINGs and wrlib.
[1] https://launchpadlibrarian.net/234989800/
buildlog_ubuntu-precise-amd64.wmaker_0.95.7+201601230517-0ppa201601211606~
ubuntu12.04.1_BUILDING.txt.gz
Menus may now be shaded like other windows by double clicking on their title
bars. Note that, even if animations are enabled, the shade animation seen
with other windows does not work for menus.
This fixes Debian bug #72038 [1]:
From: Chris Pimlott <pimlottc@null.net>
Subject: wmaker: Persistant menus should be shade-able
Date: Tue, 19 Sep 2000 14:04:41 -0400
One of the many little things that makes me appreciate Window
Maker is that by clicking on the title bar of a menu, it can be made
"persistant" so it stays on screen and doesn't dissappear after click or
mouseout like normal. I find it useful if I need to run a number of
commands in a submenu, or for keeping a list of open windows on
screen.
The usefulness of this feature could be extended by allowing menus
to be shaded (by double-clicking the title) like normal windows, thus
collapsing them to take up less space when not needed but still be
persistant. Perhaps other commands of windows (like maximizing/
minimizing, resizing) might be considered as well, although
personally only shading stands out as particularly useful for menus.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=72038
Previously, if a window was placed on a workspace other than the current one,
the window placement settings (given by WindowPlacement) were ignored and
the window was drawn in the upper left hand corner. This is Debian
bug #181735, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=181735
Part of the bug report by Andrew Gorcester from the link above
is reproduced here:
"When placing a window in a non-active workspace (which usually happens
if the user asks for a program to be started when wmaker is launched,
and defines an initial workspace in the window's attributes dialog),
Windowmaker doesn't follow specified rules on window placement.
All windows of programs that don't manage their own window placement
(Gaim manages placement itself, for instance) are placed in the far
upper-left corner. Usually windows originate from 64, 64, because the
clip occupies the upper-left corner by default."
Doug Torrance