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
The changes made in b178bed60b used the wrong
variable to set the default state of '--enable-randr' in configure.in, that is fixed now. I
also removed '--enable-randr12': If support for the Xrandr-extension is
available at compile time we set HAVE_RANDR; if there is also support for
Xrandr-1.2 (or higher), we also set HAVE_RANDR1_2 automatically.
Other changes:
* cleaned out public interface of 'class Fluxbox'
* added 'RANDR' to output of 'fluxbox -info'
'filename' might contain a '~' which has to be expanded to work for
regular system calls. We expanded 'filename' already but then did not use
it. Fixes bug #3576586.
I removed references to file changes as well, 'git log' works pretty well for
people who want to find out more about the history of files.
I also formatted old entries to have a consistent style all over the file.
* reduced duplicated auto-code
* renamed '--enable-newwmspec' to '--enable-ewmh'
* don't compile 'Slit'-code when '--disable-slit'
* use AS_IF() in configure.in
* use AS_HELP_STRING() instead of obsolete AC_HELP_STRING in configure.in
* removed redundant calls to 'imlib2-config' to fill in $IMLIB2_CFLAGS
and $IMLIB2_LIBS, AC_PATH_GENERIC() does that out of the box already
