'xft-config' is deprecated (http://lists.freedesktop.org/archives/xorg-devel/2010-March/006750.html)
and does not exist anymore on 'bleeding edge' versions (gentoo). 'pkg-config'
is the new way of doing things. 'pkg-config --libs xft' does only report
the libs needed and the linker finds out other dependencies on its own. currently,
'pkg-config' (version 0.25) reports only '-lXft'.
if the user wants for example LDFLAGS="-fuse-ld=gold --no-add-needed" then
all the needed libs must be produced, otherwise linkage fails. at the moment
it seems that fluxbox calls 'XftMatrixRotate()' and 'XftPatternAddMatrix()'
which both seems to trigger the need for 'fontconfig':
undefined reference to 'FcMatrixRotate'
undefined reference to 'FcPatternAddMatrix'
is 'pkg-config --libs xft' reporting to few libs? in comparison to
'xft-config --libs' for sure. bug? feature? i am not sure. there are
several ways to address this issue:
* append the needed libs manually via LIBS or LDFLAGS
env LIBS="-lfontconfig" ./configure
* change build-system of fluxbox to do something like
pkg-config --print-requires-private 'xft' 2> /dev/null || echo xft)`
(pkg-config version < 0.2x does not have --print-requires-private, which
then leads to not print out all libs needed, which would then require
a fallback to xft-config since an older system anyways, evidence is
old pkg-config)
* changing build-system of fluxbox to use something like:
pkg-config --static --libs xft
(which reports really all libs, even more than actually needed, check out
http://osdir.com/ml/debian-bugs-closed/2011-01/msg01112.html)
* fix 'pkg-config' (or the related xft.pc) to report '-lXft -lfontconfig'
(not our code, but preferable)
* use 'pkg-config --libs xft fontconfig' since we know that calling the
xft functions requires linking against 'fontconfig' as well:
pkg-config --libs xft fontconfig
which is what we use to get rid of the build-errors
when linking with binutils-gold and --no-add-needed it is not enough to
just use -lXft but it must be -lXft -fontconfig (and some more). since we
use 'pkg-config --libs' to find out about the needed flags and 'pkg-config'
only returns -lXft (except by using
pkg-config --libs `pkg-config --print-requires-private xft`
) we switched to 'xft-config --libs' which gives us the complete list of
all needed libs.
the issue was brought to attention by
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554386
but the proposed fix was just quick and dirty.
nxserver-3.x creates a XExposeEvent for the unmapped FbTk::Menu(), which is
not configured completely yet (hence unmapped). this causes a call to
FbTk::Menu::clearItem() which then uses a value of 0 for m_rows_per_column
to divide the current index which triggers a SIGFPE.
it is still unclear, why nxserver-3.x creates the XExposeEvent for the
unmapped (menu) window. doing nothing if the menu is unmapped 'fixes'
the problem for now.
many thanks to Lars Engels (bsd-geek.de) to assist me in debugging this
issue.
a newer xlib recently changed the result of 'DisplayString()' a little bit:
instead of returning ':0.0' or ':1.0' it yields ':0' or ':1'. our code to
transform this string into something that includes the currently used
Screen worked only on something like ':0.0'.
we now find the '.' after the ':' and strip that part away.
by using FbCommands::ExecureCmd() we run 'fluxbox-update_configs' in
the bacground while booting a new fluxbox instance already. 'system()'
waits until 'fluxbox-update_configs' is done and then gives the control
back to fluxbox.
g++-4.1 does not like parts of 12e1ef7826,
calling std::bind2nd(std::mem_fun(func), ref_arg) lead to a bunch of
error: forming reference to reference type 'XYZ'
in order to avoid switching either back to the old for-loops or boost::bind
or to enforce a newer compiler (eg, g++-4.4) to the users a new helper
functor was created: 'CallMemFunWithRefArg'
this commit also fixes a little copy and paste error introduced in
12e1ef782, 'AtomHandler::updateClientClose' was called instead of
'AtomHandler::updateWorkspace'.
before bringing up the first instance of Fluxbox we prepare the directory
and the files it needs. if the config version of exiting files is lower
than what we expect, we upgrade the config files. after that we bring
up Fluxbox.
the old way was problematic because setupConfigFiles() calls
'fluxbox-update_configs' which does its job in the background while
fluxbox continues to boot. 'fluxbox-update_configs' sends a USR2 signal
to the booting fluxbox (it might even be finished, no one knows) which
triggers 'load_rc()' which triggered 'setupConfigFiles()' again which
might trigger 'fluxbox-update_configs' again (on my machine
'fluxbox-update_configs' was called 3 times and left a pretty crippled
'keys' file when it was done).
bootstrapping before bringing up fluxbox resolves the issue. as a bonus:
no need to send USR2 to fluxbox to reload the config file because fluxbox
has not even tried to read it yet.
to quote from 'man putenv':
The string pointed to by string becomes part of the environment,
so altering the string changes the environment.
so, using putenv like
{
std::string foo("FOO=bar");
putenv(foo.c_str());
}
is wrong and leads to a potentially corrupted environment. valgrind
complaint correctly.
FbTk::App seems to be the appropriate place to hold '::seten()'
because it alters the environment of the application.
## FbTk/ImageControl.hh:
* moved 'getSqrt()' over to TextureRender.cc because it is used only there
* removed unused members m_root_window
* use std::vector<> for colors and for the gradient buffers.
## FbTk/ImageControl.cc:
* fixed memory leak in '~ImageControl', 'pixels' where not deleted[]
at all. switched to std::vector, non-issue anymore.
* moved identical code into functions 'allocateUnallocatedColors', 'initColortables'
## FbTk/TextureRenderer:
* removed 'from', 'to', 'interlaced' from class, only used in
'renderGradient()' and are actually part of the given
texture.
* removed 'xtable', 'ytable' from class, only used in
'renderGradient()'
* removed 'colors' from the class, is part of 'control'
* moved render actions (invert, bevel1, bevel2, *gradient), they need more
love but for now this is sufficient
a lot of the parsing-related and menu-building stuff is just plain
stupid boiler plate code. putting the data into a const array
separates the boiler plate data from the actual code.
* ClientPattern.cc: make compiler happy (complaints about XPROP not handled in switch)
* FbTk/FbPixmap.cc FbTk/StringUtil.cc: signed vs unsigned
* FbTk/FbString.cc: missing return
* WinClient.cc: create atoms only once; use helper function
* Window.cc: use a helper function
for each window (windows, menue etc) the initCorners() function of
FbTk/Shape.cc was called (which is ok). On each call the corner pixmaps
(of the Screen the window belongs to) were created and destroyed the
formerly created pixmaps. this is not needed.
