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'.
Fluxbox's man page had "allows to", which should actually be something like
"allows one to".
The rest of the .ins were rebuilt as a result. No changes otherwise.
CC-BY-NC 3.0 is a great license, but it limits how well we can redistribute
the theme it's self. This change allows distros (such as Debian) to keep this
theme in the source.
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().
The previous check relied upon the (undocumented) return value of
XChangeProperty to determine the exit status; at least, on my gentoo system,
the function seems to return 1 even when it fails to change the property
due to contrived, and invalid, parameters. However, setting an error
handler allows proper detection of this case. So, now the return status
properly indicates whether or not the property was changed (but not
whether fluxbox liked the command!).
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.
