A default cursor would make sense if we were talking about an API,
where we would propose a 'I-don't-know' choice to devs, but here
we're talking about WindowMaker's internal, where we're supposed
to provide a consistent interface to the user, so picking a
cursor is not an option (and 'Normal' is actually a decent
looking choice anyway).
Suggested-by: Rodolfo García Peñas <kix@kix.es>
As the cursor choice for each action is actually a user choice,
it is logical to put this into the structure, instead of a poorly
defined 'extern' in every file.
The function wCoreCreateTopLevel() is used in two files (icon.c and
framewin.c), but after create the window, some attributes are changed.
This patch moves the change inside the wCoreCreateTopLevel(), avoiding to
call XChangeWindowAttributes() after the window creation. Now the window
is created in only one step, with all the final attributes.
Some details:
- The function wCoreCreateTopLevel() has now one argument more, the
border pixel color. This attribute was used always as the screen
frame_border_pixel, but in icon.c the attribute is changed to
white_pixel. Now the function wCoreCreateTopLevel() receives the
value frame_border_pixel in framewin.c and scr->white_pixel in
icon.c, as argument.
- The vmask and attribs variables and the call to XChangeWindowAttributes()
are removed in framewin.c and icon.c. The values CWSaveUnder for vmask and
attribs.save_under = True are used if wPreferences.use_saveunders is True.
- CWBorderPixel is not needed in icon.c, because was previously set in wcore.c!
This reverts commit 824255b1ae.
According to Iain Patterson:
This patch breaks the frame extents stuff I submitted recently. With
the patch and compton set to draw semi-opaque frame extents what
actually happens is no window decorations are drawn and a bunch of
BadDrawable errors are spewed to the console.
After reverting the patch everything works again.
The code was setting some values in the window's attribute structure
which were not being used (missing the corresponding vmask flag) and
was setting some vmask bits without setting the corresponding
value in the structure.
This patch set the vmask in one line.
- vmask = CWBorderPixel | CWCursor | CWEventMask | CWOverrideRedirect;
- vmask |= CWColormap;
Is similar to:
+ vmask = CWBorderPixel | CWCursor | CWEventMask | CWOverrideRedirect | CWColormap;
And vmask is not used between the two original lines, therefore we can do the
initialization in only one line.
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.
memset is the last function call in wmalloc, just before it returns the
newly allocated memory. Therefore it is not needed to call it again
after wmalloc call. Although I would prefer to switch wmalloc to a
calloc-based wcalloc function, the compatibility of WINGs for old apps
should be kept.
for arq in `git ls-files *.c`; do
echo $arq;
indent -linux -l115 $arq;
done
The different line break at 115 columns is because
I use a widescreen monitor :-)
- 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
