Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
ps: the Resource class inherits from the Traits class instead of holding it as a member because
it's more size-efficient (base classes can have zero size, members cannot).
|
|
ps: this is a bonus, without this one needed to completely restart fluxbox for the updates to
tabPadding to take effect.
|
|
when saving/loading to/from string representation.
This is needed for the next commit.
|
|
Loading of an init file with the new manager works ok. Saving and restarting is still not
completed.
This touches many files because i removed the alternative name of resources. Unlike Xrm, lua does
not have native support for alt names. It should be fairly easy to add them, but I think that is
unnecessary and would be confusing.
|
|
by outsourcing the conversion from string/lua to the specific type (and back) to a separate
class. This change touches a lot of files because the interface of FbTk::Resource changed
slightly. However, the changes are minor.
|
|
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.
|