The icons coming from _NET_WM_ICON are argb32. fluxbox uses such icons
in entities such as 'clientmenu', 'iconbar', 'titlebar'. These entities
are not related to the depth of the winclient but to fluxbox's default
depth. Using 'winclient.depth()' is a mistake, since fluxbox is unable
to copy pixmaps from 32bit to 24/16/15bit.
It is not necessary either, because fluxbox should extract the argb32 icon
data directly into the pixmap with the correct depth in the first place.
This fixes (reopened) bug #1852693.
Note: The whole icon code in fluxbox is quite messy, lots of copying and
scaling. It might be simpler and fater to just extract the icon when needed
, in just the size that is needed.
Introduces a new member function, FbWindow::cardinalProperty()
This change also changes other code that previously used
FbWindow::property() to do the same thing as the new function; this
reduces code duplication.
There are still some bits of code (Ewmh.cc, extractNetWmIcon()) that use
FbWindow::property() to retrieve XA_CARDINAL values, but as the new
method is designed for getting a _single_ property, and that code uses
FbWindow::property() to retrieve the number of values present, and then
grab all of them; it's a different use case. I opted to not try to make
cardinalProperty() into some monolithic all-purpose cardinal method;
FbWindow::property() works just fine for that.
This change also adds an optional (default=NULL) boolean to
FbWindow::textProperty and friends that allows the caller to determine
whether or not a value was actually retrieved. This was necessary for
integrating FbWindow::cardinalProperty with the codebase, and it seemed
to fit with FbWindow::textProperty as well. Prior to this change, if
you got a return value of "", you wouldn't know if you successfully
retrieved the value which happened to be blank, or if you failed to
retrieve the value. Now, you can pass the address of a boolean if you
so choose in order to differentiate these situations; the same applies
to the new FbWindow::cardinalProperty().
biggest change: renaming of 'class Layer' to 'class ResourceLayer' in
Layer.hh to handle complaints about 'ambiguous Layer: Layer or FbTk::Layer'.
'ResourceLayer' sounds crappy, but that was the best I could come
up with right now.
a 'BidiString' holds both the logical content and the visual reordered
version of the content of a string. this helps to reduce the number of
calls to reorder the string before drawing it (as introduced in the patch
from Ken Bloom) and to be more consistent in menus and textboxes (drawing
cursors and underlining text).
using a smaller type ('long' on 64bit is 8 byte, 'int' is 4) results in
strange properties, eg:
_NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_HORZ, undefined atom # 0x2726130
(when xpropping a maximized xterm). this might cause misbehavior in apps.
is not aware of how to correctly feed icon data into the property on 64bit architecture
which caused the dimensions of the icon beeing corrupt and due to overflow arithmetics
fluxbox crashed.
