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.
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.
* 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
* much more readable and easier to read code
* smaller code
* reduced binary size due to removed big lookup-table for square root
* simple 'optimizations (lookup tables, packing of data), nothing too fancy
Adding the following lines to the keys file restore the old behaviour to
use Mouse2 on tabs to start tabbing, and keep OnTitlebar Mouse2 to lower
the window.
OnTab Mouse2 :StartTabbing
OnTab Move1 :StartMoving
Note: Internal tabs are triggering both OnTab and OnTitlebar events.
The old formula for vertical align text inside FbTk::TextButton ('height/2 +
font_ascent/2 - 1') produced not always good looking results, escpecially
when different fonts are involved (eg, ClockTool and WorkspaceName have
different fonts and font-sizes).
'(height - font_ascent) / 2 - 1' produces better results.
Additional changes:
* added ASCII-Art to document the involved entities when calculating the
baseline
* rewritten tests/testFont.cc to accept multiples texts and multiple
fonts
* removed some internal parts of FbTk::Font from the public interface
Setting a new timeout on a running FbTk::Timer must remove it from the timerlist,
otherwise the list is not ordered correctly anymore. So, we stop the running
FbTk::Timer, set the new timeout and restart it.
gettimeofday() is subject to be changed on daylight-saving or to ntp-related
(think leap-seconds). even worse, it is subject to be changed BACK in time. this
is hard to fix correctly (see commit 45726d3016 and bug #3560509). it is
irrelevant for timers to know the nano-seconds since the epoch anyways.
When a screen has more heads and some part of the screen is not on any
head and some window is placed into this invisible area then the window
is invisible which sucks. This patch repositions such windows so that
they are visible.
Example:
* head 1 is at (0,120) (size 640x480)
* head 2 is at (480,0) (size 800x600)
* whole screen virtual size is 1440x600
* that means rectangle from (0,0) to (640,120) is not visible on any head
and any windows placed there would not be visible; for example wireshark
likes to place dialog boxes at (0,0)
Found with cppcheck:
"Prefix ++/-- operators should be preferred for non-primitive
types. Pre-increment/decrement can be more efficient than
post-increment/decrement. Post-increment/decrement usually
involves keeping a copy of the previous value around and adds
a little extra code."
Applications like urxvt look for the _MOTIF_WM_INFO atom in order
to know if the window manager implements mwm hints. If this atom
is not found, then urxvt sets override_redirect when started with
the borderless option and falls out of the control of Fluxbox.
if pos is not npos, it will always be less than filename.size().
However, the access later is only safe if there is a character
after pos, which would require pos + 1 to be less than filename.size.
93924af160 might corrupt memory with gcc-4.6.1 when
finishing fluxbox (clicking 'exit', sending it a SIGINT). Allthough the order, in which static / global
objects are initialized is undefined (at least between separate compilation units), the order in
which they are destroyed is well defined: in reverse order of initialization.
this means, that if 'ScreenImlibContextContainer contexts' (of ImageImlib2.cc)
gets initialized AFTER 'ImageImlib2 imlib2_loader' of Image.cc, it gets destroyed before
imlib2_loader. When that happens, ~ImageImlib2() works on a destroyed object.
(That lead to '* glibc detected * fluxbox: corrupted double-linked list: 0x0000000000dd2710 ***'
later on in 'iconv_close')
fluxbox now properly displays windows that require ARGB visuals when
an external compositor is running. This was done by creating the
container window with the correct visual and colormap when needed.
Closes#2874629
the deleted function was never used, otherwise it would generate an error with other compilers as
well. icc noticed that it was nonsensical even when it wasn't used and complained.
The idea is that connecting to a signal doesn't change it's state or the state of the object
owning the signal (even though it needs to add the functor to the list for later reference).
Emitting, on the other hand, is usually done as a result of a state change and therefore remains
non-const.
Additional benefit of this arrangement is that objects can export const references to signals to
allow connecting, while keeping the ability to emit to themselves.
without this it wasn't possible to construct a Slot returning void from functors returning some
real value because the compiler would complain about "return statement with a value in a function
returning void".
Theoretically, this may produce some unexpected type conversions, because static_cast is slightly
stronger than implicit cast, but I judge the risk to be negligable (the alternative would be to
provide explicit specializations for slots returning void - too much typing)
without them, gcc would compare them by converting them to bool first, which is not exactly what
one would expect. Frankly, I'm surprised it even worked without this.
it is too easy too shoot yourself in the foot with it, other smart pointers also don't allow such
assignments. If you do want to assign to a RefCount pointer, use reset().
ps: assignment between two RefCounts remains possible, of course.
