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
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."
Doug Torrance