Previously, this was only (partially) possible by redefining the macro
GLOBAL_DEFAULTS_SUBDIR. This told Window Maker to look for the global
config files in a particular subdirectory of SYSCONFDIR.
However:
* This is undocumented.
* GLOBAL_DEFAULTS_SUBDIR is ignored when installing the config files. They
are always installed to SYSCONFDIR/WindowMaker.
To solve these issues, we add a "--with-defsdatadir" option to configure
which allows a user to specify the global defaults directory.
Usually, a soname bump is reserved for when an interface is added, changed,
or removed. This has not happened to wrlib. However, I think there is a
special circumstance that warrants the bump.
In particular, there are two versions of wrlib version 5 in the wild:
* The one that shipped with wmaker 0.95.6, which uses symbol version
LIBWRASTER3.
* The one that shipped with wmaker 0.95.7, which uses symbol version
LIBWRASTER5.
This was reported in Debian bug #811304 [1]. Binaries which were built
against the older wrlib won't run after upgrading to the newer one, even
though they are supposedly using the same soname version.
(We get around this currently in Debian by patching the old LIBWRASTER3
symbol version back in.)
I propose we bump to version 6 and put this mess behind us.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811304
While I love the new maximizing functions, in the process of
developing them the code to keep icons from under the dock was lost.
I have created a patch to prevent this problem.
Simplify handleMaximize function for "not effective" case, where there
was couple of duplicate code, now there is one indentation level less
and readability increased.
Mouse pointer can be now moved together with window if keyboard was used
for arrange maximized windows on screen. This feature can be turned on
in WPrefs.app in Expert tab by selecting "Move mouse pointer with half
MAXIMIZED windows.", or setting "PointerWithHalfMaxWindows" to "Yes" on
~/GNUstep/Defaults/WindowMaker file.
Now it is possible for change a bit pattern for changing state between
half-maximized windows. Half maximized windows will become maximized if
there is issued half-maximizing shortcut in opposite direction. Issue
half-maximizing command on same direction on already maximized window,
will have no effect.
Added new option to Window Maker for enabling alternative way for
half-maximized windows movement. Option can be found on Expert section
in WPrefs app.
Previous bugfix introduced another regression. It fixed the issue with
size of the unmaximized window, but break new functionality. Revert back
code for maximizing using mouse, leaving out head detection for keyboard
actions, since it is already calculated.
Mouse actions for maximize also has to be fixed due to different
behaviour in original implementation - movement of the window which is
called in handleMaximize filter out MAX_KEYBOARD from argument passed to
the wMaximizeWindow, so that it will always assume that all the actions
have to be done on the head where mouse pointer resides. For moving
windows between heads feature, calculated head is always passed and
used, regardless of how maximizing was invoked (keyboard or mouse) and
mouse pointer position.
Using MoveHalfMaximizedWindowsBetweenScreens option user can enable
ability for moving half-maximized windows not only within current
screen/head/display, but also to other heads, if they exists. Note, that
only vertically or horizontally maximized windows can be transfered to
another display. Quarter-maximized windows are not supported, since it
is ambiguous to predict in which direction such window should be moved.
Added new option to Window Maker preferences to enable half-maximized
windows movement on all available heads. Option can be found in WPrefs
app on Expert section.
Patch by Helmut Grohne <helmut@subdivi.de> to fix Debian bug #853236 [1]:
> wmaker fails to cross build from source, because it forces the use of
> pkg-config without $ac_tool_prefix. Discovering pkg-config with the
> PKG_PROG_PKG_CONFIG macro considers $ac_tool_prefix and thus makes cross
> compilation succeed. Please consider applying the attached patch after
> stretch is released.
>
> Helmut
[1] https://bugs.debian.org/853236
Previously, plmenu already existed in the source directory, and that's where
make looked for it. Now, however, it is generated to include the proper
path to WPrefs and therefore is in the build directory.
See
https://www.gnu.org/software/make/manual/html_node/Makefile-Basics.html
for more about this distinction.
It was used to generate WindowMaker/Makefile.am, but hasn't been touched
since 1999. Meanwhile, WindowMaker/Makefile.am has been changed manually
a number of times.
The path to WPrefs has been hardcoded in many of the menu files to
/usr/local/GNUstep/Applications/WPrefs.app/WPrefs, which would only actually
work if the user ran something like:
./configure --with-gnustepdir=/usr/local/GNUstep
during build.
Instead, we add a .in extension to all menu files with this issue and use sed
to use the actual WPrefs path (given by the wprefs_bindir output variable) and
generate a new menu file.
A very similar idea is already used to generate the WMState file, which sets
WPrefs as the command for the Window Maker logo tile in the dock.
This patch fixes Debian bug #851737:
https://bugs.debian.org/851737
Fullscreen windows should only be on top when they are in focus. Change
the stacking level temporarily back to WMNormalLevel if the fullscreen
window loses focus due to an alt+tab operation.
Change the stacking level back to WMFullscreenLevel if the fullscreen
window receives the focus again.
Cc: Amadeusz Sławiński <amade@asmblr.net>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
This reverts the commits:
311ab6b08c ("Raise fullscreened window")
a504370f3b ("Remove WMFullscreenLevel")
Removing WMFullscreenLevel had the side effect that a dock or panel
having the _NET_WM_WINDOW_TYPE_DOCK type would stack on top of
fullscreen windows, obscuring part of them. This is unwanted. No
other window should cover a focused fullscreen window:.
https://specifications.freedesktop.org/wm-spec/latest/ar01s09.html#STACKINGORDER
Simply raising the fullscreen window to the top of the stack of normal
windows is not sufficient if there are windows with higher stacking
levels present. The separate WMFullscreenLevel is needed.
Cc: Amadeusz Sławiński <amade@asmblr.net>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Some (presumably stale) calls to wcopy_file used what appears to
be an incorrect destination which did not always exist. This patch
forces assets to be copied under <themedir>/<asset>, rather than
<themedir><absolute path of asset>. It works by first getting the
"new" path (i.e. the one that will be inserted in the property
list), which is relative to <themedir> (and appears to be always
in the root directory, too); it then copies the file to that path.
This *may* have been the original intended behaviour, as the one
it replaces clutters the path and leaks configuration data. In
addition, the style file seems to store only the file's name, not
the path relative to <themedir>, even when the file is copied with
its full hierarchy.
Signed-off-by: Alexandru Lazar <alazar@startmail.com>
This patch has now been applied in next, so its presence among the Debian
patches would cause quilt to fail for those trying to build packages from
next.
Control: tags -1 forwarded wmaker-dev@lists.windowmaker.org
libtool 2.4.4 will add a --with-aix-soname option. Ignore it when checking
whether INSTALL-WMAKER is up to date.
Fixes Debian bug #814213 [1]. Proposed fix to Debian package at [2].
From: Chris Lamb <lamby@debian.org>
Subject: wmaker: FTBFS: Error: program option '--with-aix-soname' is not in
the documentation './INSTALL-WMAKER'
Date: Tue, 09 Feb 2016 09:59:14 +0100
Dear Maintainer,
wmaker fails to build from source in unstable/amd64:
[..]
make check-local
make[4]: Entering directory '/home/lamby/temp/
cdt.20160209093619.fGSQWYa4PE/wmaker-0.95.7'
./script/check-cmdline-options-doc.sh \
--program "./configure" --text-doc "./INSTALL-WMAKER" \
--ignore-prg 'with-PACKAGE,without-PACKAGE # only template names from
Autoconf' \
--ignore-prg 'program-prefix,program-suffix,program-transform-name
# in INSTALL' \
--ignore-prg 'version,quiet,srcdir,build,host,cache-file,no-create
# in INSTALL' \
--ignore-prg 'enable-silent-rules,disable-silent-rules # should be in
INSTALL' \
--ignore-prg 'enable-dependency-tracking,disable-dependency-tracking
# in INSTALL' \
--ignore-prg 'enable-shared,enable-static # should be in INSTALL' \
--ignore-prg 'disable-option-checking,enable-fast-install # should be
in INSTALL' \
--ignore-prg 'disable-libtool-lock,with-pic,with-gnu-ld,with-sysroot
# for libtool' \
--ignore-prg 'runstatedir #new in autoconf 2.70, backported in Debian' \
--ignore-prg 'with-x # no use, it would not work without X'
Error: program option '--with-aix-soname' is not in the documentation
'./INSTALL-WMAKER'
Makefile:951: recipe for target 'configure-documentation' failed
make[4]: *** [configure-documentation] Error 1
[..]
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814213
[2] http://anonscm.debian.org/cgit/pkg-wmaker/wmaker.git/commit/?id=dd955a7
autoconf 2.70 will add a --runstatedir option, Debian has backported it.
Ignore it when checking whether INSTALL-WMAKER is up to date.
Patch by Andreas Metzler from Debian package [1].
[1] https://sources.debian.net/src/wmaker/0.95.7-3/debian/patches/
56_ignore_runstatedir.diff/
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."
