Use the new preferences FrameBorderColor and FrameSelectedBorderColor to
set the border colour of frame windows and selected frame windows
respectively.
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.
Accept windows' depth, visual and colormap instead of always using those
of the root window. Internal windows such as menus behave as before.
In conjunction with a compositing manager on a display supporting the
RENDER extension windows can now manage their own opacity.
I wrote the patch after reading the FAQ for urxvt, which says,
regarding transparency support:
"3. Use an ARGB visual:
urxvt -depth 32 -fg grey90 -bg rgba:0000/0000/4444/cccc
This requires XFT support, and the support of your X-server. If that
doesn't work for you, blame Xorg and Keith Packard. ARGB visuals
aren't there yet, no matter what they claim. Rxvt-Unicode contains the
necessary bugfixes and workarounds for Xft and Xlib to make it work,
but that doesn't mean that your WM has the required kludges in place."
In conjunction with a compositing manager (I tested compton) it does
work and urxvt draws a semi-transparent background with fully opaque
foreground text and scrollbars; much prettier than applying a blanket
transparency value over the whole window with the compositing manager.
Other application windows I tested were, as expected, drawn the same
as before.
I verified that urxvt is drawn in the same way when using xfwm4
(with builtin compositing). Since Window Maker doesn't (at time of
writing) have its own compositing manager I should clarify that one is
required to see any benefit from this patch.
Whether or not this feature is useful for any application other than
urxvt I don't know, though I assume that an application which chose an
ARGB visual in the same way would be able to draw itself prettily.
On a display without RENDER things work just as they do without the
patch. I have, however, only been able to test on a fairly standard
TrueColor display supporting multiple colour depths with 24bpp being
the default. Testing with more ... exotic ... display types would
probably be advisable.
(Window|Menu)Title(Min|Max)Height defaults options allow to set
minimum and maximum titlebar height.
For example, to force all titlebars to 24 pixels execute
following commands:
$ wdwrite WindowMaker WindowTitleMinHeight 24
$ wdwrite WindowMaker WindowTitleMaxHeight 24
$ wdwrite WindowMaker MenuTitleMinHeight 24
$ wdwrite WindowMaker MenuTitleMaxHeight 24
Signed-off-by: Alexey I. Froloff <raorn@altlinux.org>
- fixed the workspace name display problem.
- replaced most of scr->xxx_pixel with scr->xxx_color
- removed some obsoleted GC's in the WScreen structure
WMDrawString() and WMDrawImageString() now take WMColor instead of GC as
arguments. WMDrawImageString() receives 2 colors (text & background).
This is to allow easy extension for Xft/Xrender and hide X low level details
- Added alpha channel to WMColor. 2 new functions also:
WMCreateRGBAColor() and WMSetColorAlpha()
- Miscelaneous code cleanups in wtext.c
- Removed obsoleted acconfig.h and implemented its functionality using
AC_DEFINE and AC_DEFINE_UNQUOTED as autoconf 2.5x recommends.
This will definitely enforce the need to use autoconf 2.5x
- Separated the font caches for normal fonts and fontsets in WINGs (they can
have the same names and collide in the cache giving unwanted results)
- Updated the years in the copyright notices
removed --enable-kanji and added MultiByteText option
rewrote font code to use WINGs
made autoraise only work for the active window
fixed compilation problem with OpenWindows and other non-X11R6 systems..
