this commit implements feature-request #317: "Add support for GTK dockapps.":
"Back in 2010, WindowMaker implemented a system where windows with WM_CLASS
res_class = DockApp would be treated as if they had initial_state =
WithdrawnState, since GTK refuses to allow this."
there is problem that x/y ended with unsigned int value due to
width()/height() and negative result of division ended up being big
it causes Focus to move window due to screen boundary checks
fixes annoying behaviour of window moving few pixels with
Mod4 KP_8 :MacroCmd {ResizeTo 100% 50%} {MoveTo 0 0 Top} {Raise} {Focus}
Do not try to be too smart which compilations need config.h, as most of
them will simply because of the config.h has information about system
capabilities.
* a reasonable initial placement is important for later movements to
different heads and correct head detection (required by apps file)
* it did not work well in case when (0,0) was not near any head
Commit 79fe2fca1d checks for pending
motion events and drops out of the FluxboxWindow::motionNotifyEvent() function
early if so. When the user does not use the opaque window movement method an
outline will be drawn to the screen. That outline was not cleaned correctly
with commit 79..
First draft of feature request of #3602124: Having 2 buttons in the titlebar
which allow quick positioning of a Window into the left or right half of the
current monitor.
Users expect time switches to happen upon system clock times. Calculating the
timeout for the next refresh of the shown time via the monotonic clock is
wrong: The monotonic clock yields values based upon some arbitrary point in
time which might be off a little bit to the system clock, a 'full' minute of
the monotonic clock might be in the midst of a system clock minute.
In certain situations a speedy mouse might generate more move-events
than fluxbox can handle: The event queue will fill up faster than the
repositioning of the window is finished. The user will experience a
window which lags behind the mouse cursor, aka the window-dance.
We now check the next event in the queue and postpone the move a little
bit so the queue does not fill up that fast.
Adding the following lines to the keys file restore the old behaviour to
use Mouse2 on tabs to start tabbing, and keep OnTitlebar Mouse2 to lower
the window.
OnTab Mouse2 :StartTabbing
OnTab Move1 :StartMoving
Note: Internal tabs are triggering both OnTab and OnTitlebar events.
gettimeofday() is subject to be changed on daylight-saving or to ntp-related
(think leap-seconds). even worse, it is subject to be changed BACK in time. this
is hard to fix correctly (see commit 45726d3016 and bug #3560509). it is
irrelevant for timers to know the nano-seconds since the epoch anyways.
When a screen has more heads and some part of the screen is not on any
head and some window is placed into this invisible area then the window
is invisible which sucks. This patch repositions such windows so that
they are visible.
Example:
* head 1 is at (0,120) (size 640x480)
* head 2 is at (480,0) (size 800x600)
* whole screen virtual size is 1440x600
* that means rectangle from (0,0) to (640,120) is not visible on any head
and any windows placed there would not be visible; for example wireshark
likes to place dialog boxes at (0,0)
Found with cppcheck:
"Prefix ++/-- operators should be preferred for non-primitive
types. Pre-increment/decrement can be more efficient than
post-increment/decrement. Post-increment/decrement usually
involves keeping a copy of the previous value around and adds
a little extra code."
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
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.
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).
