Age | Commit message (Collapse) | Author | Files | Lines |
|
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.
|
|
not having DISPLAY set (eg: on a headless system) caused fluxbox to crash.
|
|
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.
|
|
|
|
while integrating the old 'getSqrt()' function into the 'bsqrt()'
function i misplaced some code. this lead to 'r' being 0 on the
first run. doh.
|
|
|
|
|
|
|
|
|
|
g++-4.1 does not like parts of 12e1ef78265a621dc51f7b9af245d81431835dcc,
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.
|
|
|
|
got lost in d3eabeb805fdbd162c0743ed86a67e014e37c097 somehow
|
|
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.
|
|
'valgrind' reported a lot of code branches based upon uninitialized
variables. some are not identified yet.
|
|
the next step is to not use 'unsigned int' and then only store 'chars'
in it, maybe even using RGBA data instead of separated arrays for
r, g and b.
|
|
|
|
|
|
|
|
## 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.
|
|
|
|
'tools' is transformed to lower case some lines above,
'm_tools_ is a copy of the lower cased 'tools'.
|
|
|
|
|
|
|
|
|
|
* 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.
|
|
the global 's_corners' vector was still used on an application shutdown
(including ctrl-c SIGINT). depending on when 's_corners' was created on
the stack this could lead to an exception ('pure virtual called') while
trying to free the 'FbPixmaps' without having a valid
'FbTk::Application::instance()' left.
|
|
|
|
* use FbTk::StringUtil::number2String() to avoid 'sprintf'
* use FbTk::Util::clamp()
* use FbTk::STLUtil::destroyAndClear()
* whitespaces
|
|
we do not need a std::map just to store an attribute on an AtomHandler,
it makes housekeeping just more annoying.
|
|
|
|
our users should migrate seamlessly to our new windows-cycling behaviour
without losing their current way of doing things. so, 'fluxbox-update_configs'
tries its best to add '(workspace=[current])' wherever it looks like a valid
place for it. such changed lines are marked by '!! FBCV13' at the end and can
be easily spotted in case the updater got it wrong.
addtional changes:
* added '-check' to 'fluxbox-update_configs' to check the version number in
'~/.fluxbox/init' vs. the version number of 'fluxbox-update_configs'
* moved the update-code for each version into its own function, easier
housekeeping
|
|
commit 882a50fe1d4930b156965c54d9b66ecb27b4c9b2 removed the hardcoded limit to
cycle to windows on other workspaces, though it was and IS a good default
behaviour. if users do not want this (they want to cycle to windows on other
workspaces), they should explicitly avoid '(workspace=[current])' in their
keysfile.
|
|
these two allow 'tagging' of arbitrary windows with 'tags' (or 'labels'). such 'tagged' windows can then be used in ':NextWindow (@PROP=foo)' commands to quickly cycle through a subset of available windows.
since the 'tags' are applied as real xproperties to a window they survive a restart of fluxbox or even another windowmanager. the user can also set the tags by using xprop(1).
the next step regarding the UI should be to visualize the tags of a window.
|
|
|
|
* moved code from public API to internals
* avoid code duplication ( while(!m_terms.empty()) ...)
* cosmetic '(*it)->' vs 'term.'
|
|
reasons:
* fixes #1732115, allows to have chatwindows on another workspaces and reach them via :NextWindow (urgent=yes)
* old behavior can be achieve by using the (workspace=[current]) pattern
|
|
|
|
|
|
|
|
on startup a lot of 'Fluxbox: X Error: BadDrawable (invalid Pixmap ...)' occured.
this was caused by using an empty 'Window' to create the shape.
|
|
|
|
|
|
|
|
|