This patch addresses this warning of gcc:
wfontpanel.c: In function 'listFamilies':
wfontpanel.c:588: warning: missing sentinel in function call
Fix it by using the 'NULL' pointer instead of 0 (zero) as the
sentinel.
For more information, see
http://www.linuxonly.nl/docs/2/2_GCC_4_warnings_about_sentinels.html
in particular,
"On most systems, there is no difference between 0 and (char *)0.
On 64 bit systems, however, the integer 0 is 32 bits and the
pointer 0 is 64 bits. The compiler does not know whether it is
an integer or a pointer, and defaults for the integer. This will
not clear the upper 32 bits and the function will not stop
scanning its parameters."
Note that here in my 64-bit Mandriva I don't need to cast (char *)NULL.
Based upon a patch by Tobias Stoeckmann
Small code size reduction,
text data bss dec hex filename
620412 19144 8544 648100 9e3a4 src/.libs/wmaker
621347 19152 8544 649043 9e753 src/.libs/wmaker.old
The WINGs-function wtokensplit does not set argv to NULL if no string has been
split - instead argc is set to 0.
You can only observe this issue if you compile Window Maker without any
optimization:
compile Window Maker with CFLAGS=""
run Window Maker and save a session
change session-file and replace a 'command xyz' line with 'command " "'
restart Window Maker
watch "Fatal error"-message
Retrieved-from: http://paldium.homeunix.org/tobias/wmaker/
Submitted-by: Gilbert Ashley <amigo@ibiblio.org>
This is a small patch to fix an issue with the switchpanel and a large number
of windows which happens only on a Xinerama setup.
When the number of open windows is so large that displaying all of them would
cause the switchpanel to be too wide for the screen, the panel is supposed to
shrink and scroll to accomodate them all.
In Window Maker 0.92.0 this works for single head displays but not for
Xinerama. The panel extends to the next head and gets garbled. This patch fixes
the issue by correctly constraining the panel to the head with the cursor.
Submitted-by: Gilbert Ashley <amigo@ibiblio.org>
A minor bug has been bothering me for a long time. When you maximize a
borderless window in Window Maker, the window ends up too narrow and too short
by two pixels.
Submitted-by: Gilbert Ashley <amigo@ibiblio.org>
wmaker keeps the names of all workspaces together in
the string 'buf' with fixed length of 1024, therefore
allowing buffer overflows if the number of workspaces
is big enough.
For the default names "Workspace X" (from 1 to 9)
and "Workspace XX" (from 10 to 99) etc, the approximate
number of workspaces necessary to make the buffer
overflow occur is 80, because
(11*9) + (71*12) + 80 = 1031
The fix is to set the size of 'buf' as
the maximum number of workspaces times their maximum
name length.
The problem was reported by John H. Robinson in the wmaker-dev
list ( http://lists.windowmaker.info/dev/msg00214.html ):
"http://www.youtube.com/watch?v=fkNJZvKwmhE
Michael reported a problem with Window Maker where it crashes with a
SIGSGV when trying to create an 82nd workspace.
/usr/local/WindowMaker-0.92.1pre/bin/wmaker warning: Window Maker exited
due to a crash (signal 11) and will be restarted.
I was able to reproduce it by making 81 workspaces, then creating an 82nd."
[ crmafra: Wrote the changelog ]
Actually, the whole thing is so chock full of signed vs unsigned
mixups and the assumption of all the world is 32-bit that i'm not sure
anymore that correcting them one by one is a good idea.
what would probably work best is that if someone deeply familiar with
the code (*looks in dan's general direction*) cleaned the data types
up, then legions of grunts like myself could start cleaning the rest
with relative confidence...
Here I tried to prevent the menu of windows to be displayed in the
other side of the screen if the window is half present in the screen
horizontally (ie x < 0)
a worse problem with menu is that it disappears when
the window is half present in the window vertically
ie y < 0, that makes it not usable.
This patch fixes the following warnings (with gcc 4.2.3)
defaults.c:980: warning: unused variable 'replace'
main.c:504: warning: 'watchPath' may be used uninitialized in this function
main.c:504: note: 'watchPath' was declared here
startup.c:616: warning: implicit declaration of function 'XrmUniqueQuark'
The handling of user defined shortcuts was not checking the length
of the shortcut before copying it to a fixed-length temporary buffer,
char buf[128];
strcpy(buf, shortcutDefinition);
and strcpy() is well known for not checking if overflows will occur.
In particular, wmaker was crashing here if a big 'shortcut' was defined
either through WPrefs or by directly editing the configuration files.
This is now avoided by using strncpy() instead.
And this patch also fixes a similar buffer overflow for big workspace
names too.
Furthermore, use MAX_SHORTCUT_LENGTH instead of raw number and define
it to be 32 instead of 128.
There may be issues with running applications in 64-bit mode when
they were written with tacit assumptions about 32-bit platforms.
For example,
* Assuming that a pointer can be cast back and forth to an integer
The reason is that the size of the integer and pointer may be different.
See the description of "[PATCH] Warn when casting a pointer (constant)
to an integer of different size." in the gcc mailing list
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01881.html
where it was also suggested the use of casts to uintptr_t. This is
what this patch does.
As a result the following warnings are fixed, leaving us with an
almost warning-free compilation in 64-bit platforms:
defaults.c:1446: warning: cast to pointer from integer of different size
defaults.c:1457: warning: cast to pointer from integer of different size
defaults.c:1471: warning: cast to pointer from integer of different size
defaults.c:1486: warning: cast to pointer from integer of different size
icon.c:67: warning: cast from pointer to integer of different size
menu.c:112: warning: cast from pointer to integer of different size
switchmenu.c:452: warning: cast from pointer to integer of different size
window.c:140: warning: cast from pointer to integer of different size
window.c:2217: warning: cast to pointer from integer of different size
workspace.c:135: warning: cast to pointer from integer of different size
workspace.c:214: warning: cast to pointer from integer of different size
workspace.c:634: warning: cast to pointer from integer of different size
workspace.c:1330: warning: cast to pointer from integer of different size
workspace.c:1514: warning: cast to pointer from integer of different size
wfilepanel.c:135: warning: cast from pointer to integer of different size
wfilepanel.c:171: warning: cast from pointer to integer of different size
wfontpanel.c:499: warning: cast to pointer from integer of different size
wfontpanel.c:500: warning: cast to pointer from integer of different size
wfontpanel.c:505: warning: cast to pointer from integer of different size
wfontpanel.c:506: warning: cast to pointer from integer of different size
wfontpanel.c:776: warning: cast from pointer to integer of different size
wfontpanel.c:777: warning: cast from pointer to integer of different size
wfontpanel.c:877: warning: cast from pointer to integer of different size
wfontpanel.c:878: warning: cast from pointer to integer of different size
wpanel.c:363: warning: cast from pointer to integer of different size
fontl.c:42: warning: cast from pointer to integer of different size
fontl.c:42: warning: cast from pointer to integer of different size
fontl.c:42: warning: cast from pointer to integer of different size
fontl.c:90: warning: cast to pointer from integer of different size
puzzle.c:138: warning: cast from pointer to integer of different size
puzzle.c:225: warning: cast to pointer from integer of different size
wtableview.c:1031: warning: cast to pointer from integer of different size
wtableview.c:1067: warning: cast to pointer from integer of different size
wtableview.c:1069: warning: cast to pointer from integer of different size
wtableview.c:1074: warning: cast to pointer from integer of different size
wtabledelegates.c:234: warning: cast from pointer to integer of different size
wtabledelegates.c:250: warning: cast from pointer to integer of different size
wtabledelegates.c:265: warning: cast from pointer to integer of different size
wtabledelegates.c:287: warning: cast to pointer from integer of different size
wtabledelegates.c:351: warning: cast from pointer to integer of different size
wtabledelegates.c:372: warning: cast from pointer to integer of different size
wtabledelegates.c:393: warning: cast from pointer to integer of different size
wtabledelegates.c:410: warning: cast to pointer from integer of different size
test.c:44: warning: cast from pointer to integer of different size
test.c:47: warning: cast to pointer from integer of different size
test.c:55: warning: cast from pointer to integer of different size
test.c:58: warning: cast from pointer to integer of different size
This patch adds the --disable-verbose-compile switch to the
configure script.
When this option is used it reduces the verbosity of compilation
messages to the essential. However compiler warnings are not affected
and thus gain visibility by not standing in the middle of a storm
of other messages.
In summary, the compilation messages are reduced to a stream of
CC array.o
CC bagtree.o
CC configuration.o
CC connection.o
CC data.o
[...]
instead of a mind-boggling flux of
gcc -DHAVE_CONFIG_H -I. -I../src -I../WINGs/WINGs -I../wrlib -I../src
-I/usr/include/freetype2 -I/usr/local/include
-DLOCALEDIR=\"/usr/local/lib/loca\"/usr/local/share/WINGs\"
-DDEBUG -fno-strict-aliasing -g -O2 -c array.c
gcc -DHAVE_CONFIG_H -I. -I../src -I../WINGs/WINGs
-I../wrlib -I../src -I/usr/include/freetype2 -I/usr/local/include
-DLOCALEDIR=\"/usr/local/lib/loca\"/usr/local/share/WINGs\"
-DDEBUG -fno-strict-aliasing -g -O2 -c bagtree.c
[...]
event handler timer.
After upgrading my kernel recently I noticed that dnotify has been
depreciated, so I decided to try and implement the new inotify code in
Window Maker instead.
During testing, I also found that one of the timers which was removed
(the one causing the most wake-ups), calling delayedAction, was
responsible for handling signals. Basically with this timer removed,
signals were only handled after an X event occurs.
After looking at the delayedAction function, I couldn't see the purpose of it.
It certainly wouldn't cause any delay as it was called by the timer every
500ms, so there is no time correlation with when a signal was received.
Also, it appeared to count the signals and call DispatchEvent for each
one, but it appears DispatchEvent would just handle the most recent signal
and take action on that. The signals handled by delayedAction are the
various exit and reset signals, so only one need to be handled. I
therefore have commented out delayedAction (it wasn't called by any other
procedure) and added a call to DispatchEvent imediately after the signal
is registered, in handleExitSig.
I'm not sure what problems this may cause with dead children - these are
only cleaned up after an Xevent now that the timer is removed- but I
haven't observed any problems since a few months ago.
Pedro Gimeno explains:
"As you most likely already know, every X Window event comes with a
timestamp. You can see it using e.g. xev.
I don't know if this is Debian-specific and I'm no X Window expert, but
the fact is that in my machine this timestamp, according to my
/usr/include/X11/X.h, is a 32-bit unsigned integer and it holds the
event time in milliseconds according to my tests.
This timestamp appears to be in milliseconds from the start of the Unix
epoch, modulo 2^32. The problem is that 32 bits are too little for this
purpose: 2^32 milliseconds are exactly 49 days, 17 hours, 2 minutes and
47.296 seconds.
Now, the WindowMaker code rejects any focus event whose timestamp is
less than the last one seen, using code similar to this:
if (timestamp < LastTimeStamp) return;
LastTimeStamp = timestamp;
This is a disaster when timestamp wraps around because of the 32-bit
limit. Say LastTimeStamp equals 2^32-1 and a focus event comes two
milliseconds after. Its timestamp will equal 1 because of the
wraparound. Obviously, 1 < 2^32-1 so the event will be rejected even if
it comes from the future (relative to LastTimeStamp) and not from the
past. Focus events are no longer accepted because nothing can be greater
than 2^32-1 (unless you click on that exact millisecond, 49 days after).
If you look in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=102314
you'll see two people confirming the periodicity and predictability of
the bug. Arnaud Giersch was who noted that the period was 2^32
milliseconds (and not 2^31 as I thought it could be because of a signed
int involved) and who noted the coincidence with the Unix epoch.
My fix works by subtracting one timestamp from the other (an operation
which is done modulo 2^32) and rejecting the focus event only if the new
timestamp is within 1 minute (60000 milliseconds) in the past. Given the
periodicity of the timestamp, actually after 49.7 days there will be
another minute in the future during which focus events will not be
accepted; again after 99.4 days, etc., but thanks to the subtraction,
they will now be relative to the *last* focus change and not to the Unix
epoch.
The patch could be simplified to get rid of the compareTimes function.
It's written like that because it comes from the previous patch (which
you can see in the same bug report).
So the date comparison line could end up looking like this:
if (scr->flags.ignore_focus_events || LastFocusChange - timestamp <
60000)
so you can get rid of the compareTimes function. However please respect
the other change of 'int' to 'Time'.
As for why you aren't experiencing this problem, perhaps the event
timestamp does not come from the Unix epoch in your X Window system, but
rather starts counting when you start it or your computer, I don't know.
Or maybe your X Window server's timestamps are 64 bits wide instead of
32 bits, which I don't think because I doubt the X11 protocol specifies
a 64-bit record for the transmission of the timestamp. In either case,
the output of xev will probably help understanding the cause.
Or maybe even it's a click-to-focus only bug and you're not using that
mode. I haven't checked who calls wSetFocusTo.
Note that I can reproduce it just by manipulating the system clock,
which seems to be tied to the event timestamps."
For more information see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=102314
Reported-by: Joey Hess <joeyh@debian.org>
Signed-off-by: Pedro Gimeno <parigalo@formauri.es>
WPrefs tries to use the fonts listed in the WMCreateFont() call (from WPrefs.c),
font = WMCreateFont(scr, "Lucida Sans,URW Gothic L,Times New Roman,serif"
":bold:pixelsize=26:antialias=true");
and 'font' is later used without accounting the possibility of it being NULL in
WMSetLabelFont(WPrefs.nameL, font);
WMReleaseFont(font);
In particular, WMReleaseFont(font) will kill WPrefs ungracefully with the
following message if font=NULL
WPrefs: wfont.c:193: WMReleaseFont: Assertion `font!=((void *)0)' failed.
Aborted
That happens because the return value of WMCreateFont() can be NULL, so this
patch makes WMCreateFont() never return NULL. If the font creation fails for
some reason (see below), we try to use the emergency DEFAULT_FONT and print
debugging information telling what's going on. If the use of DEFAULT_FONT
also fails, then we terminate WPrefs with exit(1) and let the user know
why exactly if failed.
This bug happened because the font "Lucida Sans" (the first possibility
in the initial call to WMCreateFont()) "exists" in my system as a stale
symbolic link to a location which no longer exists after an upgrade from
java from 1.5.0.14 to 1.5.0.15
/etc/alternatives/LucidaSansDemiBold.ttf ->
/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/fonts/LucidaSansDemiBold.ttf
So the call to XftFontOpenName(display, scrPtr->screen, fname) with
"Lucida Sans" being the first possibility for Xft to try out ended up in 'font'
being NULL because, as far as the Xft library was concerned, "Lucida Sans"
produced a positive match (due to it existing as a symbolic link) but in the end
a NULL result was produced due to the missing symbolic link destination. This later
exposed the bug of WMCreateFont() returning font=NULL and WPrefs.c not checking
whether font=NULL before using it. Bang!
If "Lucida Sans" was the _second_ entry to try and the first one had suceeded,
this bug would not have surfaced.
This solves https://qa.mandriva.com/show_bug.cgi?id=39677
Signed-off-by: Carlos R. Mafra <crmafra@ift.unesp.br>
This patch removes wmaker from PowerTop's shame list, where
it appeared with ~3-4 wakeups/second.
It adds the linux kernel's dnotify mechanism (adapted from
the example in Documentation/dnotify.txt in the kernel source),
to detect when a configuration file in ~/GNUStep/Defaults has
changed to load it again on-the-fly. For me it usually means that
modifications to ~/GNUStep/Defaults/WMRootMenu via the 'genmenu'
script are automatically detected and loaded.
The use of dnotify makes the ancient behaviour of polling unecessary
and cuts down the wakeups count.
Other 'apparently' useless timers are also deleted and it's been almost
one year now that I use this patched exclusively without problems, so
I am pretty sure that it doesn't hurt to remove them.
The end result of all this is that wmaker generates 0 (zero) wakeups
when idle in a Linux system.
Signed-off-by: Carlos R. Mafra <crmafra@ift.unesp.br>
This also fixed an endless loop that could be entered by the previous code
in certain situations, after the patch to fix navigation/selection in a
textfiled with UTF8 chars was applied.
fix the 2 problems mentioend below:
- Fixed buggy handling of UTF8 characters in textfields in WINGs.
- Fixed segfault in WPrefs when some font description is missing from the
configuration file.
WINGs based applications should now work with both KDE and GNOME
applications (Sylvain Reynal <sreynal@nerim.net>)
- better check for the XDND protocol version when interoperating with other
applications. As it seems xdnd version 3 (which WINGs supports) and newer
are not backward compatible with xdnd version 1 and 2. This is why WINGs
applications cannot interoperate with GNUstep applications (which uses
xdnd version 2). Xdnd version 4 and 5 are backwards compatible with
version 3 though. (Sylvain Reynal <sreynal@nerim.net>)
small integer and causing unexpected color releases that can crash
Window Maker (Martin Frydl <martin.frydl@systinet.com>)
- fixed a small memory leak in WINGs/wview.c caused by not releasing the
background color of a view (Martin Frydl <martin.frydl@systinet.com>)
on 64bit platforms (Max Loparyev <max@city.veganet.ru>)
- fixed issue with icon colors on big endian platforms
(Max Loparyev <max@city.veganet.ru>)
patch based on a previous patch by Vladimir Nadvornik <nadvornik@suse.cz>
