Use inotify to check for changes to the defaults database. Workaround for
event handler timer.
After upgrading my kernel recently I noticed that dnotify has been
depreciated, so I decided to try and implement the new inotify code in
Window Maker instead.
During testing, I also found that one of the timers which was removed
(the one causing the most wake-ups), calling delayedAction, was
responsible for handling signals. Basically with this timer removed,
signals were only handled after an X event occurs.
After looking at the delayedAction function, I couldn't see the purpose of it.
It certainly wouldn't cause any delay as it was called by the timer every
500ms, so there is no time correlation with when a signal was received.
Also, it appeared to count the signals and call DispatchEvent for each
one, but it appears DispatchEvent would just handle the most recent signal
and take action on that. The signals handled by delayedAction are the
various exit and reset signals, so only one need to be handled. I
therefore have commented out delayedAction (it wasn't called by any other
procedure) and added a call to DispatchEvent imediately after the signal
is registered, in handleExitSig.
I'm not sure what problems this may cause with dead children - these are
only cleaned up after an Xevent now that the timer is removed- but I
haven't observed any problems since a few months ago.
event handler timer.
After upgrading my kernel recently I noticed that dnotify has been
depreciated, so I decided to try and implement the new inotify code in
Window Maker instead.
During testing, I also found that one of the timers which was removed
(the one causing the most wake-ups), calling delayedAction, was
responsible for handling signals. Basically with this timer removed,
signals were only handled after an X event occurs.
After looking at the delayedAction function, I couldn't see the purpose of it.
It certainly wouldn't cause any delay as it was called by the timer every
500ms, so there is no time correlation with when a signal was received.
Also, it appeared to count the signals and call DispatchEvent for each
one, but it appears DispatchEvent would just handle the most recent signal
and take action on that. The signals handled by delayedAction are the
various exit and reset signals, so only one need to be handled. I
therefore have commented out delayedAction (it wasn't called by any other
procedure) and added a call to DispatchEvent imediately after the signal
is registered, in handleExitSig.
I'm not sure what problems this may cause with dead children - these are
only cleaned up after an Xevent now that the timer is removed- but I
haven't observed any problems since a few months ago.
Fix periodic focus bug
Pedro Gimeno explains:
"As you most likely already know, every X Window event comes with a
timestamp. You can see it using e.g. xev.
I don't know if this is Debian-specific and I'm no X Window expert, but
the fact is that in my machine this timestamp, according to my
/usr/include/X11/X.h, is a 32-bit unsigned integer and it holds the
event time in milliseconds according to my tests.
This timestamp appears to be in milliseconds from the start of the Unix
epoch, modulo 2^32. The problem is that 32 bits are too little for this
purpose: 2^32 milliseconds are exactly 49 days, 17 hours, 2 minutes and
47.296 seconds.
Now, the WindowMaker code rejects any focus event whose timestamp is
less than the last one seen, using code similar to this:
if (timestamp < LastTimeStamp) return;
LastTimeStamp = timestamp;
This is a disaster when timestamp wraps around because of the 32-bit
limit. Say LastTimeStamp equals 2^32-1 and a focus event comes two
milliseconds after. Its timestamp will equal 1 because of the
wraparound. Obviously, 1 < 2^32-1 so the event will be rejected even if
it comes from the future (relative to LastTimeStamp) and not from the
past. Focus events are no longer accepted because nothing can be greater
than 2^32-1 (unless you click on that exact millisecond, 49 days after).
If you look in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=102314
you'll see two people confirming the periodicity and predictability of
the bug. Arnaud Giersch was who noted that the period was 2^32
milliseconds (and not 2^31 as I thought it could be because of a signed
int involved) and who noted the coincidence with the Unix epoch.
My fix works by subtracting one timestamp from the other (an operation
which is done modulo 2^32) and rejecting the focus event only if the new
timestamp is within 1 minute (60000 milliseconds) in the past. Given the
periodicity of the timestamp, actually after 49.7 days there will be
another minute in the future during which focus events will not be
accepted; again after 99.4 days, etc., but thanks to the subtraction,
they will now be relative to the *last* focus change and not to the Unix
epoch.
The patch could be simplified to get rid of the compareTimes function.
It's written like that because it comes from the previous patch (which
you can see in the same bug report).
So the date comparison line could end up looking like this:
if (scr->flags.ignore_focus_events || LastFocusChange - timestamp <
60000)
so you can get rid of the compareTimes function. However please respect
the other change of 'int' to 'Time'.
As for why you aren't experiencing this problem, perhaps the event
timestamp does not come from the Unix epoch in your X Window system, but
rather starts counting when you start it or your computer, I don't know.
Or maybe your X Window server's timestamps are 64 bits wide instead of
32 bits, which I don't think because I doubt the X11 protocol specifies
a 64-bit record for the transmission of the timestamp. In either case,
the output of xev will probably help understanding the cause.
Or maybe even it's a click-to-focus only bug and you're not using that
mode. I haven't checked who calls wSetFocusTo.
Note that I can reproduce it just by manipulating the system clock,
which seems to be tied to the event timestamps."
For more information see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=102314
Reported-by: Joey Hess <joeyh@debian.org>
Signed-off-by: Pedro Gimeno <parigalo@formauri.es>
Pedro Gimeno explains:
"As you most likely already know, every X Window event comes with a
timestamp. You can see it using e.g. xev.
I don't know if this is Debian-specific and I'm no X Window expert, but
the fact is that in my machine this timestamp, according to my
/usr/include/X11/X.h, is a 32-bit unsigned integer and it holds the
event time in milliseconds according to my tests.
This timestamp appears to be in milliseconds from the start of the Unix
epoch, modulo 2^32. The problem is that 32 bits are too little for this
purpose: 2^32 milliseconds are exactly 49 days, 17 hours, 2 minutes and
47.296 seconds.
Now, the WindowMaker code rejects any focus event whose timestamp is
less than the last one seen, using code similar to this:
if (timestamp < LastTimeStamp) return;
LastTimeStamp = timestamp;
This is a disaster when timestamp wraps around because of the 32-bit
limit. Say LastTimeStamp equals 2^32-1 and a focus event comes two
milliseconds after. Its timestamp will equal 1 because of the
wraparound. Obviously, 1 < 2^32-1 so the event will be rejected even if
it comes from the future (relative to LastTimeStamp) and not from the
past. Focus events are no longer accepted because nothing can be greater
than 2^32-1 (unless you click on that exact millisecond, 49 days after).
If you look in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=102314
you'll see two people confirming the periodicity and predictability of
the bug. Arnaud Giersch was who noted that the period was 2^32
milliseconds (and not 2^31 as I thought it could be because of a signed
int involved) and who noted the coincidence with the Unix epoch.
My fix works by subtracting one timestamp from the other (an operation
which is done modulo 2^32) and rejecting the focus event only if the new
timestamp is within 1 minute (60000 milliseconds) in the past. Given the
periodicity of the timestamp, actually after 49.7 days there will be
another minute in the future during which focus events will not be
accepted; again after 99.4 days, etc., but thanks to the subtraction,
they will now be relative to the *last* focus change and not to the Unix
epoch.
The patch could be simplified to get rid of the compareTimes function.
It's written like that because it comes from the previous patch (which
you can see in the same bug report).
So the date comparison line could end up looking like this:
if (scr->flags.ignore_focus_events || LastFocusChange - timestamp <
60000)
so you can get rid of the compareTimes function. However please respect
the other change of 'int' to 'Time'.
As for why you aren't experiencing this problem, perhaps the event
timestamp does not come from the Unix epoch in your X Window system, but
rather starts counting when you start it or your computer, I don't know.
Or maybe your X Window server's timestamps are 64 bits wide instead of
32 bits, which I don't think because I doubt the X11 protocol specifies
a 64-bit record for the transmission of the timestamp. In either case,
the output of xev will probably help understanding the cause.
Or maybe even it's a click-to-focus only bug and you're not using that
mode. I haven't checked who calls wSetFocusTo.
Note that I can reproduce it just by manipulating the system clock,
which seems to be tied to the event timestamps."
For more information see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=102314
Reported-by: Joey Hess <joeyh@debian.org>
Signed-off-by: Pedro Gimeno <parigalo@formauri.es>
Workaround for Composite problems when default depth is not 24.
This is really a workaround patch, the proper fix would be to have
WindowMaker know about Composite, and take advantage of it's features.
This is really a workaround patch, the proper fix would be to have
WindowMaker know about Composite, and take advantage of it's features.
WINGs/wfont.c: Avoid returning font=NULL in WMCreateFont()
WPrefs tries to use the fonts listed in the WMCreateFont() call (from WPrefs.c),
font = WMCreateFont(scr, "Lucida Sans,URW Gothic L,Times New Roman,serif"
":bold:pixelsize=26:antialias=true");
and 'font' is later used without accounting the possibility of it being NULL in
WMSetLabelFont(WPrefs.nameL, font);
WMReleaseFont(font);
In particular, WMReleaseFont(font) will kill WPrefs ungracefully with the
following message if font=NULL
WPrefs: wfont.c:193: WMReleaseFont: Assertion `font!=((void *)0)' failed.
Aborted
That happens because the return value of WMCreateFont() can be NULL, so this
patch makes WMCreateFont() never return NULL. If the font creation fails for
some reason (see below), we try to use the emergency DEFAULT_FONT and print
debugging information telling what's going on. If the use of DEFAULT_FONT
also fails, then we terminate WPrefs with exit(1) and let the user know
why exactly if failed.
This bug happened because the font "Lucida Sans" (the first possibility
in the initial call to WMCreateFont()) "exists" in my system as a stale
symbolic link to a location which no longer exists after an upgrade from
java from 1.5.0.14 to 1.5.0.15
/etc/alternatives/LucidaSansDemiBold.ttf ->
/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/fonts/LucidaSansDemiBold.ttf
So the call to XftFontOpenName(display, scrPtr->screen, fname) with
"Lucida Sans" being the first possibility for Xft to try out ended up in 'font'
being NULL because, as far as the Xft library was concerned, "Lucida Sans"
produced a positive match (due to it existing as a symbolic link) but in the end
a NULL result was produced due to the missing symbolic link destination. This later
exposed the bug of WMCreateFont() returning font=NULL and WPrefs.c not checking
whether font=NULL before using it. Bang!
If "Lucida Sans" was the _second_ entry to try and the first one had suceeded,
this bug would not have surfaced.
This solves https://qa.mandriva.com/show_bug.cgi?id=39677
Signed-off-by: Carlos R. Mafra <crmafra@ift.unesp.br>
WPrefs tries to use the fonts listed in the WMCreateFont() call (from WPrefs.c),
font = WMCreateFont(scr, "Lucida Sans,URW Gothic L,Times New Roman,serif"
":bold:pixelsize=26:antialias=true");
and 'font' is later used without accounting the possibility of it being NULL in
WMSetLabelFont(WPrefs.nameL, font);
WMReleaseFont(font);
In particular, WMReleaseFont(font) will kill WPrefs ungracefully with the
following message if font=NULL
WPrefs: wfont.c:193: WMReleaseFont: Assertion `font!=((void *)0)' failed.
Aborted
That happens because the return value of WMCreateFont() can be NULL, so this
patch makes WMCreateFont() never return NULL. If the font creation fails for
some reason (see below), we try to use the emergency DEFAULT_FONT and print
debugging information telling what's going on. If the use of DEFAULT_FONT
also fails, then we terminate WPrefs with exit(1) and let the user know
why exactly if failed.
This bug happened because the font "Lucida Sans" (the first possibility
in the initial call to WMCreateFont()) "exists" in my system as a stale
symbolic link to a location which no longer exists after an upgrade from
java from 1.5.0.14 to 1.5.0.15
/etc/alternatives/LucidaSansDemiBold.ttf ->
/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/fonts/LucidaSansDemiBold.ttf
So the call to XftFontOpenName(display, scrPtr->screen, fname) with
"Lucida Sans" being the first possibility for Xft to try out ended up in 'font'
being NULL because, as far as the Xft library was concerned, "Lucida Sans"
produced a positive match (due to it existing as a symbolic link) but in the end
a NULL result was produced due to the missing symbolic link destination. This later
exposed the bug of WMCreateFont() returning font=NULL and WPrefs.c not checking
whether font=NULL before using it. Bang!
If "Lucida Sans" was the _second_ entry to try and the first one had suceeded,
this bug would not have surfaced.
This solves https://qa.mandriva.com/show_bug.cgi?id=39677
Signed-off-by: Carlos R. Mafra <crmafra@ift.unesp.br>
wmaker: Reduce wakeups to zero
This patch removes wmaker from PowerTop's shame list, where
it appeared with ~3-4 wakeups/second.
It adds the linux kernel's dnotify mechanism (adapted from
the example in Documentation/dnotify.txt in the kernel source),
to detect when a configuration file in ~/GNUStep/Defaults has
changed to load it again on-the-fly. For me it usually means that
modifications to ~/GNUStep/Defaults/WMRootMenu via the 'genmenu'
script are automatically detected and loaded.
The use of dnotify makes the ancient behaviour of polling unecessary
and cuts down the wakeups count.
Other 'apparently' useless timers are also deleted and it's been almost
one year now that I use this patched exclusively without problems, so
I am pretty sure that it doesn't hurt to remove them.
The end result of all this is that wmaker generates 0 (zero) wakeups
when idle in a Linux system.
Signed-off-by: Carlos R. Mafra <crmafra@ift.unesp.br>
This patch removes wmaker from PowerTop's shame list, where
it appeared with ~3-4 wakeups/second.
It adds the linux kernel's dnotify mechanism (adapted from
the example in Documentation/dnotify.txt in the kernel source),
to detect when a configuration file in ~/GNUStep/Defaults has
changed to load it again on-the-fly. For me it usually means that
modifications to ~/GNUStep/Defaults/WMRootMenu via the 'genmenu'
script are automatically detected and loaded.
The use of dnotify makes the ancient behaviour of polling unecessary
and cuts down the wakeups count.
Other 'apparently' useless timers are also deleted and it's been almost
one year now that I use this patched exclusively without problems, so
I am pretty sure that it doesn't hurt to remove them.
The end result of all this is that wmaker generates 0 (zero) wakeups
when idle in a Linux system.
Signed-off-by: Carlos R. Mafra <crmafra@ift.unesp.br>
Add .gitignore to git repository
Fixed segfault when unhiding an application in certain conditions (seen
with KDE applications with transient windows)
with KDE applications with transient windows)
updated todo with ideas for post 1.0
Enhanced the cursor positioning/selecting text using the mouse in a textfield.
This also fixed an endless loop that could be entered by the previous code
in certain situations, after the patch to fix navigation/selection in a
textfiled with UTF8 chars was applied.
This also fixed an endless loop that could be entered by the previous code
in certain situations, after the patch to fix navigation/selection in a
textfiled with UTF8 chars was applied.
Removed WINGs' dependency on rgb.txt (from X11).
This fixes issues with locating the file which is being stored on different
locations depending on the X server release/version
This fixes issues with locating the file which is being stored on different
locations depending on the X server release/version
Applied patches from Stanislav Maslovski <stanislav.maslovski@gmail.com> to
fix the 2 problems mentioend below:
- Fixed buggy handling of UTF8 characters in textfields in WINGs.
- Fixed segfault in WPrefs when some font description is missing from the
configuration file.
fix the 2 problems mentioend below:
- Fixed buggy handling of UTF8 characters in textfields in WINGs.
- Fixed segfault in WPrefs when some font description is missing from the
configuration file.
more fixes for missing linking flags in some cases
replaced windowmaker.org with windowmaker.info everywhere
- Improved Info panel display.
- Fixed missing library paths when linking some binaries on certain
platforms with a recent pkg-config
- Fixed missing library paths when linking some binaries on certain
platforms with a recent pkg-config
yet another cvs commit notification test
another cvs commit notification test
cvs commit notification test
cvs commit notification test
test cvs commit notifications
test cvs commit notifications
- updated the XDND code in WINGs to work with GDK based applications.
WINGs based applications should now work with both KDE and GNOME
applications (Sylvain Reynal <sreynal@nerim.net>)
- better check for the XDND protocol version when interoperating with other
applications. As it seems xdnd version 3 (which WINGs supports) and newer
are not backward compatible with xdnd version 1 and 2. This is why WINGs
applications cannot interoperate with GNUstep applications (which uses
xdnd version 2). Xdnd version 4 and 5 are backwards compatible with
version 3 though. (Sylvain Reynal <sreynal@nerim.net>)
WINGs based applications should now work with both KDE and GNOME
applications (Sylvain Reynal <sreynal@nerim.net>)
- better check for the XDND protocol version when interoperating with other
applications. As it seems xdnd version 3 (which WINGs supports) and newer
are not backward compatible with xdnd version 1 and 2. This is why WINGs
applications cannot interoperate with GNUstep applications (which uses
xdnd version 2). Xdnd version 4 and 5 are backwards compatible with
version 3 though. (Sylvain Reynal <sreynal@nerim.net>)
updated estonian translation
- release colors to avoid issues with the reference count overflowing a
small integer and causing unexpected color releases that can crash
Window Maker (Martin Frydl <martin.frydl@systinet.com>)
- fixed a small memory leak in WINGs/wview.c caused by not releasing the
background color of a view (Martin Frydl <martin.frydl@systinet.com>)
small integer and causing unexpected color releases that can crash
Window Maker (Martin Frydl <martin.frydl@systinet.com>)
- fixed a small memory leak in WINGs/wview.c caused by not releasing the
background color of a view (Martin Frydl <martin.frydl@systinet.com>)
- fixed issue with invisible modal windows from Qt and Gtk applications
on 64bit platforms (Max Loparyev <max@city.veganet.ru>)
- fixed issue with icon colors on big endian platforms
(Max Loparyev <max@city.veganet.ru>)
patch based on a previous patch by Vladimir Nadvornik <nadvornik@suse.cz>
on 64bit platforms (Max Loparyev <max@city.veganet.ru>)
- fixed issue with icon colors on big endian platforms
(Max Loparyev <max@city.veganet.ru>)
patch based on a previous patch by Vladimir Nadvornik <nadvornik@suse.cz>
test
test
Applied some patches from Balaton Zoltan <balaton@eik.bme.hu>
- small fix for compilation in a different directory than the source
- fixed some warnings on 64bit platforms
- small fix for compilation in a different directory than the source
- fixed some warnings on 64bit platforms
eliminated gcc-4 compilation warnings
- fixed gcc-4 compilation issues (Vladimir Nadvornik <nadvornik@suse.cz>)
- fixed amd64 compilation issues (Vladimir Nadvornik <nadvornik@suse.cz>)
- fixed amd64 compilation issues (Vladimir Nadvornik <nadvornik@suse.cz>)
Fixed WPrefs.app to find its icons when not installed under GNUstep paths
updated german translations
try to work around some user's IQ level
updated news file (part 2)
updated news file
18 years ago- new algorithm for placing miniwindows after unhiding the application theywmaker-0.92.0
- new algorithm for placing miniwindows after unhiding the application they
belong to, that works without auto-arranging the icons, while still avoiding
multiple icons in the same spot by moving the miniwindows to a new slot if
their old slot was occupied in the meantime.
- double clicking an appicon will also raise the miniwindows that belong to
that application to the front (along with the normal windows).
belong to, that works without auto-arranging the icons, while still avoiding
multiple icons in the same spot by moving the miniwindows to a new slot if
their old slot was occupied in the meantime.
- double clicking an appicon will also raise the miniwindows that belong to
that application to the front (along with the normal windows).
- try fixed font for the technical drawing font if helvetica-12 is not
available to avoid crashing (Timo Juhani Lindfors <timo.lindfors@iki.fi>)
- german WINgs po file fix
available to avoid crashing (Timo Juhani Lindfors <timo.lindfors@iki.fi>)
- german WINgs po file fix
Fixed issue with GNUstep applications losing focus when all their windows
are closed and there remains only their menu (Matt Rice <ratmice@yahoo.com>)
are closed and there remains only their menu (Matt Rice <ratmice@yahoo.com>)
- fixed bug with windows shrinking to very small sizes when Unmaximize was
used on them, after they were closed in a maximized state.
- fixed bug with restoring maximized state from NetWM atoms.
used on them, after they were closed in a maximized state.
- fixed bug with restoring maximized state from NetWM atoms.
removed obsolete file
Improved hide/unhide animation for applications with multiple windows
(only animate the active window hiding/unhiding, which makes Window Maker
faster and more responsive for such applications).
(only animate the active window hiding/unhiding, which makes Window Maker
faster and more responsive for such applications).
- Fixed switch panel default value in defaults.c
- Fixed WPrefs path in the installed WMState (changed after recent WPrefs
installation path changes)
- Fixed wmaker.inst (apparently some very noisy individual was unable to get
right his 10 line patch to rename a path)
- Fixed WPrefs path in the installed WMState (changed after recent WPrefs
installation path changes)
- Fixed wmaker.inst (apparently some very noisy individual was unable to get
right his 10 line patch to rename a path)
Fixed bug that caused wmaker to crash when kplayer was switched back from
fullscreen mode to windowed mode.
fullscreen mode to windowed mode.
fixed issue with window being moved by 1 pixel up and left when the window
move was initiated by the client
move was initiated by the client
Added code to automatically convert Icon paths in WMWindowAttributes from
the old .AppInfo/... to the new Library/WindowMaker/... on the fly when
Window Maker starts.
This should allow a transparent transition without any need for users to do
anything.
the old .AppInfo/... to the new Library/WindowMaker/... on the fly when
Window Maker starts.
This should allow a transparent transition without any need for users to do
anything.
Changes (especially the ones that may affect backward compatibility like
this path change) should go at the top of the NEWS file. None digs 1200
lines in the NEWS to read about some path change.
this path change) should go at the top of the NEWS file. None digs 1200
lines in the NEWS to read about some path change.
Fixed paths, because mr Alex "Big Mouth" Perez was unable to get them right
in the first place in his trivial 10 line patch which only attempted to
replace one path with another.
He must be a big time user of his own patch, to not have noticed where the
paths pointed after his change.
in the first place in his trivial 10 line patch which only attempted to
replace one path with another.
He must be a big time user of his own patch, to not have noticed where the
paths pointed after his change.
fixed cvs to compile again
eq
updated changelog
applied patch to rename .AppInfo directory
applied patch to use more gnustepish paths for some internal data files
- Fixed a few typos
- Added new italian translation (Marco Colombo <m.colombo@ed.ac.uk>)
- Added new italian translation (Marco Colombo <m.colombo@ed.ac.uk>)
- Fixed compilation include path issue in wrlib/tests
- Removed unnecessary included headers (we don't use Xt)
- Removed unnecessary included headers (we don't use Xt)
Fixed crash when removing submenus in WPrefs' menu editor.
The submenu widget was free'd twice (once by destroyEditMenuItem() and a
second time by destroyEditMenu())
The submenu widget was free'd twice (once by destroyEditMenuItem() and a
second time by destroyEditMenu())
updated chinese translations
- better checks if the icon sizes are valid and there is enough data to
build the image from _NET_WM_ICON
- properly read the icon's pixels from _NET_WM_ICON, so they won't depend
on machine endianess.
build the image from _NET_WM_ICON
- properly read the icon's pixels from _NET_WM_ICON, so they won't depend
on machine endianess.
fix for broken 'make install' introduced by previous commit
fix to allow parallel builds on SMP systems using make -j
fixed issue with path assignment
- fixed possible crash bug because a variable allocated on stack was
returned by a function
- removed obsolete macro
returned by a function
- removed obsolete macro
fixed bug with infinite loop in some circumstances in fitText() in WINGs
Removed --with-appsdir option and replaced it with --with-gnustepdir. Also,
default installation path (for non GNUstep users) is now $(prefix)/bin
default installation path (for non GNUstep users) is now $(prefix)/bin
Detect if gcc is able to compile x86 asm and if it supports passing more
than 10 parameters in inline asm, else disable asm code.
This should enable it to work on any x86 platform (not just linux as before)
given that a recent enough gcc is available (no more need to guess by looking
at $host)
This should also fix the issues of compiling wrlib with gcc-2.95
than 10 parameters in inline asm, else disable asm code.
This should enable it to work on any x86 platform (not just linux as before)
given that a recent enough gcc is available (no more need to guess by looking
at $host)
This should also fix the issues of compiling wrlib with gcc-2.95
better text alignment
fixed some compilation issues with gcc-2.9x
fixed another spot where compiling on solaris with openwin generated errors
attempt to fix compilation on solaris with openwin
Changed the order some header files are loaded, as it seems to cause havoc
on some platforms
on some platforms
added preliminary X Input Methods support
oops
added option to disable switchpanel
fixed some bugs
fixed some bugs
updated japanese translations (Takeo Hashimoto <HashimotoTakeo@mac.com>)
changed alt-tab behaviour
small fix for older fontconfig
fixed crash bug with alt-tab + run-dialog (or internal windows in general)
increased libwraster version
0.91.0, disable unfinished vdesk
0.90.1
fixed several po files
fixed some bugs
fixed some bugs
updated Makefiles files for po dirs
fixed animation speed issues with 2.6.x linux kernels
bad name choice...
icon with smoother corners
forgot this
- Fixed issues with crashing dialog not working
- Keep menu and title text at 12px since there is not constrained by width
- Removed some obsoleted options from wconfig.h
- Added a lighter image for the switch panel
- Keep menu and title text at 12px since there is not constrained by width
- Removed some obsoleted options from wconfig.h
- Added a lighter image for the switch panel
bug fix
added themable, pixmap background switch panel
- replaced VirtualEdgeThickness option with EnableVirtualDesktop (boolean)
- some code cleanups in the virtual desktop.
- some code cleanups in the virtual desktop.
limit VirtualEdgeThickness values to the 0..10 range
- Fix that enables that the virtual desktop code be disabled on the fly
when VirtualEdgeThickness is set to 0
- Fixed virtual edge to resize the edge on the fly if thickness changes
when VirtualEdgeThickness is set to 0
- Fixed virtual edge to resize the edge on the fly if thickness changes
added RCopyArea
missed this small update
- Fixed wrong call to XChangeProperty() when setting _NET_WM_ICON
- Changed the WPrefs icons with Largo's version
- Replaced Apps with Application in the docs
- Changed the WPrefs icons with Largo's version
- Replaced Apps with Application in the docs
workaround for older fontconfig versions that do not define some constants
Updated the single click patch to work with latest version.
(thanks to "Daniel Richard G." <skunk@iskunk.org>)
(thanks to "Daniel Richard G." <skunk@iskunk.org>)
free
added some netwm support in WINGs
- Replaced Apps with Applications in WPrefs installation path
- Added missing switchpanel.h to compile file list
- Added missing switchpanel.h to compile file list