The problem was the following. While alt-tabbing from one
window to a xterm, wait for the xterm to be raised but
keep the alt key pressed. Now move the mouse cursor
over the xterm and release the alt key.
The result is a xterm in a zoombie focused state; its titlebar
has the focused color but xterm itself is not focused and does
not accept any input.
Fix this by reinstating the check for a NULL pointer from
wSwitchPanelHandleEvent() before changing focus. That function
detects if the mouse cursor moved over to the same window which
is currently being pointed out by the switchpanel, and returns
NULL in this case (the check for panel->current != focus fails).
Thanks to Paul Harris for reporting it!
If we compute the maximus geometry in only one pass through
the window list, the order in which the windows appear in
the list can affect the outcome.
That is because before computing the intersections in the
y-projections we update the y coordinates from whatever window
which happened to change the new_y coordinate during the
previous x-intersection computations, but that may not be _the_
blocking window which decides the final positions in the y axis.
Therefore we may find that this "intermediate window state"
has a non-vanishing y-intersection with another one -- and
be blocked by it -- even though that should not be the case for
the final outcome.
So to avoid that we first scan through all the windows to decide
the final maximumized coordinates in the y axis. Only after that we
compute the x-coordinates.
This patch modifies the linking of the WINGs libraries
to create a shared library. wmaker used to do this, but
it was dropped around wmaker-0.90/0.91.
The shared .so library is needed when compiling and running
the wdm display manager and any other programs which link
to libWINGs.
Submitted by: Gilbert Ashley
Origin: ALT/Sisyphus Linux
When maximumizing a window which has the full_maximize attribute
set we have to consider two possibilities:
1. If the new y coordinate is zero it means that no other
window blocked its maximumization up to the top of the
screen, so we want to put the titlebar outside.
2. If the new y coordinate is not zero it means that another
window in the current workspace blocked its way to y = 0.
In this case we do nothing with the titlebar.
Note that there is another possible fine tunning which is not
addressed in this patch, which is to consider the resize bar.
Let's avoid checking the existence of a border every time
we want to adjust the widths. So we'll always subtract the correction
factor, which is zero in case the window has no border.
It is easier to read the computations if the variables
have shorter names. At the same time it avoids reading
the struct array elements repeatedly, so as a bonus
misc.o gets 64 bytes (0.5%) smaller
[mafra@Pilar:wmaker.git]$ size src/misc.o.*
text data bss dec hex filename
11125 0 4104 15229 3b7d src/misc.o.new
11189 0 4104 15293 3bbd src/misc.o.old
When changing workspaces, after focusing new window, wmaker handles all
pending events. If it receives another change-workspace combination,
you may end up with a workspace without any focused window.
Ctrf-F1 and Ctrl-F2 used to switch to 1st and 2nd workspaces.
Hold Ctrl and press F1 and F2 almost at the same time.
This patch ignores all change-workspace commands while workspace
change is in progress.
See also https://bugzilla.altlinux.org/show_bug.cgi?id=7230
[crmafra: Thanks to Alexey I. Froloff for the above explanation]
The man page of XChangeProperty() says:
"If the specified format is 32, the property data must be a
long array."
And as we call it with format 32, the type of 'data' must
be 'long'. It happens to work nowadays in 32-bit architectures
because sizeof(CARD32) = sizeof(long), but that is no longer
true in 64-bit mode.
This patch was downloaded from
www.openbsd.org/cgi-bin/cvsweb/ports/x11/windowmaker/patches/patch-WINGs_wwindow_c
and I thank Alexey I. Frolov and Vladimir Nadvornik for helping me
to understand it on a wmaker-dev thread.
For those not familiar with the way Macs cycle windows, the Command-Tab
sequence (Alt-Tab elsewhere) switches between DIFFERENT application windows
and Command-Grave (key above tab) switches between windows owned by the
SAME application as is currently focused. So if you had three Safari and
two Finder windows open, and Safari had focus, Command-Tab would switch to
Finder; Command-Tab would switch back to Safari; Command-Grave would switch
to a different Safari window etc.
This patch implements "something like" the above by only populating the
switchpanel with windows matching the currently-focused WWindow's wm_class
when the new cycling mode is activated. In practice this means you can
switch to The Next XTerm or The Next Firefox Window using this method.
The configuration names for these new shortcuts are GroupNext and
GroupPrev. The patch tells WPrefs.app about them. Of course switching to
The Next Window is still possible with the (unchanged) FocusNext and
FocusPrev keys.
Allow wmsetbg to revert to pre-0.90.0 behaviour when choosing a
background image that is large enough to span several heads in a
Xinerama setup. If the -X flag is passed to wmsetbg, the background
image will be stretched to fill the logical screen (as it would be by
default in older versions of wmsetbg) instead of being tiled across
screens.
Shift the workspace name, shown when switching workspaces, by 32
pixels. This is purely for aesthetic reasons. It just looks better
(IMO) than having the name flush against the screen edge.
When switching workspaces, force the name to be shown entirely within
one head of a Xinerama display. Previously the name would span heads if
set to TOP, CENTER or BOTTOM alignment, and was hence hard to read when
the display comprised an even number of heads.
This patch combines two small patches which fix issues with x86_64 and mmx in
the configure script.
Submitted by: Gilbert Ashley
Author: unknown?
Origin: ALT/Sisyphus Linux, Alexey Voinov <voins@altlinux.ru>
If the old_geometry coordinates were saved while the window
was in another xinerama head, use current coordinates as
the old ones to avoid making the window jump heads when
un-maximizing it.
This patch removes bits and pieces of xmu that for some reason
have been bundled with wmaker. I can very well imagine that at the time
they were bundled, xmu was not, was not available everywhere, or
whatever.
I couldn't come across a system that doesn't have these things in its
system-supplied x libs, though i've been carrying this since january,
and my memory is quite flakey at times.
certainly nothing xorg is at danger, nor xfree86 dating back to at
least 3.3. i believe this stuff should be everywhere that calls itself
to be on par with x11r6.3 at the very least.
it would be incredibly useful if people having access to commercial
unixes could check this on things released in the past, say, 15 years.
i believe back then i had solaris 8+and sco openserver 5+ covered.
When a maximized window is resized (either using wmaker or because the
application changed the window size), and you want to maximize it again,
you first have to unmaximize it (because wmaker thinks the window is still
maximized), and only then you can maximize it. The following patch
corrects this behaviour.
The patch "Clean up maximization and un-maximization logic" introduced
a regression wrt to the left/half maximization feature, due to a C
operator order precedence issue.
With this patch, minimized windows do not reshuffle anymore.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361241
where Martin Hinsch reported:
"The behaviour of icons (minimized applications) is severely broken when
automatic placement is switched on.
* When switching the workspace icons often stick thereby covering (and
hiding) icons on the workspace one is switching to.
* After minimizing an application, clicking (singly or doubly) on one of
the icons causes all of them to reshuffle, usually in a way that the
icon in question changes its place (which is extremely annoying).
* Icon placement ignores the dock so that icons disappear behind
it/cover it.
All of these suddenly appeared about a year ago (I think with 91.0). The
problems are not architecture-specific since they occur in exactly the
same way on my pentium machine. Wiping the complete configuration (rm -r
~/GNUstep) did not make a change either."
This fixes a compilation failure with gcc-4.3.4, where it complains
nxpm.c: In function RGetImageFromXPMData:
nxpm.c:99: error: expected expression before ] token
...
There is no point in having a buffer capable of 512 simultaneous events,
as it will typically be only 1. But increase the value for the length
of the path + filename to 64 (which is a reasonable size for a
typical /home/something/GNUstep/Defaults/WMRootmenu filename).
This patch adds history to some dialog boxes. To use it replace %a with
%A in menu file (like in "Run..." menu item). You can specify third
parameter to %A to use different histories for differen dialogs.
All history files is kept in ~/GNUstep/.AppInfo/WindowMaker/ and the number of
history lines controlled by DialogHistoryLines parameter (one for
all dialogs) defaults to 500 lines.
It also adds Tab completion.
Origin: ALT/Sisyphus Linux, Alexey Voinov <voins@altlinux.ru>
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.
