Age | Commit message (Collapse) | Author | Files | Lines |
|
this reduces typing and it makes more sense in lua, since there the resources are implemented as
hierarchical tables and the topmost table has to be handled a bit specially.
|
|
|
|
|
|
|
|
by outsourcing the conversion from string/lua to the specific type (and back) to a separate
class. This change touches a lot of files because the interface of FbTk::Resource changed
slightly. However, the changes are minor.
|
|
for various values of X.
|
|
I added a new class, LResourceManager, which should handle loading and saving of resources like
the old ResourceManager, only it does that with the help of lua. I moved the common features of
the two managers (interface + a few functions) to a common base class ResourceManager_base. I
augmented the Resource_base class with two new functions (setFromLua and pushToLua) which are
used by the lua RM instead of getString and setFromString.
Parts of the new RM are written in lua. To avoid loading scripts from a file at runtime I decided
to link compiled lua code straight into the executable. For this purpose I created a small script
which converts a binary file into a declaration of a C array of bytes.
|
|
function
|
|
|
|
|
|
parameter
|
|
|
|
It's impossible to do this without C++0x features (we need std::exception_ptr).
|
|
See how variadic templates are good. They enabled me to write those four functions as one.
|
|
It was pretty underused anyway. I was just lazy to write a proper destructor.
|
|
|
|
std::function is superior, but not supported on old compilers
|
|
copied from conky (http://conky.sf.net) and relicensed. Since I am the person who wrote it in
the first place there should not be a problem with licence conversion.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
* Calling Timer::setTimeout() from within Timer::start() might lead to ugly
behavior (as experienced in bugs #3590078, #3600143, etc; see commit
4d307dcd10af9d817ff5c05fc40ae7487564cb31, 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.
|
|
Added the option to remove the SystemTray tool completely from
fluxbox.
|
|
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 INCLUDES macro deprecated in favour of AM_CPPFLAGS.
References: http://www.gnu.org/software/automake/manual/html_node/Program-Variables.html
|
|
release tar ball
|
|
|
|
The XKeycodeToKeysym() is deprecated.
References: http://comments.gmane.org/gmane.comp.misc.suckless/9403
|
|
|
|
|