| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
the -1 in the FbTk::FbTimer::remainingNext() function was pointless in the
first place anyway: reducing the timeout by just 1 microsecond improves
nothing (in this case). if the timer triggers exactly at a full unit (second)
then it's correct to wait for the full next unit.
|
|
|
|
the lag / skipping of the clock was not caused by faulty timer code
on fluxbox's side but by the behavior and inner workings of time().
since this is fixed now (913244789f) we can now rollback ec7fe513c8
and detect strftime-formats which need intervals of seconds or minutes.
minor: the small change to FbTk::Timer::setTimeout() reduces one
start() / stop() cycle for a running timer.
|
|
from time to time (...) time() might be off to gettimeofday() by a
second. the reason for this is that time() is usually implemented
by just returning the field 'second' of the struct that represents
the clock inside the kernel. gettimeofday() on the other hand also
takes the 'fraction' field (mostly 'nanoseconds') into account and
thus is closer to the current time than time().
the result of using time() was a perceived 'lag', sometimes the
clocktool even skipped a second. by using FbTk::FbTime()::system()
instead fixes the issue.
|
|
|
|
|
|
|
|
xmodmap (and other tools) trigger MappingNotify events. a single xmodmap
expression such as "keycode comma = comma semicolon" might trigger 4 or 5
MappingNotify events. loading the keys file on each of them is quite
unefficient.
fluxbox now uses a (250ms) timer which is reset upon further events.
|
|
there is problem that x/y ended with unsigned int value due to
width()/height() and negative result of division ended up being big
it causes Focus to move window due to screen boundary checks
fixes annoying behaviour of window moving few pixels with
Mod4 KP_8 :MacroCmd {ResizeTo 100% 50%} {MoveTo 0 0 Top} {Raise} {Focus}
|
|
This commit fixes primarily a race condition that occurs when xinit(1) shuts
down: by not acting properly fluxbox gets caught in an infinite loop. It
caused bug #1100.
xinit(1) sends a SIGHUP signal to all processes. fluxbox tries to shutdown
itself properly by shutting down workspaces and screens. While doing that, the
Xserver might be gone already. Additionally, fluxbox used to restart() itself
on SIGHUP, which is clearly not the right thing to do when xinit(1) is about
to end the session.
So, fluxbox does this:
* handling SIGHUP now shuts down fluxbox without clearing workspaces and
screens.
* A 2 second alarm() is triggered in Fluxbox::shutdown() as a last resort
* XSetIOErrorHandler() is used to recognize the disconnect from the xserver.
* SIGUSR1 is for restarting fluxbox, SIGUSR2 for reloading the config
* FbTk/SignalHandler.cc/hh is gone; this unused abstraction served currently
no real purpose. Signal handling is now done in main.cc
* Unrelated to the issue itself src/main.cc was trimmed down quite a bit and
the code (responsible for handling the command line interface) was moved to
src/cli*
|
|
|
|
* Fix integer wrap around for some situations (resulting in a very wide
window):
w = max_width - x_offs - (*closest)->widthOffset()
If the given window is on the right most display and thus 'x_offs' is
bigger than 'max_width' (half of the display width), the resulting 'w' wraps
around and becomes very large.
* Place a single window via ArrangeWindowsStack* as well
* Some minor code styling / reordering along the way
|
|
|
|
Do not Ungrab the keyboard for a KeyPress event, this causes us to lose the
KeyRelease event which is needed to ungrab the keyboard after the event
happened.
|
|
std::bind2nd() has problems with the existing call because it uses the
argument type passed to std::equal_to() in std::binder2nd()'s constructor,
but WinClient* does not have the const specifier that `client' does.
The call works fine with libstdc++ because of the way it implements
std::bind2nd(), but fails with libc++ and possibly with other STL
implementations as well.
|
|
usually $HOME is set when fluxbox runs. in some rare scenarios (eg., fuzzying
binaries to detect bugs) one could launch fluxbox by using 'env -i' and thus
eliminating $HOME from the environment. to prevent crashes fluxbox uses now
'getpwuid()' when $HOME is not set to detect the home folder.
|
|
|
|
Detecting very long window titles is done via FbTk::TextUtils::doAlignment().
Instead of removing one char from the title at a time to see if it fits into a
given 'max_width', we now use a binary-search like approach to get faster to
the right value. This massively improves the speed for windows with
(arbitrary) long window titles (see bug #1090, javascript
document.title = new Array(4999).join(".");
leads to massive waiting for fluxbox to detect that this window has a very
long title).
In addition to that Xft returns 'wrapped' shorts ('integer overflows') for
long texts: XGlpyhInfo.xOff is declared as signed short, it's able to hold
~32k pixels. A monospace font with font-size 10 produces an integer
overflow after 3276 chars / glyphs, thus rendering the check
if (text_width < max_width) { /* ... */ }
pointless and leading rendering the whole title. By calculating some kind of
upper limit for a pseudo-wide glyph ("WW") and strictly cutting off the input
string at that limit prevents this issue.
|
|
This rather large change will attempts to make 'make' to work better.
See excellent paper 'Recursive Make Considered Harmful' by Peter Miller
for further explanation why several make files is worse than one for
whole project.
Note. The tests are build with 'make check' rather than defining TEST.
Reference: http://miller.emu.id.au/pmiller/books/rmch/
Reference: http://karelzak.blogspot.co.uk/2013/02/non-recursive-automake.html
|
|
This commit alters XRANDR (X Resize And Rotate) extension dependency,
which is expected to have at least version 1.4. Earlier old versions of
xrandr were supported, at least to some extent.
|
|
The earlier _GNU_SOURCE definitions possibly did not take effect
everywhere where it was intended.
|
|
Do not try to be too smart which compilations need config.h, as most of
them will simply because of the config.h has information about system
capabilities.
|
|
|
|
|
|
|
|
placement based on apps file
* a reasonable initial placement is important for later movements to
different heads and correct head detection (required by apps file)
* it did not work well in case when (0,0) was not near any head
|
|
placement based on apps file
* if you have e.g a 1920x1200 monitor and a small 800x600 monitor to the
right of the bigger one and a small window at the right side of the
big monitor (but still the whole window area at the big monitor) then
the original head detection would claim the window is on the small
monitor because (800/2+windowWidth/2 < 1920/2+windowWidth/2) is true
for small windows; but that is obviously wrong, the window is entirely
on the big monitor
* these incorrect head detections did lead to incorrect window
placements as they were required in the apps file
|
|
Commit 79fe2fca1de5140f538e68f6981b27cf7f917e7a checks for pending
motion events and drops out of the FluxboxWindow::motionNotifyEvent() function
early if so. When the user does not use the opaque window movement method an
outline will be drawn to the screen. That outline was not cleaned correctly
with commit 79..
|
|
|
|
|
|
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.
|
|
|
|
I forgot this piece in 779618e45d4571bb6a4866aa2e398780f4b4da5d.
|
|
The buffer for some gradients does not have to be width * height big when two
lines are sufficient.
|
|
|
|
|
|
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
|
|
Stupid typo.
|
