This patch only calls XGrabButton for CTRL+Button4 and CTRL+Button5.
This leaves CTRL+Button1-3 to the application.
This then removes the functionality of moving a window between
workspaces with CTRL+Button1 and CTRL+Button3
This patch constrains MOD+Wheel to vertical resize, and adds
CTRL+Wheel horizontal resize. Two resize in both directions, you
have to use CTRL+MOD+Wheel.
To enable this functionality I have to grab all CTRL+Mousebutton
events in wmaker, which stops them from reaching the application.
This definitely hurts application functionality in some apps, for
example the "VT Fonts" (CTRL+Button3) menu in xterm is no longer
accessible. To stop this from happening use the "Do not bind mouse
clicks" window attribute for the apps in which you want to disable
this.
Because wmaker now controls all CTRL+Mousebutton events, I also
added CTRL+Button1 and CTRL+Button3 shortcuts that will move a
window back and forth through your workspaces without changing its
position or size.
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 autocomplete feature in the "Run" dialog now adds a trailing "/"
when autocompleting directory names. This does three things:
1) shows you that you are completing a directory and not a filename,
2) saves one character of typing, and
3) makes it behave more consistent with shell (bash) autocompletion
I've found a buffer overflow problem in RSmoothScaleImage. There are
some scaling calculations involving floats which are finally converted
to integers. Since such conversion does not round the number, just
truncates the decimal part, sometimes the number is smaller than it
should be. As a result, smaller buffer is allocated for picture
scaling and thus buffer overflow occurs.
Strange thing is that this bug has not appeared earlier so it probably
has something to do with newer gcc or glibc (I switch from
"prehistoric" Fedora Core 5 to Fedora 12).
<What about the symptoms?>
There were several ones, probably depending on application version and
compilation flags. First, it just stopped responding. Looking at the
process with strace I saw it locked in some FUTEX wait (unfortunately
I don't have the logs). Second, it just crashed. And last I got
complaint from glibc about double free or corrupted heap before
malloc. I've found the bug through wmweather+ dockapp, versions 2.9
and 2.11 (http://sourceforge.net/projects/wmweatherplus/), I've never
encountered it in WindowMaker itself.
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
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.
