We can get rid of one overall tab by moving the
if(swpanel)
test -- which was done everytime in each individual case --
to the beginning, therefore encompassing all cases.
for arq in `git ls-files *.c`; do
echo $arq;
indent -linux -l115 $arq;
done
The different line break at 115 columns is because
I use a widescreen monitor :-)
GCC has an extension to deal with ranges within case statements.
Let's use it to make the code more readable and ~5% smaller,
[mafra@Pilar:wmaker.git]$ size src/event.o.*
text data bss dec hex filename
13087 0 1056 14143 373f src/event.o.new
13711 0 1056 14767 39af src/event.o.old
gcc-4.3.2 warns:
defaults.c: In function 'getModMask':
defaults.c:2586: warning: comparison of unsigned expression < 0 is always false
The line in question is
if (mask < 0)
and 'mask' is the return of wXModifierFromKey() which is an 'int' and can
indeed return a negative value (see src/xmodifier.c), so let 'mask' be
an 'int' too.
There is no point in having parameter in wDefaultsCheckDomains() and
not using it, so let's simply remove the parameter altogether and
avoid silly-looking things like
wDefaultsCheckDomains("bla");
gcc was complaining in a few places things like:
defaults.c:890: warning: comparison between signed and unsigned
so let's just make the loop counting variables be unsigned, as
the never get negative anyway.
I also spotted other two variables which can be unsigned too.
gcc-4.3.2 warns:
defaults.c:3136: warning: declaration of 'index' shadows a global declaration
/usr/include/string.h:309: warning: shadowed declaration is here
and in a few other places too. Fix this by renaming 'index' to 'widx'.
GCC warns:
event.c: In function 'handleDestroyNotify':
event.c:676: warning: declaration of 'index' shadows a global declaration
/usr/include/string.h:309: warning: shadowed declaration is here
event.c: In function 'handleKeyPress':
event.c:1435: warning: declaration of 'index' shadows a global declaration
/usr/include/string.h:309: warning: shadowed declaration is here
So let's rename "index" to "widx".
Note that there is a more serious shadowing in this same function,
event.c:1686: warning: declaration of 'wwin' shadows a previous local
but this is more complicated to solve.
inotifyHandleEvents() was allocating a buffer of size
(sizeof(struct inotify_event) + FILENAME_MAX)*1024
where FILENAME_MAX is #defined to be 4096 in stdio_lim.h, therefore
it was more than 4 MB!
Reduce it by using 16 instead of FILENAME_MAX and 512 instead of 1024.
Now valgrind does not complain about things like
Invalid write of size 8
at 0x42002F: inotifyHandleEvents (event.c:323)
by 0x7FF00020F: ???
Address 0x7febfc148 is on thread 1's stack
I also made some small coding style changes.
When investigating possible memory leaks with 'valgrind' I noticed
this leak report:
602 bytes in 13 blocks are definitely lost in loss record 77 of 128
at 0x4C2362E: malloc (vg_replace_malloc.c:207)
by 0x4576ED: wmalloc (memory.c:88)
by 0x45B4F7: wstrconcat (string.c:214)
by 0x426FC2: main (main.c:608)
which happens here,
str = wstrconcat("WMAKER_BIN_NAME=", argv[0]);
putenv(str);
There is a comment further below (in another context)
/* return of wstrconcat should not be free-ed! read putenv man page */
so this leak report is probably a false positive anyway. However,
https://www.securecoding.cert.org/confluence/display/seccode/POS34-C.+Do+not+call+putenv%28%29+with+a+pointer+to+an+automatic+variable+as+the+argument
has some nice discussion about putenv() and after reading it I decided to
use setenv() instead, making 'valgrind' happy along the way. It also
makes the code a bit simpler, avoiding a call to wstrconcat().
I also changed the name of another variable called 'str' to 'pos', just
in case.
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>
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>
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>
belong to, that works without auto-arranging the icons, while still avoiding
multiple icons in the same spot by moving the miniwindows to a new slot if
their old slot was occupied in the meantime.
- double clicking an appicon will also raise the miniwindows that belong to
that application to the front (along with the normal windows).
- 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)
the old .AppInfo/... to the new Library/WindowMaker/... on the fly when
Window Maker starts.
This should allow a transparent transition without any need for users to do
anything.
in the first place in his trivial 10 line patch which only attempted to
replace one path with another.
He must be a big time user of his own patch, to not have noticed where the
paths pointed after his change.
