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
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".
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.
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.
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.
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.
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.
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.
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
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]
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
In commit d6c134f420 ("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.
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]
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]
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.
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
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]
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. ]
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().
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>
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]
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.
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.
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.
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.
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.
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 :-)
