If we Restart() directly, the windows with titlebars come back N pixels
below their original positions before the xrandr-induced restart, where
N is the titlebar height.
To avoid this issue, let's do the proper restart preparation before
actually calling Restart().
Let's also grab ConfigureNotify in the event loop as in the patch
here: http://lists.kde.org/?l=kwin&m=116429907520188&w=2
(thanks to Tamas for pointing it out).
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
Some people using nvidia and/or playing some games (e.g. Einstein)
are reporting some issues with the restart induced by the
resolution changing. Let's disable it by default.
People without nvidia cards etc can still enable it with
--enable-xrandr.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
The code was added in 2001 in commit acdc0e3d6b for
"backwards compat". This motivation no longer exists in 2010,
so there is no reason to keep a private implementation of
a standard function from the C library.
Instead of using the --disable-verbose-compile hack, let's
use the standard option --enable-silent-rules (or 'make V=0' directly)
available with autoconf 1.11 and higher.
This is enabled in autoconf by using 'silent-rules' in AM_INIT_AUTOMAKE.
The verbosity of compilation is reduced in a similar manner as using
the --disable-verbose-compile option, so we can remove all that ugly
hackery.
According to the autoconf manual, using AS_HELP_STRING is recommended
to avoid having to manually adjust the alignment of help text
in ./configure --help
WUtil.h:212: warning: function declaration isn’t a prototype
WUtil.h:259: warning: function declaration isn’t a prototype
WUtil.h:300: warning: function declaration isn’t a prototype
WINGsP.h:593: warning: function declaration isn’t a prototype
WINGsP.h:599: warning: function declaration isn’t a prototype
WINGs.h:616: warning: function declaration isn’t a prototype
raster.c:295: warning: no previous prototype for ‘calculateCombineArea’
This patch makes wmaker automatically Restart() to take into account
resolution changes done by xrandr.
The motivation to write this patch is that when I start my laptop connected
to an external monitor (VGA1), the resolution in the monitor is initially
wrong (perhaps this is a bug in XOrg or OpenSuse, but anyway), so I always
do this after starting wmaker:
xrandr --output VGA1 --preferred
The resolution in the external monitor gets fixed, but wmaker does not
recognize the change automatically and I have to manually restart it.
So this patch avoids the last step by making wmaker be XRandR-aware.
Wmaker now restarts automatically when it receives a RRChangeScreenNotify
event and I don't have to do the last part of the silly procedure described
above.
I am not sure if restarting wmaker is the most elegant solution, but
it at least solves part of my issue with wmaker + xrandr.
If a window has the skip_window_list flag set wmaker currently not only skips
this window from the window list (F11) but also from the switchpanel (TAB).
This patch makes skip_window_list-windows appear in the switchpanel and be
skipped only in the window list, strictly honoring what the name of the flag
is supposed to mean.
The motivation for this is that I have lots of workspaces and almost all of
them has a xterm, so that I set the skip_window_list for the xterms not to
overcrowd the window list. But I still want to alt+TAB to xterms on the current
workspace.
In addition to that, now the "internal window" flag is not checked before
appearing in the switchpanel.
gcc-4.4.1 was complaining:
fontconv.c: In function ‘mapWeightToName’:
fontconv.c:114: warning: field precision should have type ‘int’, but argument 4 has type ‘size_t’
fontconv.c:114: warning: field precision should have type ‘int’, but argument 4 has type ‘size_t’
fontconv.c: In function ‘xlfdToFc’:
fontconv.c:157: warning: field precision should have type ‘int’, but argument 4 has type ‘size_t’
fontconv.c:157: warning: field precision should have type ‘int’, but argument 4 has type ‘size_t’
The rationale is the same as in commit c7f2a189c4
("Fix the call to XChangeProperty() in 64-bit mode"), because we are
calling XChangeProperty() with format 32, which requires the type of
'data' to be 'long'.
As the README used to say, it was a unfinished work. If someone
wants to finish it after all these years it can be recovered
from the logs. But meanwhile let's not carry dead code around.
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.
It addresses this warning
dialog.c: In function ‘LoadHistory’:
dialog.c:209: warning: passing argument 2 of ‘WMFindInArray’ from incompatible pointer type
../WINGs/WINGs/WUtil.h:455: note: expected ‘int (*)(void *, void *)’ but argument is of type ‘int (*)(const void *, const void *)’
but induces others in other places. One of them was this one
window.c: In function ‘wManageWindow’:
window.c:782: warning: passing argument 2 of ‘WMFindInArray’ from incompatible pointer type
../WINGs/WINGs/WUtil.h:455: note: expected ‘int (*)(const void *, const void *)’ but argument is of type ‘int (*)(void *, void *)’
which is fixed by constifying the arguments of matchIdentifier(). The other warnings are
fixed similarly.
WindowMaker.h already #includes wconfig.h, which checks exactly
the same thing. So remove it from WindowMaker.h.
However, it would be better if WindowMaker.h didn't include
wconfig.h at all. The only reason I see for the inclusion is
the check for KEEP_XKB_LOCK_STATUS, defined in wconfig.h.
But that can be probably cleaned up too (I guess modern X's
enable XKB stuff that by default, by I haven't checked)
But anyway.
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.
The non-gpl warnings in WPrefs.app/tiff/README
and WPrefs.app/README were misleading, because
they were refering to Marco van Hylckama Vlieg's
work which was licensed with OpenContent License.
But as Alfredo Kojima wrote in the Changelog in
commit f65c549814 from 30.03.2010,
Marco's icons were licensed with the GPL.
Furthermore, in an email to wmaker-dev on 10.03.2010,
Marco confirmed:
"Anyway, I have no problem with the artwork being
licensed under GPL or whatsoever."
The inspiration comes from Geir T. Kristiansen's 'genmenu' shell script
(http://gtk.no/genmenu) which I have been hapilly using for
the last 9 years or so.
That script generates the Window Maker menu by asking a few questions
and checks whether the applications in a predefined list exist in
the user's $PATH, so that the menu contains only the applications
which are guaranteed to exist and which the user cares about.
However I always thought it was a bit slow to finish, even
when having a file containing the answers to the questions to
be piped in.
And as Kristiansen states in his webpage, his script does not
support internationalization:
"If you want internationalization I really suggest you rewrite
genmenu from scratch anyway in a more sensible language and remove
other limitations while you are at it."
so I decided to rewrite in C and make it support internationalization
(only English and German so far). While I am not sure yet if I removed
"other limitations while you are at it" I definitely made it finish faster.
This C program does not make you questions though.
But in the same spirit as the author of 'genmenu', who says:
"Genmenu is a hack, deal with it, it just happens to serve my needs."
I present you 'wmgenmenu', which you can use like this:
wmgenmenu > /home/mafra/GNUstep/Defaults/WMRootMenu
and the menu is automatically generated from the list of
predefined apps which are contained in the C sources (wmgenmenu.h).
And when you generate the WMRootMenu as above, wmaker will automatically
load the new menu for you (due to the 'inotify' mechanism in wmaker-crm).
As for 'wmgenmenu' being faster than 'genmenu':
[mafra@Pilar:~]$ time ./genmenu.sh < answers.txt &> /dev/null
real 0m3.626s
user 0m0.968s
sys 0m1.830s
[mafra@Pilar:~]$ time wmgenmenu &> /dev/null
real 0m0.020s
user 0m0.006s
sys 0m0.013s
Once upon a time (< 2005) the CachedPixmaps directory was located
at ~/GNUstep/.AppInfo/ and that was later moved to
~/GNUstep/Library/WindowMaker. So Dan Pascu introduced this function
in 24519b6292 to make the convertion
automatically to users back then.
As it is highly unlikely that there is an old-timer wmaker user still
running a pre-2005 wmaker which suddenly decides to switch to wmaker-crm
and runs into trouble with his CachedPixmaps folder, let's simply remove it
to make defaults.o 1.8% smaller (596 bytes).
No new translations were added. The .po file was recreated with
make WPrefs.pot
msgmerge de.po WPrefs.pot > de.po.new
(remove old strings from it)
mv de.po.new de.po
It was fun trying to translate them, but even after several
minutes of deep thoughts about the different cases etc I managed
to translate them wrongly.
So I thank Martin Dietze for kindly fixing them!
I wanted to learn some German and got curious to read the Window Maker
translations. After noticing that some strings with translations
were already removed from the main source I decided to recreate the
German .po file to get rid of those messages.
Even the option to enable "virtual desktop" in configure.ac was
commented out...and I would never intend to use it anyway.
So let's just remove the ~800 lines of #ifdef'ed code to have a
cleaner code base to read when bored.
The raising and lowering of the clip is already taken care of
by the "ClipRaiseLowerKey" shortcut.
wmaker gets a bit smaller for free:
text data bss dec hex filename
449483 17384 8208 475075 73fc3 src/.libs/wmaker.old
449307 17256 8192 474755 73e83 src/.libs/wmaker.new
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
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
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
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.
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.
Carlos R. Mafra