Public Git Hosting - wmaker-crm.git/log

Add option to allow starting DockApps with a single click

This patch is from the contrib directory. It adds an option to allow starting
DockApps with a single click. It's a handy option that adds only a few lines to
the code.

It is a good feature patch example because it includes modifications
to the WPrefs application so that the feature can be easily enabled or
disabled. The one-click ability allows wmaker to integrate more seemlessly with
programs like ROX-Filer which can be configured to use single or double click
actions.

The README in the contrib/ directory says,

author:
Sebastien Bauer <seb_bauer@bigfoot.com>
John Morrissey <jwm@horde.net>

updated for Window Maker 0.65.0 by:
Daniel Richard G. <skunk@graphics.lcs.mit.edu>

updated for Window Maker 0.80.2 by:
Martial Daumas <martial@nasgaia.org>

update for 0.80.2+ by:
steve lion <steve.lion@verizon.net> and vlaad

Clean up maximization and un-maximization logic

We should not try to un-maximize the windows from inside
the function wMaximizeWindow(), as that makes no sense.

If the window is already maximized then we don't call
wMaximizeWindow() anymore and call wUnmaximizeWindow()
instead, which will use the old geometry regardless
of which maximization is active (horizontal, vertical,
maximus, etc). And the old geometry now is also saved
when we enter wMaximizeWindow().

So when we call wMaximizeWindow() or wUnmaximizeWindow()
we really mean "maximize to the specified state" or
"go back to whatever old geometry coordinates we had before".

Maximus: Tiled Maximization

This patch introduces the "tiled maximization" feature, a.k.a. Maximus.

By pressing the keyboard shortcut associated with Maximus, the focused
window will be maximized to the greatest area satisfying the constraint
of not overlapping existing windows.

Fix for omnipresent AppIcon bug at startup

    Bug overview: right after start up, omnipresent AppIcons (living in the Clip)
    are displayed but non-functionnal.

    How to reproduce it: place two AppIcons in the Clip, make the first one (A)
    omnipresent and leave the second one (B) as is. Make the Clip "autocollapse".
    Switch to the second workspace and restart wmaker. Wmaker starts in the first
    workspace; the Clip is closed (its text color corresponds to the closed state,
    AppIcon B is not shown). However, AppIcon A is displayed.  Moreover, A does
    not react when the Clip expands or collapses.  Finally, a click on A makes it
    disappear. Fortunately, changing to another workspace fixes the problem
    definitively.

    Explanation and correction: internally, wmaker maintains as many clips as
    workspaces. When the user switches to another workspace, the omnipresent
    AppIcons are moved to the new "current" clip. In the situation above (trying
    to reproduce the bug), when wmaker restarts, the omnipresent AppIcons are
    restored in the second workspace, whereas the first workspace is active. In
    the previous code, a "hack" (calling XMapWindow()) unconditionally displayed
    the omnipresent AppIcons. The proposed patch makes sure the omnipresent
    AppIcons are moved to the first workspace on wmaker startup.

Clean up #ifdef mess

Use enum instead of #ifdef maze for enumerating keybindings

Gobble "spurious" EnterNotify events when moving an appIcon or a dock

This is a bug fix. Bug overview: if an AppIcon is moved rapidly over a Clip
    set to auto-expand, the latter may erroneously auto-expand afterwards.

    How to reproduce it: set a Clip to auto-collapse, and make sure it contains a
    (random) AppIcon, so as to easily visualise its open/close state. Now move
    rapidly an AppIcon over the Clip. Try to move it so fast that the cursor
    sometimes is out of the AppIcon's tile. Then, replace the AppIcon out of the
    Clip.

    Explanation and correction: if, while the AppIcon was being moved, the mouse
    cursor entered at least once in the Clip's tile, the latter is going to
    receive an EnterNotify event (after the AppIcon is replaced) and thus expand
    automatically after the relevant delay. The solution is to simply "gobble"
    (i.e., ignore) all EnterNotify events when moving an AppIcon.

Fix half_scr_width calculation

Moved the half_scr_width calculation to after the

