Several variable declarations were recently added immediately after
labels, but this causes compile errors in GCC versions prior to 11,
e.g.,
wsmap.c: In function ‘handle_event’:
wsmap.c:534:4: error: a label can only be part of a statement and a declaration is not a statement
534 | WMScreen *wmscr = wsmap->scr->wmscreen;
| ^~~~~~~~
We move these declarations to the top of the corresponding switch
statements so that Window Maker can compile on these older versions of
GCC.
Previously, the transparent frames that were drawn prior to snapping a
window assumed that there was only one head, i.e., that the new
position and dimensions of the window would be based on the dimensions
of the entire screen.
However, this is not the case on multi-head systems, and so we now
base the transparent frame's position and dimensions on the current
head of the window.
We also refactor the code so that the new dimensions are computed in
the switch statement and finish with one final call to
drawTransparentFrame.
Previously, we assumed that it always switched from left to right or
vice versa when calling swapDrawer. However, now we may also call
swapDrawer when changing the value of "KeepDockOnPrimaryHead", which
wouldn't actually switch which side of the screen it's on.
So instead, we determine which side of the screen it should be on
based on the dock.
Previously, we either saved it as 0 or -ICON_SIZE, and then adjusted
it depending on the screen width when restoring the state.
But since the introduction of the "KeepDockOnPrimaryHead" option, the
state-restoring code has changed so that the dock will go on the left if the
x-coordinate of the position in WMState is to the left of the midpoint
of the screen and on the right otherwise. But previously (unless the
user manually set the value in WMState) this would always send the
dock to the left, even if it had been on the right, since the x-coordinate
automatically saved to WMState in this case was negative.
We simplify things by saving the actual x position of the dock to WMState.
Previously, we assumed that if the dock was on the right, then the
menu should be on the far right of the entire screen, but this is no
longer the case with "KeepDockOnPrimaryHead" set to "YES".
We use the new helper function getDockXPosition to determine where
to put the dock. If WMState gives an x-coordinate less than the
center of the screen, we put it on the left, and otherwise we put it
on the right.
We use the new "getDockXPosition" helper function to find the x
position of the main icon, whose position is used in "wDockCreate" to
get the position of the entire dock.
Previously, "KeepDockOnPrimaryHead" was only taken into account
when *moving* the dock and not when creating it.
This implements a feature request [1] to allow the possibility of
keeping the dock on the primary head on a multi-head system.
In particular, if the new KeepDockOnPrimaryHead option is set to YES,
the dock will either be on the left- or right-hand side of the primary
screen. If it is NO, then we get the current behavior, i.e., the dock
will either be on the left-hand side of the leftmost head or the
right-hand side of the rightmost head.
[1] https://github.com/window-maker/wmaker/issues/24Closes: #24
Once implemented, this will keep the dock on the primary head (when
there are multiple heads) when YES. The default value is NO, the
current behavior, i.e., treat all monitors together as one large screen.
This matches the English manpage and also prevents
wrong-manual-section Lintian warnings in the Debian package, as "Maker"
was being interpreted as the section of these manpages.
Files in /usr/share/xsessions are used by some display managers (e.g.,
LightDM and GDM) to detect available sessions. Such a file has been
shipped in the Debian Window Maker package for years.
Previously, we released the color well's color even if it was the same
as the new color. This eventually resulted in a segfault when calling
WMPaintColorSwatch because we tried calling XFillRectangle with no
display.
We fix this by only releasing/updating the color well's if it differs
from the new color.
It's USE_MAGICK, not USE_MAGIC. Also, we wrap the if/else statement
in an ifdef. This doesn't really affect anything since load_magick.c
won't be compiled if USE_MAGICK is undefined because of an if statement
in the Makefile. But in the off chance that it is somehow, then we will
try to load a nonexistent version 6 header file since USE_MAGICK will
be interprested as 0 and 0 < 7 is true.
Unescaped curly braces have been deprecated since Perl 5.26 and are
illegal in Perl 5.30. I copied the relevant lines from the latest kernel
source, so we'll inherit a couple other improvements as well.
The abs() function should take an int as argument, but there were
several instances in the code where it was taking an unsigned int or a
double. In these case, we took one of the following approaches:
* If the argument was a double, use fabs() instead.
* If the argument was unsigned and was certainly going to be positive
(i.e,. no subtraction), then drop abs() altogether.
* If the argument was unsigned as result of adding or subtracting signed
and unsigned ints, then we cast all the unsigned ints to signed ints.
We dropped ImageMagick 6 support in 0.95.9. However, ImageMagick 6 is
still widespread (e.g., ImageMagick 7 has not been packaged in Debian
yet), and upstream plans on maintaining it until at least 2028 [1].
In this patch, we detect the version of the MagickWand library installed
on the user's system and include the appropriate header file when
building wrlib.
Note: I've only tested this with ImageMagick 6, so I'd appreciate
confirmation that it works with ImageMagick 7.
[1] https://github.com/ImageMagick/ImageMagick6/blob/master/NEWS.txt
We use the AC_PATH_XTRA macro to find all the X library paths during
build, but we weren't actually using the variables it generated for
building wmlib. Instead, we just hardcoded the linker flag "-lX11",
which may or may not actually work.
As the literal string "wm_cv_xext_xmu" will never be equal to "xno",
we always ran the code that was supposed to run when the variable
$wm_cv_xext_xmu was not equal to "no". In particular, if libXmu
was not found, then we proceeded as if it had been found.
I noticed one instance of this while looking at the code the other day,
and after a quick grep, realized it happened a *lot*! One of the many
frustrating things about the English language is that we use apostrophes
to make pretty much everything possessive *except* the pronoun "it".
In that case, we use "its". "It's" is reserved for the contraction
meaning "it is" or "it has".
As reported in Debian bug #922284 [1]:
As evident from the prefix, GNUSTEP_USER_ROOT is a GNUstep variable and
Window Maker should not set it. Furthemore, it has been deprecated for
12 years already. As of gnustep-make/2.7.0-4 the GNUstep build system
is configured in strict v2 mode which makes it impossible to compile
GNUstep software. In a terminal started from a Window Maker session:
yavor@aneto:/tmp/gorm.app-1.2.24$ make
This is gnustep-make 2.7.0. Type 'make print-gnustep-make-help' for help.
Running in gnustep-make version 2 strict mode.
rm -f InterfaceBuilder; \
ln -s GormLib InterfaceBuilder
/usr/share/GNUstep/Makefiles/config-noarch.make:121: *** GNUSTEP_USER_ROOT
is obsolete. Stop.
It is also impossible to build gnustep-make from pristine upstream
source:
yavor@aneto:/tmp$ wget -q
ftp://ftp.gnustep.org/pub/gnustep/core/gnustep-make-2.7.0.tar.gz
yavor@aneto:/tmp$ tar xzf gnustep-make-2.7.0.tar.gz
yavor@aneto:/tmp$ cd gnustep-make-2.7.0/
yavor@aneto:/tmp/gnustep-make-2.7.0$ ./configure
...
yavor@aneto:/tmp/gnustep-make-2.7.0$ make
config-noarch.make:121: *** GNUSTEP_USER_ROOT is obsolete. Stop.
Note that the majority of GNUstep users use Window Maker as their window
manager and many of them build GNUstep software from source, mostly
because of the GNUstep Objective-C runtime which depends on Clang
(Debian packages use GCC and the GCC/GNU runtime).
Our solution is to replace the GNUSTEP_USER_ROOT environment variable with our
own environment variable, WMAKER_USER_ROOT. This is documented in NEWS.
[1] https://bugs.debian.org/922284
The variable set by PKG_PROG_PKG_CONFIG which points to the pkg-config
utility is PKG_CONFIG, not PKGCONFIG. The latter was previously used
when trying to detect the presence of the MagickWand library when Window
Maker was built using --enable-magick.
This option had been broken for several reasons:
* The getstyle utility does not replace the #usergnusteppath# macro which
was passed to it by the menu.
* When processing the USER_THEMES_DIR macro, the menu inserts a space
afterwards, and so the directory and filename were passed to getstyle
as two separate arguments.
* It used the old, pre-0.50.0 theme format.
By using the -p option to getstyle, we can avoid these issues, as we don't
need to specify the directory *and* it uses the 'new' (since 1999) themepack
format.
Inspired by the Debian patch 54_Debian_wmmacros.diff. These macros are
actually already referenced in appearance.menu and background.menu, but
only Debian installations have taken advantage of them.
We use the new #usergnusteppath# macro to reference the user GNUstep path.
This macro is used when handling directories with OPEN_MENU, e.g., to list
available image files for setting the workspace background.
When parsing a menu file, we replace any instances of #usergnusteppath#
with either GNUSTEP_USER_ROOT or ~/GNUstep if the former is not set. In
this way, authors of menu files do not have to worry about whether users
will have this variable set or not.
We also document this feature in WindowMaker/menu.in, which generates the
default English language old-style menu and currently contains the existing
documentation for the Window Maker menu system.
We remove the macros LOCAL_THEMES_DIR, LOCAL_STYLES_DIR,
LOCAL_ICON_SETS_DIR, and LOCAL_BACKGROUNDS_DIR.
They were only referenced in the Debian patch 54_Debian_wmmacros.diff, which
set them to /usr/local/share/WindowMaker/{Themes,Styles,etc.}.
In a default installation, THEMES_DIR, STYLES_DIR, etc. coincide exactly
with these paths. In a Debian installation (which defaults to /usr/share
instead of /usr/local/share), it seems unlikely that a user would have these
files in both locations.
Previously, WPrefs could only be used to edit the menu specified in
WMRootMenu.
In a recent commit, the ability to specify a menu in proplist format defined
in another file which is referenced by WMRootMenu was added. However, if a
user attempted to edit such a menu in WPrefs, an error dialog appeared.
We add the ability for WPrefs to read such a menu. After the user makes any
changes, the result is stored in WMRootMenu, and *not* the original file.
Previously, calls to WMIsPLString, WMIsPLData, WMIsPLArray, and
WMIsPLDictionary would result in a segfault if the argument was null.
This could happen, e.g., if we are checking which type of proplist
was just parsed from a file, but the parsing failed.
These functions now return False in this case.
Many of the menu files contain the macro #wmdatadir# as a placeholder for
the data directory containing Window Maker themes, styles, background
pixmaps, etc. This macro is replaced by the the actual path to the data
directory (by default /usr/local/share/WindowMaker) by the wmaker.inst
script, but only when copying WMRootMenu to the user's home directory.
Instead, we replace the macro during the build. This way, *every* menu
file has the correct path.
Note that several of the files in question were not previously generated
during build. These have been renamed with a .in extension.
The background menu was missing "centered", "maximized", and "filled".
This closes Debian bug #85591 [1]:
The current default for the scaled backgrounds menu is to use
scaling without keeping the aspect ratio.
This very rarely yields to a usable background.
Could the default be changed to scaling with keeping the aspect
ratio ?
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=85591
Previously, WMRootMenu could either be a menu file in proplist format
itself, or it could reference another menu file in the old style format.
If WMRootMenu referenced another menu file in proplist format, this file
was parsed assuming it was in the old style format and thus failed, as
observed by Andreas Metzler [1].
In this patch, we first attempt to parse a referenced menu file as if
it were in proplist format. If this fails, then we fall back on the old
style format. This has the disadvantage of spamming the terminal with
various parsing errors if the menu file is in the old style format.
[1] https://www.mail-archive.com/wmaker-dev@lists.windowmaker.org/msg07097.html
From https://standards.freedesktop.org/menu-spec/latest/apa.html:
Category-based menus based on the Main Categories listed in this
specification do not provide a complete ontology for all available
applications. Category-based menu implementations SHOULD therefore provide
a "catch-all" submenu for applications that cannot be appropriately placed
elsewhere.
Emphasis on *submenu*. By using 'Applications', these menu entries were
sorted into the top level.
From https://standards.freedesktop.org/menu-spec/latest/apas03.html:
Reserved Categories have a desktop-specific meaning that has not been
standardized (yet). Desktop entry files that use a reserved category MUST
also include an appropriate OnlyShowIn= entry to restrict themselves to
those environments that properly support the reserved category as used.
Previously, when WMSetWidgetBackgroundPixmap() was called prior to
WMRealizeWidget(), no background pixmap was actually set.
This is because while the CWBackPixmap bit is correctly set to 1, the
CWBackPixel bit remains set to 1. When XCreateWindow() is finally
called during realization, the background pixel takes precendence over the
background pixmap.
We fix this by setting CWBackPixel to 0 when setting CWBackPixmap to 1 and
vice versa.
The default configuration options are given in two places in the source
code:
- src/default.c
- WindowMaker/Defaults/WindowMaker.in
The defaults are initially set in the former, but are then overwritten by
the latter.
Ideally, the default options in these two locations should coincide.
However, there are currently several issues.
- Many of the options are missing from WindowMaker/Defaults/WindowMaker.in
- Many of the options have conflicting defaults between the two locations.
- A number of options given in WindowMaker/Defaults/WindowMaker.in no longer
exist.
In this patch, we bring the defaults in the two locations in line with one
another. We have given preference to the defaults in W/D/WindowMaker, as
these are the one users have been used to.
Some of the paths in IconPath and PixmapPath have been removed. In
particular, the various system pixmap paths (/usr/include/X11/pixmaps,
/usr/share/pixmaps, and /usr/local/share/pixmaps) have been removed in
favor of PIXMAPDIR, which is specified by the user at build. Also,
/usr/share/icons has been removed from IconPath. The root of this
directory will contain very few icons, as the icons themselves are located
in subdirectories corresponding to XDG icon themes.
We add a comment to src/defaults.c to remind future developers who
add or remove options to change the default values in both locations.
We also take the opportunity to remove the unused DEF_INFO_TEXT_FONT
macro.
Previously, only the user's WMGLOBAL file would be read to determine the
current WINGs fonts (System Font and Bold System Font) in the Font
Configuration panel. It is quite possible that this information would
not be in the user's WMGLOBAL file, but instead in the system WMGLOBAL
file.
We instead use the WMDefaultSystemFont and WMBoldDefaultSystemFont
functions to get this information.
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
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
Doug Torrance