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.
Last group from a desktop file is always added to menu regardless of
NoDisplay property. Properly handle the NoDisplay and Hidden properties
at the end of file.
Signed-off-by: Alexey I. Froloff <raorn@raorn.name>
I noticed that I can have different background with wmmsetbg for each
desktop and wanted to use it, but it was missing option to fill the
screen with proportionally scaled image, so here it is.
memset is the last function call in wmalloc, just before it returns the
newly allocated memory. Therefore it is not needed to call it again
after wmalloc call. Although I would prefer to switch wmalloc to a
calloc-based wcalloc function, the compatibility of WINGs for old apps
should be kept.
As reported by Paul Seelig, it used to be the case that
getstyle -t ~/GNUstep/Library/WindowMaker/Themes/somefile
would save the current theme, and all old menus (WMRootMenu) were
relying on this.
The problem was that the following piece (from commit 6bf79945)
if (style_file && !make_pack)
print_help(0, 1);
would allow a style_file to be specified and saved to only with the
option -p (which implies make_pack), therefore saving a theme with
-t like the root menu used to do no longer worked.
Now things work fine:
[mafra@Pilar:~]$ ls GNUstep/
Applications/ Apps/ Defaults/ Library/
[mafra@Pilar:~]$ getstyle -t ~/GNUstep/theme
[mafra@Pilar:~]$ ls GNUstep/
Applications/ Apps/ Defaults/ Library/ theme
But also note that trying to save a theme outside of GNUstep/
is not allowed and it prints no error message - perhaps it should...
...in order to avoid clashes that happen during compilation of
wmakerconf.
This is a new function in WINGs, so renaming it at this point is
not a big deal.
Thanks to Rodolfo García for the heads up.
The statement under "if (style_file)" in the else branch of
"if (make_pack)" will never be executed because getstyle already
prints out a help message and exits before that.
So remove that code.
Instead of using a temporary buffer to store a "reason" string
which is later printf()'ed by abortar(), use wwarning() directly
and do the small cleanup done by abortar() on the spot.
As this was the only call site for abortar() it can now be removed.
The resulting object code gets smaller as a side effect.
Thanks to Christophe <christophe.curis@free.fr> for finding a mistake
in the first version of this patch.
Dario Niedermann reported on 27.11.2011:
Selecting "Save Theme" from WMaker's root menu results in dialog box
asking for theme name, but then nothing is saved.
This feature used to work in 0.92.0.
and the reason for it (if he uses a WMRootMenu generated by wmgenmenu) is
the incorrect use of the option "-t" instead of "-p" to getstyle.
Furthermore, let the invocation of getstyle reflect the new default location
for the themes.
When invoked as
getstyle -p NewTheme
Instead of saving the theme inside the topdir ~/GNUstep let's save it
insinde their proper directory ~/GNUstep/Library/WindowMaker/Themes.
There is a problem with getstyle invoked with no arguments:
[mafra@Pilar:util]$ ./getstyle
Usage: getstyle [-t] [-p] [-h] [-v] [file]
or with -t:
[mafra@Pilar:util]$ ./getstyle -t
Usage: getstyle [-t] [-p] [-h] [-v] [file]
In both cases it is supposed to write to the standard output:
[mafra@Pilar:wmaker.git]$ getstyle -h
Usage: getstyle [-t] [-p] [-h] [-v] [file]
Retrieves style/theme configuration and output to FILE or to stdout
This regression was caused by commit 6bf7994520 ("style Stuff up").
When that commit did
argc -= optind;
if (argc != 1)
print_help(0,1);
it excluded the output to stdout as valid, because in this case
argc - optind is zero (see the manpage of getopt(3)).
The correct handling is to set the style_file only when there is
one non-option ARGV-element (argc - optind == 1) and print the
help message when there are more than one non-option element.
The one in WPrefs.app/Appearance.c is indirect: the function might
be inlined and might return an uninitialized value, which causes gcc to
complain that the caller might use that uninitialized return value.
The problem with f65b99e615 was that it removed the call to
newWindow() along with the unused variable, without considering that
newWindow() has side effects that need to happen even if the return
value is ignored. So as long as we keep the newWindow() call, we can
safely remove the (unused) variable.
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>
wmagnify stopped working after f65b99e615 ("Remove warnings").
So revert that change in util/wmagnify.c, as it turns out that the
gcc warning was bogus there.
* Remove assigned but not used variables (GCC 4.6)
* Bump _XOPEN_SOURCE to 600, ridding of FreeBSD warnings (this probably need
to be tweaked on a per-implementation basis as problems arise)
Recognize the freedesktop.org-mandated Main Categories in .desktop files
and put menu entries in the appropriate categories.
Signed-off-by: Tamas TEVESZ <ice@extreme.hu>
Add optional interface parsers may choose to implement that, when
a directory is being scanned for files to parse, may, based on
the file name, decide whether or not said file should be parsed.
Signed-off-by: Tamas TEVESZ <ice@extreme.hu>
Add fileInPath, which determines whether or not a given file exists
in $PATH (some heuristics apply).
Make the Wconfig parser use it.
Signed-off-by: Tamas TEVESZ <ice@extreme.hu>
As far as i can tell this finishes the Wmconfig parser (all bits we are
interested in/can use are parsed and converted).
The PropList writer gained ability to properly react to and handle various
flags passed by parsers.
Signed-off-by: Tamas TEVESZ <ice@extreme.hu>
Autoconf uses multiple levels of variables when defining paths. For
example, ${datadir} by default is ${datarootdir}, which by default is
${prefix}/share, which by default is /usr/local. Substituting from
./configure, as is done by AC_DEFINE or AC_DEFINE_UNQUOTED, does not
expand all these variables. This was causing some of our defines to have
garbage like "${prefix}/share/pixmaps" rather than the intended
"/usr/local/share/pixmaps".
The solution is to generate the files needing these paths from the
Makefile rather than from ./configure, because make does fully expand
all those levels.
Signed-off-by: Brad Jorsch <anomie@users.sourceforge.net>
wsyserrorwithcode - Not used, no point either.
wsyserror->werror - qualifying "error" with a "type" hardly makes
sense if there are not at least two "type"s. There are not. Safe trip.
Signed-off-by: Tamas TEVESZ <ice@extreme.hu>
On the one hand, libWINGs wasn't linking against -lX11 when it should
have been. And on the other, only libWINGs needs Xft, only wmaker needs
Xrandr, only wmaker and wmsetbg need Xinerama, only libwraster needs
Xmu, and -lpng may not need -lz.
Cleaning this up can help distributions get their dependencies correct,
and might even avoid loading the unused libraries at runtime, so we may
as well do it.
Signed-off-by: Brad Jorsch <anomie@users.sourceforge.net>
If you link against a library A that itself links against a library B,
it may or may not work to use symbols from library B in your executable;
this is known as "indirect linking". GNU ld does indirect linking by
default (but it can be disabled using --no-add-needed), but the new
experimental GNU gold linker does not do this. It's an easy fix for us,
as the tests are all already done in ./configure, we just need to tell
the Makefile.ams to use the results.
This should fix Debian bug #556677, if they ever start using this
branch.
[crmafra: Folded Andreas Metzler patch to update debian/changelog]
Signed-off-by: Brad Jorsch <anomie@users.sourceforge.net>
I just spent an hour trying to find out why the latest wmaker-crm was
ignoring a number of the preferences in my configuration file. It turns
out the problem was that commit f41db5 added a value into the middle of
the enum in src/keybind.h, and the setting of
AUTOMAKE_OPTIONS = no-dependencies in all the Makefile.ams meant that
make wasn't smart enough to rebuild the files depending on it.
Would anyone mind if we just remove no-dependencies from
AUTOMAKE_OPTIONS? People can still run ./configure with
--disable-dependency-tracking to disable it at configure time.
Instead of using the --disable-verbose-compile hack, let's
use the standard option --enable-silent-rules (or 'make V=0' directly)
available with autoconf 1.11 and higher.
This is enabled in autoconf by using 'silent-rules' in AM_INIT_AUTOMAKE.
The verbosity of compilation is reduced in a similar manner as using
the --disable-verbose-compile option, so we can remove all that ugly
hackery.