usableArea = wGetUsableAreaForHead(scr, head, &totalArea, True);

call. This fixes the problem where windows that get "half screen
maximized" cover the dock or clip.

Use half_scr_width instead of computing it each time

Let's use

half_scr_width = (usableArea.x2 - usableArea.x1)/2;

to shorten the expressions in the left/right half maximize
code.

Increase the readability of wUnshadeWindow() and wShadeWindow() a little bit

Instead of open coding the animation routines in the function bodies,
put them in a helper function called shade_animate(wwin, what), whose
second argument can be SHADE or UNSHADE.

Trivial coding style changes

Some trivial style changes I made while reading src/placement.c

k&r->ansi some stuff

ansify and "fix" function pointer declarations

Left Half / Right Half Maximize

This adds Left Half / Right Half Maximize capability to WindowMaker.
It allows you to maximize a window to only the left or right half
of your screen.

It is useful on widescreen displays where one might to bring up
two different windows side-by-side.

Define TITLEBAR_HEIGHT in default configuration file

...and use it in src/placement.c

And while we are at it, clean up a bit the visual of wconfig.h.in

Make wmaker 0.11% smaller by avoiding code duplication

This patch cleans up an obvious code duplication case in the
different "placement" algorithms.

Avoid this needless repetition by using a helper function,
which in turn lets those functions a bit easier to read and
also makes wmaker 0.11% smaller :-)

[mafra@Pilar:wmaker.git]$ size src/.libs/wmaker.*
   text    data     bss     dec     hex filename
619824   19160    8544  647528   9e168 src/.libs/wmaker.new
620552   19160    8544  648256   9e440 src/.libs/wmaker.old

Nightly Build script can now deal with testing and unstable branches.

Show app name in Kill Application dialog

The "Kill Application" dialog window doesn't always show the
application name when killing DockApps. It shows its wm_class
instead, which is not always the same as the app name.

This patch allows the Kill Application dialog window to show
the application name in the window -- as expressed by using the
basename of the path to the application.

[crmafra: Added wtokensplit() to get only the app name]

Miscellaneous fixes from OpenSuse

These are some of the fixes sent to the wmaker-dev list by
Vladimir Nadvornik, with minor modifications to address Dan
Pascu's concerns.

Original-post: http://lists.windowmaker.info/dev/msg00293.html

Add config option to supress focus requests across workspaces

