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.
m_client.focus() might call ~ClientMenuItem(), thus m_client is not available anymore. the crash was triggered by trying to deiconify a client via the clientmenu. this triggers a signal to remove and destroy the current ClientMenuItem.
warping a transient window to the next workspace creates a cycle between
BScreen::changeWorkspaceID(), BScreen::reassociateWindow(), Workspace::removeWindow(),
FocusControl::unfocusWindow(), FluxboxWindow::setCurrentClient(), FluxboxWindow::focus()
and so on.
for now we just stop allowing transient windows to be warped, it is most
likely a bad idea anyway having the modal dialog on one workspace and the
(dead) main window on another one.
this issue must be analyzed further, since there might be a deeper problem
with the way the focus code works.
FbTk::Menu::updateMenu() recalculates the width() and height() of the
window. this must be done before the menu is moved to fit completely
onto the screen.
the 'menu().raise()' command is not needed, that is done inside
'menu().show()' already.
The issue was caused by a client that got an unmap notify and had a FocusIn event
directly after in the event queue. The focus in event was handled by Fluxbox::revertFocus
before the WinClient.cc removed itself from the search window list.
WindowMenuAccessor returned strange alpha values if compiled
with 'g++ -Os'; unholy black magic happens if template<int> faces
functions returning only 'usigned char'.
With ROT90-SystemTray fluxbox crashed. It is a bit unclear of where
to catch pixmaps / windows with either width or height equal to 0; IMHO
this needs more investigation.
nxserver-3.x creates a XExposeEvent for the unmapped FbTk::Menu(), which is
not configured completely yet (hence unmapped). this causes a call to
FbTk::Menu::clearItem() which then uses a value of 0 for m_rows_per_column
to divide the current index which triggers a SIGFPE.
it is still unclear, why nxserver-3.x creates the XExposeEvent for the
unmapped (menu) window. doing nothing if the menu is unmapped 'fixes'
the problem for now.
many thanks to Lars Engels (bsd-geek.de) to assist me in debugging this
issue.
a newer xlib recently changed the result of 'DisplayString()' a little bit:
instead of returning ':0.0' or ':1.0' it yields ':0' or ':1'. our code to
transform this string into something that includes the currently used
Screen worked only on something like ':0.0'.
we now find the '.' after the ':' and strip that part away.
by using FbCommands::ExecureCmd() we run 'fluxbox-update_configs' in
the bacground while booting a new fluxbox instance already. 'system()'
waits until 'fluxbox-update_configs' is done and then gives the control
back to fluxbox.
before bringing up the first instance of Fluxbox we prepare the directory
and the files it needs. if the config version of exiting files is lower
than what we expect, we upgrade the config files. after that we bring
up Fluxbox.
the old way was problematic because setupConfigFiles() calls
'fluxbox-update_configs' which does its job in the background while
fluxbox continues to boot. 'fluxbox-update_configs' sends a USR2 signal
to the booting fluxbox (it might even be finished, no one knows) which
triggers 'load_rc()' which triggered 'setupConfigFiles()' again which
might trigger 'fluxbox-update_configs' again (on my machine
'fluxbox-update_configs' was called 3 times and left a pretty crippled
'keys' file when it was done).
bootstrapping before bringing up fluxbox resolves the issue. as a bonus:
no need to send USR2 to fluxbox to reload the config file because fluxbox
has not even tried to read it yet.
to quote from 'man putenv':
The string pointed to by string becomes part of the environment,
so altering the string changes the environment.
so, using putenv like
{
std::string foo("FOO=bar");
putenv(foo.c_str());
}
is wrong and leads to a potentially corrupted environment. valgrind
complaint correctly.
FbTk::App seems to be the appropriate place to hold '::seten()'
because it alters the environment of the application.
## FbTk/ImageControl.hh:
* moved 'getSqrt()' over to TextureRender.cc because it is used only there
* removed unused members m_root_window
* use std::vector<> for colors and for the gradient buffers.
## FbTk/ImageControl.cc:
* fixed memory leak in '~ImageControl', 'pixels' where not deleted[]
at all. switched to std::vector, non-issue anymore.
* moved identical code into functions 'allocateUnallocatedColors', 'initColortables'
## FbTk/TextureRenderer:
* removed 'from', 'to', 'interlaced' from class, only used in
'renderGradient()' and are actually part of the given
texture.
* removed 'xtable', 'ytable' from class, only used in
'renderGradient()'
* removed 'colors' from the class, is part of 'control'
* moved render actions (invert, bevel1, bevel2, *gradient), they need more
love but for now this is sufficient
a lot of the parsing-related and menu-building stuff is just plain
stupid boiler plate code. putting the data into a const array
separates the boiler plate data from the actual code.
* ClientPattern.cc: make compiler happy (complaints about XPROP not handled in switch)
* FbTk/FbPixmap.cc FbTk/StringUtil.cc: signed vs unsigned
* FbTk/FbString.cc: missing return
* WinClient.cc: create atoms only once; use helper function
* Window.cc: use a helper function
for each window (windows, menue etc) the initCorners() function of
FbTk/Shape.cc was called (which is ok). On each call the corner pixmaps
(of the Screen the window belongs to) were created and destroyed the
formerly created pixmaps. this is not needed.
the global 's_corners' vector was still used on an application shutdown
(including ctrl-c SIGINT). depending on when 's_corners' was created on
the stack this could lead to an exception ('pure virtual called') while
trying to free the 'FbPixmaps' without having a valid
'FbTk::Application::instance()' left.
our users should migrate seamlessly to our new windows-cycling behaviour
without losing their current way of doing things. so, 'fluxbox-update_configs'
tries its best to add '(workspace=[current])' wherever it looks like a valid
place for it. such changed lines are marked by '!! FBCV13' at the end and can
be easily spotted in case the updater got it wrong.
addtional changes:
* added '-check' to 'fluxbox-update_configs' to check the version number in
'~/.fluxbox/init' vs. the version number of 'fluxbox-update_configs'
* moved the update-code for each version into its own function, easier
housekeeping
commit 882a50fe1d removed the hardcoded limit to
cycle to windows on other workspaces, though it was and IS a good default
behaviour. if users do not want this (they want to cycle to windows on other
workspaces), they should explicitly avoid '(workspace=[current])' in their
keysfile.
these two allow 'tagging' of arbitrary windows with 'tags' (or 'labels'). such 'tagged' windows can then be used in ':NextWindow (@PROP=foo)' commands to quickly cycle through a subset of available windows.
since the 'tags' are applied as real xproperties to a window they survive a restart of fluxbox or even another windowmanager. the user can also set the tags by using xprop(1).
the next step regarding the UI should be to visualize the tags of a window.
reasons:
* fixes#1732115, allows to have chatwindows on another workspaces and reach them via :NextWindow (urgent=yes)
* old behavior can be achieve by using the (workspace=[current]) pattern
a 'BidiString' holds both the logical content and the visual reordered
version of the content of a string. this helps to reduce the number of
calls to reorder the string before drawing it (as introduced in the patch
from Ken Bloom) and to be more consistent in menus and textboxes (drawing
cursors and underlining text).
* parse the string only once for a bunch of chars to check instead of
starting over again and again from the beginning, created a helper
function to do this (FbTk::StringUtil::findCharFromAlphabetAfterTrigger)
* put same code into a function (setClockModeLabel())
* use much simpler code to switch between 12h and 24h mode and replace
the fmt-switches
While 769130f51a did fix one issue, it introduced another by changing the
logic related to the new SignalTracker. The original logic (introduced in
9ad388c5bf) was:
-> in 'leave(Signal)', only call 'disconnect'
-> in 'leaveAll()', call 'disconnect' and 'disconnectTracker'
But 769130f51a inverted this, calling 'disconnectTracker' in both cases but
only 'disconnect' in the 'leaveAll()' case, which would leave unattached signals
around after calling 'leave(Signal)'.
This fix not only repairs the logic, but renames the ambiguous 'disconnect'
boolean to something more explicit: 'withTracker'.
As noted in the previous commit, StrictMouseFocus now works as advertised:
Focus follows mouse on every EnterNotify event (except when the "ClientMenu"
closes or during alt+tab window cycling)
This is not actually implemented yet, but from now on, "MouseFocus" means:
Focus follows mouse only when you are moving the mouse, any EnterNotify events
caused by non-mouse operations (window closing, keycommands, changing
desktops) will *not* shift focus
And once fully-implemented, "StrictMouseFocus" will mean:
Focus follows mouse on every EnterNotify event (except when the "ClientMenu"
closes or during alt+tab window cycling)
the old way of deciding which head to (re)maximize the current window
was to just test if the center of the window is INSIDE which head.
now we calculate the closest head which fixes the problem
using a smaller type ('long' on 64bit is 8 byte, 'int' is 4) results in
strange properties, eg:
_NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_HORZ, undefined atom # 0x2726130
(when xpropping a maximized xterm). this might cause misbehavior in apps.
The MemFunSelectArg* functions can be used to select
a specific argument from a signal. For example this would
select the string argument as argument to the callback:
Signal<void, int, float, string> signal;
signal.connect(MemFunSelectArg2(obj, &Object::takesOneStringArg));
signal.emit(10, 3.14, "hello");
...
void Object::takesOneStringArg(const string& value) {
...
}
For example connecting a function that takes two arguments
to a signal that emits three arguments:
struct Functor {
void show(int a, int b);
};
Functor f;
Signal<void, int, int, int> s3;
s3.connect(MemFunIgnoreArgs(f, &Functor::show));
the idea (as a first patch) for this change was provided by
Thomas Habets (thomas at habets pp se). instead of having a
fixed interval each second, we now calculate the next point in
time based upon the format string used by the clocktool to render
the time. as long as no seconds are shown fluxbox now wakes up
once every minute.
the hardcoded 'OnTitlebar Mouse1 :Raise' (see Window.cc, FluxboxWindow::buttonPressEvent())
is disabled for now, should be added to fluxbox-update_configs
static xyz inside a anonymous namespace is not really needed, so i removed the namespace
to get rid of the compiler warning. it's more convinient for the developer
to put ';' after that REGISTER_COMMAND_PARSER
When a user sets 'background: none' it really means "Do not let themes touch the
background I have already set with fbsetbg" -> It does still actually call
fbsetbeg to re-assert the proper background.
This new value 'unset' is for users who will use an alternate method to set
their background (root-tail, xscreensaver, or whatever). It instructs fluxbox
to *never* run fbsetbg.
This is the basic condition that was first noticed because of the effect of the
ClientMenu window unmapping and the resulting EnterNotify event stealing focus
from the window selected in that menu. But to be complete, any window unmapping
should cause focus to move to the next in the last-recently-focused window list,
not the one that happens to be beneath the mouse cursor.
This will be used to avoid some situations where an EnterNotify event should not
focus the window beneath the mouse cursor. For example, when a menu (or any
window for that matter) is unmapped, focus should not pass to whatever window is
beneath the current location of the mouse cursor, but to the previous window in
the focus list.
This was first noticed when using the ClientMenu feature with
focus-follows-mouse on -> The focus would always end up on the window beneath
the mouse pointer, not the window selected in the menu.
x
Mathias should listen to me when I say "by the way, I know you liked the code I
just removed; you should change your keys file to use
:MacroCmd {Focus} {Raise} {StartMoving}". Behavior in 1.0.0 and previous was
that alt+click would focus and raise, regardless of whether the window was moved
or not. If mathias really wants his alt+drag to preserve stacking order, he
should add Mouse<N>Move events to the keys file to distinguish moving from
clicking. I've been planning on doing it anyway.
