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>)
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>)
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>
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).
- 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)
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.
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.
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
