The file event.h includes the function prototypes for event.c.
The prototypes included were moved from funcs.h.
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
new window positions top left, top right, bottom left and bottom right
these new maximized positions are combinations of left, right, top and
bottom maximized positions
if a window was at x=0 or y=0, the original condition return
false and the window is not moved to original position,
but if width or height from old_geometry is set then wmaker
already saved old_geometry, and we can trust x=0 or y=0 is
original position.
- remove extern declaration in source file, use header instead
- add inclusion of header defining the functions of the file to
get the compiler to cross-check them
- marked static the functions that should not be visible ouside
their file
These functiosn were renamed:
wIconCreateCore to icon_create_core
wIconCreateWithIconFile to icon_create_for_dock
wIconCreate to icon_create_for_wwindow
Using window-supplied depth, visual and colormap information has the
side effect of causing window borders to be draw using inconsistent
colormap entries. Allocate entries from each window's colormap when
drawing its border.
Force setting the border when the window is first created so it's
guaranteed to be drawn in a consistent state.
Update the saved X co-ordinate of a window which was moved when
maximized (only) vertically so that unmaximizing the window restores
its dimensions without warping it back to its previous X position.
Similarly update the saved Y co-ordinate of a window which was
moved when maximized (only) horizontally.
Handle Maximus as a special case. We remember the Maximusized X and Y
co-ordinates then adjust the restored co-ordinates relative to the
delta between the window's position just after Maximusizing and its
position just before restoring. So for example if a window is
Maximusized, moved 100 pixels to the left and restored, it will end
up 100 pixels left of its original geometry.
Also fix "jumping window" bug reported by Christian Wittmer:
This "jumping window" happens only when you
1) open new xterm (STRG +n)
2) current position is (+64, +0)
3) maximize window vertically
4) undo maximizing
5) move window to the right or left (up or down as you like)
I moved right to (+450, +0)
6) maximize vertically again
7) and undo maximizing
8) window jumps back to (+64, ..) position
If you move a new opened window to a new position (e.g. +200, +200)
and then start with "3)". window is jumping back "+200, +200"
The functions related to colormap are moved from funcs.h to the new
file colormap.h. These files are included where needed.
The functions wColormapInstallRoot and wColormapUninstallRoot are
removed, because they are not used.
Making all in src
CC actions.o
actions.c: In function ‘wMaximizeWindow’:
actions.c:421:14: warning: ‘maximus_height’ may be used uninitialized in this function [-Wuninitialized]
actions.c:440:29: warning: ‘maximus_width’ may be used uninitialized in this function [-Wuninitialized]
actions.c:442:35: warning: ‘maximus_y’ may be used uninitialized in this function [-Wuninitialized]
actions.c:454:18: warning: ‘maximus_x’ may be used uninitialized in this function [-Wuninitialized]
CCLD wmaker
These warnings were harmless because they were at a point where
find_Maximus_geometry() had already been called. So let's simply initialize
them to zero to silence gcc.
Fons Adriaensen reported that:
> WM's 'unshade' seems to use multiple Expose events [...] even when
> all animations and 'superfluous effects' are disabled.
Typo in shade_animate() could cause windows to be animated when the
no_animations preference was set. With this patch I see fewer
XMoveWindow() calls and quicker shading.
Avoid some pitfalls with window maximization and make it behave more
intuitively. We now treat a window's vertical and horizontal
maximization as separate properties and only remember its original
geometry in a particular direction when it actually changes. We also
deliberately do not remember a window's geometry when it changes from
one maximized state to another. As a result windows can be more
reliably restored to their original size.
For example the "Maximize active window" hotkey followed by the
"Maximize active window vertically" hotkey will now result in the window
being maximized horizontally only, whereas previously the second hotkey
would have no effect because the window was already maximized
vertically. In addition selecting the Unmaximize window menu in the
same example will now result in the window being restored to its
original size. Previously the unmaximize attempt would have no effect
because the vertical maximization would have remembered the window's
"original" geometry when it was fully maximized.
Maximus is handled separately. The "Maximus" hotkey will now toggle
Maximus mode regardless of the window's current maximization state. For
example if two unmaximized windows are on screen and one is Maximusized
it will fill the space left by the second window, as before. But if the
first window is maximized and the "Maximus" hotkey is pressed the window
will now fill the same space as if it were Maximusized from its original
size. Previously the window would not change size from its fully
maximized state because the Maximus algorithm would consider
fully-maximized to be a valid Maximus size.
From the original report by Tamas Teves:
"i'm having (and have, for a long time) problems with openoffice and
java-based (perhaps only netbeans-based?) apps.
for openoffice, any menu opens in the far right edge (with xinerama,
on the far right edge of the rightmost display) of the display. it
then can be clicked and operated corretly where it appears.
as for netbeans (and jswat, which also uses netbeans platform as a
base), it's a bit more complicated, but let me try to describe. start
netbeans so that it is not maximized and not in the upper left of the
display. it works fine. move it around, still works fine, resize,
still works fine. now if i maximize it (not by moving to the upper
left corner and resizing, but by the maximize shortcut), then the
menus start acting weird. it seems that the actual position of the
mouse pointer and the hot spot of the mouse pointer get "out of sync"
so to speak, as if the hot spot stayed where the window was before
maximization.
i've made a capture which hopefully better shows what i'm trying to
say. this is a netbeans window maximized, while i'm trying to click
tools->options. the left mouse button must always be held down, or
else it instantly loses any interaction with the menus (in the capture
i released it once when i completely lost track of where i might be).
the capture is available at http://dawn.dev.hu/~ice/tmp/wmjava.avi
i'm not sure whether java stuff other than those based on netbeans
platform exhibit this behaviour. i've seen this with at least one
other nb platform stuff as well."
The fix is to call wWindowSynthConfigureNotify() after wWindowConfigure()
Non-obvious fixes:
WINGs/wfilepanel.c: Cast to void to avoid an unused calculated value
warning.
WINGs/wtabview.c: Test tab<0 to avoid a warning from the next condition
about signed overflow in an inlined invocation of the function.
Signed-off-by: Brad Jorsch <anomie@users.sourceforge.net>
When an app hides its window but doesn't exit (e.g. apps that "minimize"
to the system tray), the highlighting was not being removed.
When alt-tabbing, the tabbed-to app's icon was not getting highlighted.
Signed-off-by: Brad Jorsch <anomie@users.sourceforge.net>
This patch highlites appicon of a currently focused window.
Original-patch-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Alexey I. Froloff <raorn@altlinux.org>
MinimizeAllKey - minimize all windows on current workspace.
Original-patch-by: Pavel S. Khmelinsky <hmepas@yauza.ru>
Signed-off-by: Alexey I. Froloff <raorn@altlinux.org>
[crmafra: AllMinimizeKey --> MinimizeAllKey]
When unhiding window by clicking its appicon, unconditionaly
raise its frame.
Original-patch-by: Artem Delendik <u2u@nm.ru>
Signed-off-by: Alexey I. Froloff <raorn@altlinux.org>
By defining a struct containing the coordinates of the
windows (top, bottom, left, right, width, height) and
using a helper function to set up these coordinates, the
whole function becomes much cleaner and easier to read.
Taking the border width into account was making it hard to follow the
algorithm, and complicating things usually lead to mistakes.
In fact, in trying to account for this +/- 1 pixel issue the maximus
geometry for the requested window would sometimes overlap another window
by one or two pixels (depending if it was on the right or left). Therefore,
applying the maximus geometry to this other window in sequence would
maximize it completely instead of finding the correct tiled geometry.
So that always bugged me. Now I got tired of it and decided to kill the
whole consideration of the border width, and simply put some "+ 1"
inconditionally to be on the safe side.
Now it can happen that the windows will stay away one or two pixels,
but trying to be 'good enough' is better than trying to be 'perfect'
and getting it wrong for corner cases.
And the matter is worse because the size of xterms are 'quantized', so
changing the position of the other windows by a few pixels result sometimes
in a overlap of +1 pixel, or a distance of 1 or 2 pixels. Furthermore,
the bottom of xcalc behaves differently from the bottom of a xterm or
xjed (for xcalc the ad hoc correction for bottom_0 must be -8 in total).
But now my tests show that things are OK, and I can use maximus
for all the windows in the screen and no overlap will occur (except
if one of the windows is a xcalc, I don't know why).
It wasn't defined anywhere and when I defined it, the compilation
did not finish:
appicon.c: In function drawCorner:
appicon.c:206: error: WScreen has no member named focused_texture
appicon.c:208: error: WScreen has no member named unfocused_texture
appicon.c: At top level:
appicon.c:214: error: conflicting types for drawCorner
appicon.c:193: note: previous definition of drawCorner was here
make[2]: *** [appicon.o] Fehler 1
make[1]: *** [all] Fehler 2
make: *** [all-recursive] Fehler 1
So let's simply remove those #ifdefs.
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
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.
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.
