It's hard to hit right moment to update the clock correctly: Either we are a
bit too early and the 'old time' is the same as the 'new time' and the clock
looks 'a bit off' or we are too late and the clock is 'a bit off'. This is
especially the case for format strings which do not show the second and thus
are updated only at the full minute (see bug #1082): if fluxbox does not
update the clock 'now' it would do it one minute later and thus the clock
might show the wrong time for roughly 1 minute.
Instead of coming up with something immensely clever we just trigger the
ClockTool every second. If no update of the shown time is needed fluxbox won't
do anything.
Some minor code reordering as byproduct.
By removing FbTk/LogicCommands.o from LDADD in src/Makefile.am (commit
06655f6) I prevented the linker to pick up FbTk/LogicCommands.o and thus
rendered all logic-commands useless.
Using a small helper object to pull in the dependency fixes this problem
without relying on manually tweaking the build system.
First draft of feature request of #3602124: Having 2 buttons in the titlebar
which allow quick positioning of a Window into the left or right half of the
current monitor.
For odd 'widths' and 'heigths' the texture would not be filled completely:
Given a 'width' of 5 we would render only 4 instances of x (-2, 1, 0, 1)
instead of the needed 5. This results in a texture which looks a bit cut off
to the bottom right side.
std::set<Key, Comp> stores Key only if Comp(Key) yields a unique result (My
mistake: I was under the impression Comp is only used for the ordering). This
prevents FbTk::Timers with equal end-times from actually being started.
Escpecially in situation with multiple ClockTools this lead to stopped timers
(see bug #3600694).
Kudos to Adam Majer for enlightening discussions.
ClientPatterns might be tricky to get right. Instead of fiddling around in
either the keys-file or the apps-file and restarting fluxbox to see if the
changes had any effect / matched the right windows, 'ClientPatternTest' and
the fluxbox-remote should make this easier:
$> fluxbox-remote "clientpatterntest (title=.*vim*)"
This causes fluxbox to store the list of matched windows in the
_FLUXBOX_ACTION_RESULT property onto the rootwindow. This property might
then be read by:
$> xprop -root _FLUXBOX_ACTION_RESULT
or
$> fluxbox-remote result
The format of the list is:
win_id \t title_of_window \n
win_id is '-1' when fluxbox wasn't able to parse the given ClientPattern.
win_id is '0' when there are no windows matching the given ClientPattern.
Users expect time switches to happen upon system clock times. Calculating the
timeout for the next refresh of the shown time via the monotonic clock is
wrong: The monotonic clock yields values based upon some arbitrary point in
time which might be off a little bit to the system clock, a 'full' minute of
the monotonic clock might be in the midst of a system clock minute.
The old code did not brighten up "pure" colors like "red", "green" and "blue"
at all. The new code use a different precomputed LUT which is based upon
simplified vector math, see the comments in FbTk/ColorLUT.cc
* Calling Timer::setTimeout() from within Timer::start() might lead to ugly
behavior (as experienced in bugs #3590078, #3600143, etc; see commit
4d307dcd10, fixes the problem partially).
* Stop a timer first, then call the handler (via Timer::fireTimeout()). A
given handler might call Timer::start() again, which (re)adds the Timer
to the control list .. the following Timer::stop() would remove it again.
* Use 'm_start' as indicator if timer is running.
* Move the (now quite short) code of ::addTimer / ::removeTimer
into the Timer::start() and Timer::stop() functions.
Testing bits-per-pixel in the inner loop is suboptimal, especially since
that value does not change. A little helper macro helps to keep the code
readable, also improves the situation for StaticGray and PseudoColor.
With commit 541c8c4 we switched from an (manually) ordered list to a
std::set<> to handle the active timers. The code which checks for overdue
timers now traverses and modifies the std::set<> in place. This might
lead to an infinite loop. Examples of such bad behavior are "flickering of
the tooltip" (bug #3590078) or crashes (bug #3600143) or just insanely high
cpu load when autoraising windows or submenus.
We now make a copy of the std::set<> traverse this instead of the original.
In certain situations a speedy mouse might generate more move-events
than fluxbox can handle: The event queue will fill up faster than the
repositioning of the window is finished. The user will experience a
window which lags behind the mouse cursor, aka the window-dance.
We now check the next event in the queue and postpone the move a little
bit so the queue does not fill up that fast.
fbsetbg: The random number generation used 'time' shell internal, which
does not exist in all shells. Allowing 'ps' output to be part of cksum
input will increase entropy and enhance quality of the randomness.
fbsetbg: The second fix is more important. In posix shell there is no
'==' comparision operator.
fluxbox-generate_menu: There are no quarantees about echo accepting
options, so use 'printf' for more advanced outputing.
It seems autoheader version 2.69 does not work with configure.in file,
and AM_CONFIG_HEADER macro.
aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'
configure.in:585: warning: macro 'AM_CONFIG_HEADER' not found in library
Executing: autoheader
autoheader: error: AC_CONFIG_HEADERS not found in configure.in
