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.
The original code refused to create anything not in $WMAKER_USER_ROOT, now
we go one step further and limit creation inside its 'Library' or
'Defaults' sub-directories.
It has become common practice in previous patches to use PACKAGE_TARNAME
instead of hard-coding "WindowMaker" when working with paths, so let's be
as consistent in the generated header.
Directory /etc/WindowMaker is for global defaults configuration, it is not
a "data" folder which is $PREFIX/share/WindowMaker.
The name change make it more consistent with other names.
The FreeDesktop XDG standard suggests storing history in the directory
pointed by $XDG_STATE_HOME; so if we find it is defined we prefer to use
it over the default path. If undefined, keep the old behaviour.
This may introduce a loss of history for users that had some in the legacy
place but have the variable, we consider this very unlikely to be a problem
but if user complains we can suggest them to move the legacy file over the
empty new one.
Replace calls to wusergnusteppath() which just append "/Library" by calls
to wuserdatapath().
Take opportunity to replace hardcoded "/WindowMaker" directories with
the existing PACKAGE_TARNAME macro (which comes from autotools).
The choice of 'TARNAME' is because it meant to be used in filename, thus
less likely to have problematic characters than PACKAGE_NAME (meant for
display purpose) and PACKAGE which is there for historical reason.
The organisation of the file tree for storing application files depends on
a number of directories with a specific name.
This patch puts these names in the generated "config-paths.h" so they can
be shared between WINGs and WindowMaker, and could be user-configured in
the future.
As reported by clang, (!wPreferences.new_style == TS_NEW) inverts the
"wPreferences.new_style" and not the whole expression. Use the appropriate
comparison operator to avoid misunderstanding.
For the Menu edition tab, when building the path to the file that contains
the menu data, rely on wdefaultspathfordomain instead of constructing the
path with many hard-coded names.
Instead of constructing path to user's defaults directory with hard-coded
names, just query wdefaultspathfordomain with a blank domain: this returns
the equivalent of "~/GNUstep/Defaults/", yet avoiding problems related to
duplicating strings.
The man page says environment variables are used, and if they don't exist
it falls back to defaults, yet this was not true in WINGS.
This changes implements the checks for the default paths used when the env
variables are not defined; these default paths have been fixed (+lib) to
match the GNUstep layout ('fhs'), expect for the very last path which keeps
the legacy layout.
For the user Apps folder, rely on wusergnusteppath() (~/GNUstep) to build
the path.
The previous code was only partially functional as the hard-coded paths
did not exist in any of GNUstep standard file system layout and the
GNUSTEP_*_ROOT environment variables were not provided by GNUstep for a
while. This means it would never work no matter how environment variables
were set when using layouts: 'debian', 'fhs', 'next', 'Apple', 'mac',
'fhs-system', or 'standalone'.
