| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Windows returns pointers to empty strings for non-existent env vars.
|
|
Needed for mingw-cross-env
|
|
calling imlib_set_cache_size() before a context is created by fluxbox creates
an 'unknown' context. that one is never freed at shutdown.
|
|
|
|
|
|
|
|
93924af160ea303c94a2576b0e57a04e94c9228c 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')
|
|
make public only what needs to be public
|
|
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
|
|
nowadays every app should use the extended window manager hints exclusively.
|
|
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)
|
|
|
|
connectSlot
I do this to avoid compiler ambiguity between the two versions of connect()
|
|
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.
|
|
I'm doing this because I want to have access to keybindings from lua and for that I need more
flexible ownership semantics.
|
|
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.
|
|
ps: it was already commented out, I'm just deleting it
|
|
|
|
|
|
This way we can use Commands as signal handlers out-of-the-box.
|
|
Command offers a subset of functionality and could be completely removed at some point.
|
|
it was testing for FbWindow.property() == Success, where it should've tested for == true.
|
|
to make it's interface more compatible with other smart pointers.
|
|
|
|
Added some polish around them and, to mark this special occasion, moved them out of the SigImpl
namespace.
PS: This partially reverts commit 0775350fee345e37fb59835dda4d85664346b606, 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.
|
|
and remove a an "almost" copy constructor (almost, because it takes a non-const reference
parameter) which was useless.
|
|
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'.
|
|
in toolbar
|
|
|
|
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.
|
|
this marks the completion of the transition to FbTk::Signal
|
|
|
|
|
|
|
|
Also, I spotted a potential bug in the code. I marked the place with XXX. Someone should take a
look at that.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
