| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
fbcompose(1) is an optional compositing addon for fluxbox window manager. It
augments fluxbox with a number of graphical features. Most notably, fbcompose
allows fluxbox to properly display applications that require compositing
(docky, for example), adds support for true window transparency (as opposed to
fluxbox's pseudo transparency) and provides a plugin framework to extend the
compositor's functionality.
As this is still a beta version of the compositor, the bugs are likely.
|
|
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
|
|
Also, I spotted a potential bug in the code. I marked the place with XXX. Someone should take a
look at that.
|
|
|
|
|
|
|
|
|
|
|
|
I removed the const versions of reconfigSig() in the process since FbTk::Signal has no const
methods anyway.
|
|
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().
|
|
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.
|
|
see #3088856 / 09f99a4674a75a201effdc912d79a28c2dad4225.
at the moment this fix looks side-effect free, time will tell.
|
|
workspace, see #3088856
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.
|
|
* 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
|
|
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.
|
|
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).
|
|
|
|
|
|
|
|
|
|
while keeping its current position / size
|
|
the properties correct
fixes partly #2980313, resize with keys still does not trigger _NET_WM props to be correct
|
|
|
|
this allows to move some hardcoded keysbindings into the keys file and
makes the code simpler
|
|
|
|
The focus signal emits the window that had the focus status changed.
|
|
This will reduce the number of #ifdef DEBUG for
simple debug messages.
include "Debug.hh" and use fbdbg instead of cerr for debug.
|
|
the hardcoded 'OnTitlebar Mouse1 :Raise' (see Window.cc, FluxboxWindow::buttonPressEvent())
is disabled for now, should be added to fluxbox-update_configs
|
|
|
|
|
|
initialize this from that'
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Moving and Resizing windows can reveal other windows, which of course can change
unexpected focus changes in focus-follows-mouse.
|
|
Lower is one of the actions which may reveal a window under the current mouse
pointer which would unexpectedly change focus under focus-folows-mouse.
|
|
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.
|
|
|
|
this fixes a problem when the user resizes a window over the opposite border.
as a result a signed overflow occured which lead to quite huge windows.
|
|
|
|
|
|
|
