I cannot imagine that modifying an existing ~/.xinitrc is ever wanted, and creating an ~/.xinitrc when none exists is much worse.
If a user created their own ~/.xinitrc, then don't modify it.
The user will modify it if they like.
If the user did not create their own ~/.xinitrc, then creating one will short-circuit X startup as `startx` will *replace* the system's version with the user's version.
Literally ~/.Xresources won't be loaded.
There's no way this is expected behavior.
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
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.
Previously, the directory was expected to already exist, but as now it is
automatically created it is a good idea in case of problem to have the
message clearer.
Took opportunity to indent properly that part of code.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
This patch is creating the missing custom GNUSTEP dir.
Patch found on vinelinux.org as WindowMaker-0.95.6-GSDIR.patch.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
LITE was removed in fe736e849c ("Remove LITE config option"), but
the check for it in wmaker.inst was missed.
Furthermore, remove confusing message about wmaker being configured for KDE.
Instead of using _old_ and hard-coded predefined menus as the
source for the user's WMRootMenu during installation, generate
the menu automatically using wmgenmenu.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
Let's remove the configuration options about "sound" from
WPrefs (as it was never fully functionall anyway) and from
configuration files.
Remove also the xpm and tiff icons.
- Fixed WPrefs path in the installed WMState (changed after recent WPrefs
installation path changes)
- Fixed wmaker.inst (apparently some very noisy individual was unable to get
right his 10 line patch to rename a path)
