This reverts 58e09b7190 after having regressions
and bug reports in regards to autorepeated key events are not working anymore.
So, the problem with the lost keypress after the workspace change is still
open but at least the behavior for other folks is as it was. Since 58e09b7190
seems to be corelated to "auto repeat" keys it might indicate the problem
which 58e09b7190 "fixed". We will see.
Fixes#1115.
Note: I expect only modern compilers will hit the source of fluxbox. It
seems futile to guard stdlib headers while demanding <algorithm> etc. This
should trim down the noise in the source quite a bit.
Part of this massive looking but simple rather simple change is a the way we
check for active Xinerama: XineramaIsActive() was used before. The docs for
XineramaQueryScreens() state that
XineramaQueryScreens() returns NULL and sets number to
0 if Xinerama is not active.
Sold.
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 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.
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 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.
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.
* 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
* 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 79fe2fca1d 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.
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.
Added some polish around them and, to mark this special occasion, moved them out of the SigImpl
namespace.
PS: This partially reverts commit 0775350fee, since I had to
reintroduce ReturnType template parameter, because it will be used in other places. But Signal classes
remain without the ReturnType, because I still cannot imagine how would it be used.
Commit 690d926 (introduced FbTk::BidiString) broke building without
HAVE_ICONV, because of wrong variable name and use of iconv_t type.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
otherwise a race condition might appear between copying the default
config files to .fluxbox/ and executing 'fluxbox-update_configs'. under
macosx this lead to 'fluxbox hangs'.
setxkbmap and xmodmap both might change the keycodes. thus fluxbox needs
to remap the keysyms from the currently loaded keytree to new keycodes
after it received a 'MappingNotify' event.
we do not reload() the keys file because:
* the user might work on it right now
* remap only needed symbols is cheaper than parsing the keysfile anyway
The icons coming from _NET_WM_ICON are argb32. fluxbox uses such icons
in entities such as 'clientmenu', 'iconbar', 'titlebar'. These entities
are not related to the depth of the winclient but to fluxbox's default
depth. Using 'winclient.depth()' is a mistake, since fluxbox is unable
to copy pixmaps from 32bit to 24/16/15bit.
It is not necessary either, because fluxbox should extract the argb32 icon
data directly into the pixmap with the correct depth in the first place.
This fixes (reopened) bug #1852693.
Note: The whole icon code in fluxbox is quite messy, lots of copying and
scaling. It might be simpler and fater to just extract the icon when needed
, in just the size that is needed.
Prior to this patch, TextDialog did not handle parentrelative labels;
borrowing code from OSDWindow, now TextDialog properly handles this.
Eventually, I plan to combine the good parts of TextDialog and OSDWindow
into OSDWindow, and then let TextDialog derive from OSDWindow... but for
now, here's the band-aid fix for the issue without the refactorization.
TextDialog windows (such as 'set title', or 'edit clock format') now
properly render their titlebar to match the current style. Previously,
the titlebar font settings were controlled by window.font.*, and this
became apparent because window.font.effect needed to be set to put
'halo' on the titlebar of these TextDialogs. However,
window.font.effect controls the effect on the text within the editbox on
these as well, having these set in the same location is far from
desirable. Specifically because the TextDialog essentially emulates the
titlebar of other windows. So, after this change, window.font.effect
still controls the text in the editbox, but the titlebar area is themed
as the titlebars of other windows.
Text justification of titlebar and border width, is now respected in
TextDialog. Also, previously the edit box was sized in an odd way; one
which left part of the window actually undrawn (so you'd get artifacts
from whatever happened to be on the screen in that position when it
opened); this has been addressed.
TextDialogs, rather than going to the center of the entire desktop, now
center on the _current head_, which prevents the awful positioning where
half of the window is on one screen and half is on another.
Lastly, when hovering your mouse over the iconbar button for a window
with a title that's too wide to fit on the button, a tooltip is
displayed. This tooltip themes itself to match the button, however it
wasn't using the theme properly (similarly to how TextDialog was)... and
as such, also wasn't using the proper font effects. This has been
addressed just as it was for the TextDialog.
previously, the tracker disconnected itself only when the caller passed withTracker = true to the
leave() function. However, the default value was for the parameter was false.
Non disconnecting from signal when stopping tracking creates very dangerous situation because the
signal still holds a pointer to the tracker. This resulted in a segfault when exiting fluxbox,
because the tracker (FluxboxWindow) got destroyed before the signal (BScreen::focusedWindowSig),
and the signal was using an invalid pointer when it tried to disconnect itself from the tracker.
Instead of setting withTracker to true by default or changing all invocations of leave(), I
decided to make the tracker disconnect itself unconditionally because I could not find a use case
for the opposite behaviour.
PS: This message is in fact longer than the actual commit.
previously they declared the parameter, but ignored the return value of the member function. I've
changed it so they pass the return value, if it is not void. MemFunSelectArg didn't have the
ReturnType template parameter, so I added it for consistency. Since I was already editing the, I
made all the operator()s const.
- merged all the common stuff from 0,1,2,3 argument versions into one common base class
- removed ReturnType template parameter as it was instantiated with "void" everywhere and the
current ignores the return value of the callbacks anyway
this was possible (and used) with FbTk::Subject, but the implemetation of FbTk::Signal didn't
support it, which made it impossible to continue with conversion.
Replace CallbackHolder, FunctorHolder and SlotHolder with a (smaller) set of polymorphic classes.
SignalHolder now stores a (smart) pointer to the class.
the previous version of operator*() made no sense. E.g., it violated the invariant
(*ptr).foo <=> ptr->foo. The dereferencing operator now returns a reference to the pointed-to
object, rather than a pointer to it.
I also added a bool conversion operator, which can be used in testing the NULL-ness of the
pointer. Anyone wondering if that could be done in a simpler way is encouraged to read
<http://www.artima.com/cppsource/safebool.html>.
And, finally, I removed the mutable flag from the m_data member, since it does not need it.
basically, i just got rid of Signal[0-3] classes and moved their contents to the appropriate
specialization of FbTk::Signal
also, this fixes the
no matching function for call to 'MemFunIgnoreArgs(FbTk::Signal<void, FbTk::SigImpl::EmptyArg,
FbTk::SigImpl::EmptyArg, FbTk::SigImpl::EmptyArg>&, void (FbTk::SigImpl::Signal0<void>::*)())'
error i had in the following commit.
Introduces a new member function, FbWindow::cardinalProperty()
This change also changes other code that previously used
FbWindow::property() to do the same thing as the new function; this
reduces code duplication.
There are still some bits of code (Ewmh.cc, extractNetWmIcon()) that use
FbWindow::property() to retrieve XA_CARDINAL values, but as the new
method is designed for getting a _single_ property, and that code uses
FbWindow::property() to retrieve the number of values present, and then
grab all of them; it's a different use case. I opted to not try to make
cardinalProperty() into some monolithic all-purpose cardinal method;
FbWindow::property() works just fine for that.
This change also adds an optional (default=NULL) boolean to
FbWindow::textProperty and friends that allows the caller to determine
whether or not a value was actually retrieved. This was necessary for
integrating FbWindow::cardinalProperty with the codebase, and it seemed
to fit with FbWindow::textProperty as well. Prior to this change, if
you got a return value of "", you wouldn't know if you successfully
retrieved the value which happened to be blank, or if you failed to
retrieve the value. Now, you can pass the address of a boolean if you
so choose in order to differentiate these situations; the same applies
to the new FbWindow::cardinalProperty().
and add a configure option for building them (default: off).
This patch fixes an error when configuring the tarball, where configure complained it cannot find
src/tests/Makefile.in.
biggest change: renaming of 'class Layer' to 'class ResourceLayer' in
Layer.hh to handle complaints about 'ambiguous Layer: Layer or FbTk::Layer'.
'ResourceLayer' sounds crappy, but that was the best I could come
up with right now.
changing the layout or the number of the attached monitors
might lead to invisible windows. only those windows should be
positioned to the closest monitor, if they are not visible
already.
