Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
this way, they can be used as inputs to std::bind1st and friends
|
|
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.
|
|
|
|
I removed the const versions of reconfigSig() in the process since FbTk::Signal has no const
methods anyway.
|
|
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().
|
|
|
|
|
|
likes it that way)
|
|
|
|
|
|
use the FbTk::Timer API correctly, bug(s) introduced by
1f0adef4daa2da5b08ed7f41e7a0ce1e3f71e46f
e68511794130388ab9668fdef0dcf48dbbf002fd
|
|
|
|
|
|
had to add <algorithm> at various other files as a result of this change.
|
|
|
|
|
|
|
|
WindowMenuAccessor returned strange alpha values if compiled
with 'g++ -Os'; unholy black magic happens if template<int> faces
functions returning only 'usigned char'.
|
|
|
|
|
|
|
|
|
|
At least 'invertRGB()' does not like 'width' or 'height' being 0.
341b2f43e511e39dd was triggered by this problem as well.
|
|
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.
|
|
'typeinfo' was needed for RTTI in isItemSelectable() (see last commit)
'algorithm' is already included some lines above
|
|
|
|
MenuSeparator is never enabled since it returns always 'false' in its
implementation of isEnabled(). no need to use RTTI imho.
|
|
* removed useless struct _menu
* code deduplication via renderMenuPixmap()
* improved documentation:
- 'sublevel' actually means 'column'
- 'persub' means 'row_per_column'
|
|
while integrating the old 'getSqrt()' function into the 'bsqrt()'
function i misplaced some code. this lead to 'r' being 0 on the
first run. doh.
|
|
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.
|
|
the next step is to not use 'unsigned int' and then only store 'chars'
in it, maybe even using RGBA data instead of separated arrays for
r, g and b.
|
|
|
|
## 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
|
|
|
|
|
|
|
|
* 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.
|
|
|
|
on startup a lot of 'Fluxbox: X Error: BadDrawable (invalid Pixmap ...)' occured.
this was caused by using an empty 'Window' to create the shape.
|