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.
This is essentially the fetchFile() from wcolorpanel.c from the last
commit, but renamed to a better name.
This patch just adds the function to the lib. Nobody uses it yet.
The idea is to use the fetchFile() in getstyle.c and in wcolorpanel.c
instead of using two very similar functions.
In order to do that, let's move the most generic one (fetchFile()) to
libWUtils, and this is the first step.
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.
Applying patches without needing to fix them first helps me save time,
and this file (stolen from the linux kernel documentation) contains some
valuable tips to configure email clients to not mangle the patches you send.
The goal is that patches are sent in the body of the email (to ease review)
and be applied directly with 'git am'.
I personally use mutt as mail client and xjed as an editor. I insert the patch
in the body of the email using xjed's "Insert file" menu operation. That
works fine, but this documentation file helps you with more choices.
I use xrandr to decrease the resolution of my display when I connect
it to my TV. When I change the resolution back to my monitor, a few
of the icons at the bottom of my dock are deleted.
This happens because wmaker computes the maximum number of dockapps
which the dock can hold based on the screen resolution:
icon_count = scr->scr_height / wPreferences.icon_size;
and drops the dockapps above that number (in wDockRestoreState()).
But now the resolution can change via xrandr, so the above computation
can lead to dockapps being dropped when the new resolution is smaller
than it used to be.
To fix this it's enough to have a resolution-invariant number of allowed
dockapps.
If you delete the file ~GNUStep/Defaults/WMRootMenu and run WMPrefs
and go to the Menu Edit tab, it will show a dialog about keeping the menu or
discarding it. If you discard it then WPrefs shows an error:
"Could not open default menu from
'/home/user/GNUStep/Library/WindowMaker/plmenu"
The problem is at WPrefs.app/Menu.c:1424, and it happens because it tries
to load the default menu from the user's GNUstep home, but plmenu is not
copied there during the installation.
Of course, the file doesn't need to be copied to the users home, so
WPrefs should try to read it from /usr/share/WindowMaker/plmenu (Debian)
or /usr/local/share/WindowMaker/plmenu (upstream).
* New maintainer [Closes: #632875]
* New upstream version, now from git. [Closes: #556677]
* New package wmaker-common (arch independent files)
* removed the asclock diversions from the wmaker scripts
* new package wmaker-common with the arch independent files
* debian/patches are now DEP-3
* debian/copyright is now DEP-5
* Standard-Version is now 3.9.2
* manpages moved to upstream
* solved some problems with .la files (lintian clean)
This reverts commit f4890b17e6.
It turns out that I needed some functions from wtext.c to develop
a WINGs front-end to my comic book collection MySQL database.
Conflicts:
WINGs/Makefile.am
WINGs/WINGs/WINGs.h
With the addition of an extra button to the 'Advanced Options' window,
the vertical space of the widget no longer suffices. Increase it from
350 to 360 and adjust other parameters accordingly.
And let's write the button positions as 'PHEIGHT - 40' instead of using
a hardcoded value, avoiding the need to change it everytime PHEIGHT is
changed.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
The flag to not let windows be minimized was already defined in
WM (it's called 'no_miniaturizable') and the minimize functions
respect it. However this flag can not currently be set manually.
As can be read in the NEWS file
"NotMiniaturizable option changed to NoMiniaturizeButton"
it seems that the "non miniaturizable" property was a first-class citizen
in ancient times and probably configurable (those changes do not appear in
the old CVS history).
Let's make this property be user-configurable through the "Advanced Options"
panel.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
Before this change some lines in the "Advanced Options" window would not
fit into one line and would screw up the others. This depends on the fonts
used, but increasing the width of the panel a bit does not hurt.
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.
There are were a few uses of 'strncpy' that could lead to a missing NUL,
resulting in possible garbage being displayed. As suggested by Tamas,
use 'wstrlcpy' instead
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.
This may ease Carlos' work slightly when dealing with people like me that could not find it and thus submitting the patch directly to him, the only address found
PropGetWMClass()
- XAllocClassHint()s a struct for class hint data
- This is filled by XGetClassHint(), which in turn uses Xlib to allocate
some more space for XClassHint members
- Upon XGetClassHint() failure, "default" is libc malloc'd (via strdup),
and is returned to the caller
- Upon XGetClassHint() success, XClassHint members are returned raw --
these members must be freed with XFree() (see XAllocClassHint(3))
- Thus it's up to PropGetWMClass() callers to decide (based upon the return
value) which method (libc free() or XFree()) to use to free res_name
and res_class. This was done nowhere, thus leaking some memory
on every failed PropGetWMClass() call.
- So just strdup the successful res_name/res_class members, XFree() them
while still in PropGetWMClass(), and allow callers to unconditionally
libc free() whatever PropGetWMClass() returns.
By turning M'bert's d6c134 around a bit and adapting the surroundings,
allow _NET_ACTIVE_WINDOW only if fulfilling it doesn't cause annoying
unwanted changes in the workspace. This is now the default behaviour;
unconditional focus stealing can be enabled on a per-client basis in the
Advanced Options window menu ("Focus across workspaces").
With Xinerama, on heads other than the primary, certain parts (menus,
scrollbars) of certain types of clients (Qt) are incorrectly or not at
all drawn.
The fix follows other window managers in completely ignoring the
_NET_WORKAREA property.
Problem originally poked at by Ambrus Szabo, correct keyword and the
eventually implemented solution suggested by Lucius Windschuh, typed
up by me.
From the original report by Tamas Teves:
"i'm having (and have, for a long time) problems with openoffice and
java-based (perhaps only netbeans-based?) apps.
for openoffice, any menu opens in the far right edge (with xinerama,
on the far right edge of the rightmost display) of the display. it
then can be clicked and operated corretly where it appears.
as for netbeans (and jswat, which also uses netbeans platform as a
base), it's a bit more complicated, but let me try to describe. start
netbeans so that it is not maximized and not in the upper left of the
display. it works fine. move it around, still works fine, resize,
still works fine. now if i maximize it (not by moving to the upper
left corner and resizing, but by the maximize shortcut), then the
menus start acting weird. it seems that the actual position of the
mouse pointer and the hot spot of the mouse pointer get "out of sync"
so to speak, as if the hot spot stayed where the window was before
maximization.
i've made a capture which hopefully better shows what i'm trying to
say. this is a netbeans window maximized, while i'm trying to click
tools->options. the left mouse button must always be held down, or
else it instantly loses any interaction with the menus (in the capture
i released it once when i completely lost track of where i might be).
the capture is available at http://dawn.dev.hu/~ice/tmp/wmjava.avi
i'm not sure whether java stuff other than those based on netbeans
platform exhibit this behaviour. i've seen this with at least one
other nb platform stuff as well."
The fix is to call wWindowSynthConfigureNotify() after wWindowConfigure()
