This patch fixes a small problem which only rarely occurs. If a
window is opened only for a very short time and closed right away, in
some circumstances the frame around it stays opened. It looks like
Window Maker doesn't get the destroy message. The XGrabServer call was
commented in the code so I activated it again which seems to prevent this
from happening. I think it actually make sense since the ungrab calls are
used anyway in the following code.
As pointed out by Nicolas Bonifas, wWindowCheckAttributeSanity() is
currently unused. Removing it saves 200 bytes:
text data bss dec hex filename
23476 0 8 23484 5bbc src/window.o.new
23676 0 8 23684 5c84 src/window.o.old
If menu is NULL we would have a null pointer dereference when initializing scr.
> Ie, why not move the assignment of 'src' to after the test?
I thought about this, but I checked the 3 different calls to
updateWorkspaceMenu (all in winmenu.c). They must all call
updateWorkspaceMenu with non-NULL pointers, so if we have a NULL
'menu' pointer then we obviously have a major problem and it is
probably better to crash here than to silently return and fail a
little latter.
[crmafra: edit changelog]
This animation is not as cool as the NORMAL_ICON_KABOON, so I don't
think having a choice here is justified. Let's remove this option
(it was not defined in wconfig.h.in by default) and keep using
the nicer NORMAL_ICON_KABOON.
This code makes wmaker a little bit bigger for no gain at all. I could
undefine SILLYNESS and forget it, but I actually also want a clean
source code to read. And the less code the better.
So now I won't get a different Info dialog on Christmas, but
my wmaker will also not carry around that code in the other 364 days
of the year.
As a result, wmaker gets ~1.7 % smaller
text data bss dec hex filename
448043 17424 8200 473667 73a43 wmaker.new
455340 18360 8328 482028 75aec wmaker.old
Thanks to Iains patch which showed me how to access the window hints, I
now propose the following: The resize increment is set to the closest
multiple of the size hints larger than wPreferences.resize_increment.
This should fix Carlos' complaint about fixed-increment windows resizing
too "slowly", and it also fixes my complaint about the blank space below
the last line of an xterm.
Thanks to:
Iain Patterson <wm@iain.cx>
Use height and width increment when wheel resizing if size hints are
set on a window and meaningful height and width increments are
specified.
Windows which don't care about their resize increments will have height
and width increments set to 1. For these windows - and windows without
resize hints at all - use the setting configured with ResizeIncrement.
This patch adds the ability to resize windows with the mouse wheel
while holding the Mod key. This currently ignores wWindowConstrainSize
until I can figure out a way to repeatably resize windows with
fixed size increments (like xterm) using this method.
This also adds a slider to WPrefs to choose the increment with which
the wheel will resize a window.
WINDOW_BIRTH_ZOOM was a bit lame and it makes sense to not have
it at all. So remove the trailing "2" of WINDOW_BIRTH_ZOOM2 and
make it the only choice (you can #define it in src/wconfig.h.in).
Note that it uses the same algorithm as the animation to resize,
ie zoom, twist or flip. You can choose them in WPrefs.
Two reasons for removing it:
1) I won't ever want to hear useless sounds
2) The sound support is a bit of a joke. The code is there but you have
to hunt it somewhere else (not in any repository that I know of).
In my 10 years of using wmaker, I never used it for this reason.
Now I consider having no sound in Window Maker a feature, and I like
it that way. So there is no point in carrying useless code around.
PS: There is still the code in WPrefs to be removed.
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]
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.
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.
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.
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."
