Every time either the Slit menu or the Toolbar menu were added to the
root menu, the whole root menu was (re)created from scratch. Now we
create and remove only the menus needed.
Side effect: the position of these menus is now at the end of the root
menu and not somewhere in between. If users complaint, I' ll think about
it.
This commit is a preparation step for some menu cleanup ahead. To make it
easier to understand which types of MenuItems are added where and when, I
converted the overloaded FbTk::Menu::insert() functions into explicit ones
(Menu::insertSubmenu(), Menu::insertItem(), etc. ). This makes it possible
to just grep for 'insertSubmenu()'.
Side effect this commit: it trims down the very verbose creation of menu items
in regards to how the labels are created.
Minor: FbTk::Menu::shown and FbTk::Menu::s_focused are moved out of the class.
The font might have an impact to the result of width() and height(). In order
to render the new pixmap correctly fluxbox now first sets the font and the
width of the border and after that it recreates the pixmap.
When fluxbox comes up some of it's drawables span a 1x1 area. Subtracting from
such small numbers bigger ones always lead to massive problems when 'unsigned
int' are involved:
'button_width' is an unsigned int of '1' (this might be caused by another
issue or on purpose, anyway), subtracting -10 or any other number should
result in something < 0 when in reality an integer underflow happen: max_width
is now MAX_INT-something big. This makes fluxbox crash under certain
circumstances.
This fixes bug #1116.
* Correctly build data files when operate outside of the $(srcdir)
* Actually install data files
* Use pkg-config to detect X11, works better on MacOSX. We used pkg-config
already anyway, double checking for X11 does not yield better results.
* Replace EXEEXT in some files while before installing them
xxx_LDFLAGS place the libraries like '-lX11' or '-lXft' at the beginning of
the linker command. Some systems were not able to handle the situation and
this lead to a lot of unresolved symbols. Reading the documentation of
automake:
... you can use LDADD to do so. This variable is used to specify
additional objects or libraries to link with; it is inappropriate for
specifying specific linker flags, you should use AM_LDFLAGS for this
purpose.
In addition we link against -lm in order to satisfy symbols refering to 'cos'
and 'sin'.
POSIX states that 'd_name' in 'struct dirent' is char[], so it cannot be NULL.
This will result in the compiler complainting about an expression which always
evaluates to true ... for this compiler (clang). But in some implementations
'd_name' is a 'char*' that's why it's better to keep the check for possible
NULL.
OSDWindow::resize(const FbTk::BiDiString&) shadowed FbWindow::resize(x, y). To
fix this I renamed the function to OSDWindow::resizeForText() to make the
intention clear.
While running code analysis tools this issue popped up. As it is written it is
clearly a NOP, but the reason for why it is written that way remains unknown.
I suspect that it was a textfragment introduced by some repeat-function of the
used editor (think '.' in VIM). The code was introduced by commit a932a7a801
and looked like this in the original form:
if(!XQueryTree(FbTk::App::instance()->display(), window().window(),
&root_return, &parent_return,
&children_return, &nchildren_return))
parent_return=parent_return;//return;
Look at the outcommented return statement. I decided to return from that
function instead of the NOP.
This commit fixes issues #72 (brought up + different solution by Mattias
Guns; I received a similar patch by 'Nable 80' via ML and discussed the
issue in #fluxbox with 'Nable 80'), patch #73 (Mattias Guns) and finally
patch #162 (Ulrich Eckhardt; this commit is heavily based upon Ulrich's
work).
The original code was overly complex. It tried to avoid writing
bytes to the disk at the expense of comprehensibility and as a result it
was buggy. I looked at both patches from Mattias and 'Nable 80' which address
the bug with skipping entries in the history-file (my fault: incorrect use
of outfile.ignore(1, '\n')): They provided a proper fix for the problem
but I decided to use Ulrich's code since it improves the whole code by making
it a lot simpler.
So, kudos to all of you.
this commit implements feature-request #317: "Add support for GTK dockapps.":
"Back in 2010, WindowMaker implemented a system where windows with WM_CLASS
res_class = DockApp would be treated as if they had initial_state =
WithdrawnState, since GTK refuses to allow this."
kudos to Arkadiusz Bokowy (this commit is a slightly changed version
of a patch sent to the devel-ml): when retrieving the '.res_name' of
a XClassHint we should check '.res_name' and not '.res_class'.
the other changes only reduce the code.
handing over the dimensions of a WinClient client must not contain properties
of the FbWinFrame, otherwise they get added twice in
FbWinFrame::moveResizeForClient() and thus result in a resizes when no resize
is wanted.
other changes: it's easier for me to detect the nth bit when the value looks
like (1 << 8) instead of 0x0100 (for the 8th bit). that is why i changed
0x0100, 0x0200 etc. in the nearby code.
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.
