This patch adds the DockRaiseLowerKey shortcut, which raises/lowers
the dock depending on whether the dock is lowered/raised.
[crmafra: Reformatted Brad's patch against git repo and removed the
DockRaiseKey and DockLowerKey shortcuts ]
I don't want the (small) overhead of the window birth zoom special effects
because I like apps popping up instantly when I open them (specially now
with the SSD).
Another way to not get the birth animation is to unset "animations" in
WPrefs, but that makes the other animations which I care (ie they don't have
the effect of making my computer seem slower than it really is) go away.
Paul Harris reported that using the mouse wheel over a miniwindow
would deiconify it to a different workspace than the original one
where it was iconified.
This happens because after the window begins to be deiconified the
"residual" mouse wheel scrolling hits the workspace background, and
Window Maker changes workspace with wWorkspaceRelativeChange().
But if it all happens fast enough (so the deiconification animation
did not finish yet) the workspace will have changed before the
window reaches its final deiconified destination, leading to
the situation that Paul described in the link below.
So to avoid this, let's set a 'ignore_wks_change' variable
from wDeiconifyWindow() and make wWorkspaceRelativeChange() respect it.
Original report: http://lists.windowmaker.info/dev/msg00821.html
Since a single default visual ID cannot be used for multiple screens, thus
Window Maker refused to start. There is now a global function for getting the
default visual ID. The command line argument --visual-id can be a comma
separated list of visual IDs for each screen. A default value is only set for
the first screen.
Part of the menu on Debian systems is stored in
/etc/X11/Windowmaker/menu.hook. This patch will add this path to
src/wconfig.h.in when building the Debian wmaker package. This is
what is done in the Debian version of wmaker 0.92.0.
This patch fixes a minor bug in Maximus: the new window size didn't take the
border into account. This bug was particularly visible with the
"do not cover dock" option turned on.
New windows will only get focused if the mouse is on the same screen.
The code doesn't handle multiple heads but since it's just one screen
the function works as usual. Checking the head and assign the focus only
if the window is on the same head might be a good idea. Making the whole
stuff optional might be even better.
This patch fixes a problem with restarting Window Maker in multi-screen
environments. The code for setting the background by calling wmsetbg
changes the environment. In multi-screen setups the DISPLAY variable
becomes :0.0 instead of :0 (for example). The restarted Window Maker
process therefore only manages one screen.
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.
Let's remove the configuration options about "sound" from
WPrefs (as it was never fully functionall anyway) and from
configuration files.
Remove also the xpm and tiff icons.
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.