In commit d6c134f420bfa1cd6b6a9474d01548933b559901 ("Do not switch
workspace to follow new windows in others") the default behavior
was changed, and workspace switching to follow focus requests was
strictly forbidden.

Although that seems to be a sane thing to do by default, that raises
concerns about whether Window Maker could be more flexible in that
respect -- allowing the user to choose which applications are or
are not allowed to do that.

This patch adds such configuration, located in the "Advanced Options"
submenu of the top-level "Attributes" menu.

Adapted nightly build script to coexist with new 'next' branch.

Fix NULL pointer dereference

Some weird applications like Safari for Windows running on CXOffice
or some applications running on Wine were causing wmaker to crash.
So let's not rely on a window's `frame' property to be not NULL in
src/wmspec.c.

Original-post: http://lists.windowmaker.info/dev/msg00161.html
See-also: http://lists.windowmaker.info/dev/msg00222.html

Do not switch workspace to follow new windows in others

New windows should only be focused if they are in the current workspace.
Not performing this check can lead to WM switching workspaces if a
window is opened which:

   (a) is configured to appear in a particular workspace

and

   (b) sends a _NET_ACTIVE_WINDOW message to give focus to
       something, e.g. a sub window.

This behaviour was observed with firefox if a session with more
than one tab open was restored at startup because:

"If a Client wants to activate another window, it MUST send a
   _NET_ACTIVE_WINDOW client message to the root window:"

Original-post: http://lists.windowmaker.info/dev/msg00442.html

[crmafra: Added comment]

Add debianisation code and automatic build script

Add two menu files from the Debian package

Add GLOBAL_DEFAULTS_SUBDIR and fix a syntax error in wmlib/Makefile.am

Up the version number for the GIT version to 0.93.0-pre

swpanel: Consider also the release of FOCUSPREV

The switch panel was not being destroyed with the realease of
FOCUSPREV, only with FOCUSNEXT. Fix this.

One can reproduce this bug as follows.

In the "Keyboard Shortcut Preferences" of WPrefs set "Focus next window"
to e.g. "Alt+Tab" and "Focus previous window" to "Ctrl+Tab".
The switchpanel is not destroyed if we release "Ctrl+Tab" but it
is upon releasing of "Alt+Tab".

Retrieved-from: http://git.altlinux.org/people/voins/packages/?p=WindowMaker.git;a=commit;h=51c95a55c9310f499b1fdeca138106ca7bf74423

[crmafra: Commit log]

Remove LITE config option

Why?

     1. The reason for its existence is to "Disable some stuff that are
        duplicated in kde", and I don't think I will ever need that.
        Furthermore, even the description in the configure script reads
        "disable some stuff (dont use it)".

     2. It makes the code uglier at some places, e.g.,

         #ifdef LITE
                {
         #if 0
                }
         #endif
         #else

                if (!wRootMenuPerformShortcut(event)) {
         #endif

        which by the way is the ugliness which motivated this patch.

     3. Does not even compile anymore. It fails with

          CC dockedapp.o
          CC event.o
       event.c: In function 'executeButtonAction:
       event.c:711: error: WScreen has no member named root_menu
       event.c:712: error: WScreen has no member named root_menu
       event.c:713: error: WScreen has no member named root_menu
       event.c:715: error: WScreen has no member named root_menu
       event.c:720: error: WScreen has no member named switch_menu
       event.c:721: error: WScreen has no member named switch_menu
       event.c:722: error: WScreen has no member named switch_menu
       event.c:724: error: WScreen has no member named switch_menu
       make[2]: *** [event.o] Error 1
       make[1]: *** [all] Error 2
       make: *** [all-recursive] Error 1

       But instead of fixing this (it would be trivial), let's get
       rid of the whole ugliness altogether.

Add spaces to gcc 'case' range extension

According to the gcc manual, that is safer.

Fix function prototype declaration

It is safer if the functions are declared with proper
prototype specifications.

This patch addresses some of the warnings with -Wstrict-prototype,
like this:

event.c:105: warning: function declaration isn't a prototype

WPrefs: Fix crash due to wtokenfree() memory leak fix

After the fix to avoid a memory leak in wtokenfree(), WPrefs crashes
when opening the 'Applications Menu Definition' dialogue.

The problem is that WPrefs code relied on the fact that the first token
in the array would not be free'd by wtokenfree(), a misbehaviour which
is correctly addressed with this patch.

Retrieved-from: http://www.mail-archive.com/ports@openbsd.org/msg12731.html

[crmafra: small changes in the commit log from the webpage]

WINGs: Fix memory leak in wtokenfree()

wtokenfree() does not free the first entry of an array.
If count is 1 then

while (--count)

will be

while (0)

and the inner body of that while-loop will not be entered.
Therefore a memory leak happens every time wtokenfree() is called.

Retrieved-from: http://paldium.homeunix.org/tobias/wmaker/patches/

[crmafra: This patch, altough correct, breaks WPrefs.app, which will be
fixed by the next patch. ]

swpanel: Start with the first window when all are minimized

When all windows are minimized, the switch panel cursor is
initially on the second window in the list. With this patch
it will be on the first window.

swpanel: Fix stacking issue with swpanel escape handling

Daniel Déchelotte reported one problem with the escape handling in
the switchpanel:

   "Start with two windows: a fullscreen one, and a smaller window
    that appears above the fullscreen one. With the mouse, focus the
    bigger window. Start alt-tabbing, then press Escape. The bigger
    window will then be focused (good) *and raised* (small problem)."

Fix this by adding a test for the escape key before calling
raiseWindow().

swpanel: Factor out if (swpanel) test

We can remove redundand tests in each "case:" inside the
switch if we do it in the beginning.

swpanel: Clean up "case ButtonRelease"

Get rid of 2 tabs indentation by removing a
not-strictly-necessary temporary variable.

swpanel: Clean up StartWindozeCycle() a bit more

We can put the test for 'newFocused' inside change_focus_and_raise()
to clean up the code a little bit.

Fix multiple errors in findfile.c

Problems:

1.

  During expansion of path, the resulting path can overflow the supplied
  area of PATH_MAX+2 (buffer as well as buffer2). A tampered environment
  variable can be used to modify program flow.

Proof:
      [note: wmaker has been compiled with propolice]
      $ export A="[tested with 4096x A]"
      $ GNUSTEP_USER_ROOT="\$A\$A/\$A/\$A/" wmaker --for-real
      *** stack smashing detected ***: wmaker terminated
      Aborted

2.

  Way too many functions handle a return value of NULL for wexpandpath
  improperly, resulting in segfaults (and maybe other problems). To
  prove the existance of these issues:

Proof:
      $ GNUSTEP_USER_ROOT=~nouser wmaker --for-real
      wmaker error: could not get password entry for user nouser: Success
      Segmentation fault

Solution:

     hard exit with error message about what is going on.

3.

  The improper parsing of environment variables can lead to expansion
  of path names that were not intended to be expanded.

     (a) If a string like "$(var" is found, Window Maker tries to expand "var"
      (environment variable) although the syntax is wrong.

Proof:

      $ export PROOF=foo
      $ GNUSTEP_USER_ROOT=/\$\(PROOF wmaker --for-real
      wmaker warning: could not find user GNUstep directory (/foo/Defaults/WindowMaker).

      (b) If the variable out of a) cannot be resolved, a closing bracket will be
         added.

Proof:

      $ unset PROOF
      $ GNUSTEP_USER_ROOT=/\$\(PROOF wmaker --for-real
      ./wmaker warning: could not find user GNUstep directory ($(PROOF)/Defaults/WindowMaker).

Author: Tobias Stoeckmann
Retrieved-from: http://paldium.homeunix.org/tobias/wmaker/
Submitted-by: Gilbert Ashley <amigo@ibiblio.org>

Remove useless tests

There is no point in checking

if (dock_state)

if the function would have already returned with
the check if(!dock_state) right above.

Retrived from http://yo.dan.free.fr/wmaker.phtml.en

[crmafra: wrote the commit message]

Fix use of uninitialized variable

Gcc-4.3.2 warns:

texture.c: In function 'wTextureMakeFunction':
texture.c:393: warning: 'fallbackColor.pixel' is used uninitialized in this function

Based on a patch by Vladimir Nadvornik.

Less strict font requirements

Fixes bug:

https://bugzilla.novell.com/show_bug.cgi?id=154758

Fix findBestIcon()

This patch fixes the issue described here:

https://bugzilla.novell.com/show_bug.cgi?id=371974

Fix "smart" placement bug when there are shaded windows in other workspaces

Bug overview:
    New windows are sometimes mis-placed when the "smart" algorithm is used.

How to reproduce it:
    be sure (with WPrefs.app, for instance) to use the so-called "smart"
    window placement algorithm. In an empty workspace, open a first window
    (for instance, an xterm). The window should appear at the upper left corner.
    Shade it (hide its contents below its title bar by double-clicking on it)
    and select another empty workspace. Open another window. Instead of placing
    it at the exact same place as the first window, wmaker places the new
    window a little bit lower, or frankly to the right.

Explanation and correction:
    when placing a new window, wmaker avoided all shaded windows, instead of
    only avoiding the shaded windows on the active workspace.

Fix focus issues with the switch panel and auto-focus

1. Setup two windows in a workspace, one at the center and the
   other at a corner. Move the mouse to the center of the screen, so
   that the focus goes to the center window. Now, with the help of the
   keyboard (with Alt-tab, typically), try and switch the focus to the
   other window. In doing so, the switch panel shows up, gives the
   focus to the other window and then disappears. However, its
   disappearance make it seem to wmaker that the mouse has just
   entered the center window, so wmaker gives the focus to that
   window again.

   2. It is a lit bit more involved. "Raise window when switching
   focus with keyboard" needs to be set. In a given workspace, maximize
   a first window A, then setup "above" window A two windows B and C
   (one in the upper left corner and the other one in the lower right
   corner, for example). Move the mouse so as to give the focus to
   window B. Press the Alt key, hit the key tab once (window A moves
   up to the "top"), then another time (window C is then selected).
   Eventually relase the Alt key: window B is given the focus again.

Correction: it is a matter of ignoring some (EnterNotify) events
when the switch panel is active or has just been used.

Escape key handling in switchpanel

Pressing the escape key (ESC) while the switchpanel is active
cancels it and gives the focus back to the window which had it
before the switchpanel was invoked.

If all windows are minimized before the switchpanel was called,
they will continue to be if ESC is pressed.

In other words, pressing ESC is like going to the parallel universe
where you never entered the switchpanel in the first place.

Based on a patch by Nicolas Bonifas from 17.08.2009.

Use helper function in StartWindozeCycle()

This way we avoid code duplication in 6 places.

This changes the previous behavior of the first
instance because the helper function has an extra

CommitStacking(scr);

compared to the original code. But it should not
hurt to have it.

Clean up coding style in StartWindozeCycle()

No functional changes were made apart from
setting the various KeyCode variables at the
same time as defining them.

Clean up StartWindozeCycle()

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.

Change to the linux kernel coding style

    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 :-)

Make drawIconProc() static

It is used only inside src/dialog.c

Clean up case switching in handleKeyPress()

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

Remove unsigned type from 'mask'

    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.

Sanitize calling sites of wDefaultsCheckDomains()

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");

Make loop variable be unsigned int

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.

Fix variable shadowing

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'.

WMCreateFont: Add missing wfree()'s

I removed (forgot) them when in commit ee28b0257ab5 ("Avoid returning
font=NULL in WMCreateFont()"). Add them back.

handleKeyPress: Fix shadowing of global 'index' variable

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: Reduce buffer size to avoid huge memory consumption

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.

real_main: Use setenv() instead of putenv() in remaining places

It simplifies the code a bit.

real_main: Use setenv() instead of putenv()

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.

Fix improper use of function sentinel

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.

WPrefs: Remove unused function updateThemeList()

Remove unused variables

GCC -Wall complains about them.

Make compilation even less verbose

Add "-s" flag to MAKEFLAGS if --disable-verbose-compile
is enabled.

Remove prototype of unused function StartLogShell

Fix buffer overflow in SendHelperMessage()

The following fixes a buffer overflow in SendHelperMessage() which i
started seeing recently on x64.

Remove unused StartLogShell function.

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

Check for argc==0 when calling wtokensplit()

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>

xinerama switchpanel corruption fix

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>

Fix mixing pixels when maximizing borderless windows

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>

Fix workspace limit segfault

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 ]

avoid integer overflow

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...

Sync comment with reality

Or rather, remove possibility for comment to diverge from reality

Fix menu positioning bug

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.

Fix gcc warnings

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'

Compilation: Add a few spaces in the output

It is even better to have the messages displayed a few spaces
off from the left screen border.

The inspiration comes from the Git compilation output.

Fix buffer overflows in shortcut and workspace name handling

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.

wmaker: Fix compiler warnings about pointer <--> integer conversion

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

automake: Fix warnings about underquoted calls to AC_DEFUN

This patch fixes warnings from automake versions >=1.8 about
underquoted calls to AC_DEFUN.

I followed the recommended modifications of
http://sources.redhat.com/automake/automake.html#Extending-aclocal

Makefile: Beautify compilation messages

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
[...]

Use inotify to check for changes to the defaults database. Workaround for

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.

Fix periodic focus bug

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>

Workaround for Composite problems when default depth is not 24.

This is really a workaround patch, the proper fix would be to have
WindowMaker know about Composite, and take advantage of it's features.

WINGs/wfont.c: Avoid returning font=NULL in WMCreateFont()

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>

wmaker: Reduce wakeups to zero

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>