Age | Commit message (Collapse) | Author | Files | Lines |
|
this affects all java clients, because java uses the retarded
WM_TAKE_FOCUS protocol, but also very important clients like xeyes ;-)
BUG: 1055
|
|
deiconify'ing a client on a different workspace left an oplock by a
shortcut return, turning the client semi- to inaccessible
BUG: 1010
|
|
While usually™ the window is just reset to its original layer, ensuring
to show the active window is certainly a good idea, but it's not
required to lower the fullscreen window to the desktop layer, the other
windows layer + an extra raise is entirely sufficient and it's rather
odd to see conky when activating a utility window to a video player ;-)
CCBUG: 894
|
|
Tabs outside the titlebar are not selectable by mouseclicks (ie. the
feature does not work)
The patch clones the enterNotifyEvent code and ignores (for now) the
actual button (no idea whether it makes any sense to restrict it the
left button?)
BUG: 1103
|
|
The FocusNewWindow key is still read, but not written and OVERRIDDEN in
case of conflict with the FocusProtection key
|
|
The apps file gets a new key
FocusProtection
supporting a comma separated list.
* None : regular behavior
* Lock : If this window has the focus, no other may claim it
* Deny : This window is not allowed to focus itself
I addition there's preparation for a follow-up patch to incorporate and
substitute the present FocusNewWindow feature:
* Gain : Pass focus to new window
* Refuse : Do not pass focus to new window
rationale:
clients stealing the focus sucks badly and while there's an input driven
timeout, that only protects actual typing flow, but if eg. vlc proceeds on
the playlist, you'll suddenly control vlc instead of your browser
(ie. typing ctrl+w doesn't close the tab, but the playlist ...)
|
|
|
|
Still enough stupid ones around which ask for 0,0
(despite there's a panel ...) or restore a position
on a VGA screen which they stored while being on a 4k
screen.
Otoh, do not forcefully position the window just because
the topleft position is outside any head, this can still
be desired and isn't a problem.
Actually, the corner could be covered by the close button
and if *only* it is onscreen the window can hardly by used
or seen.
|
|
so far, transients are simply unplaced, resulting in a static
0,0 position.
|
|
Make windows snap to edges when resizing them, as well as when moving.
From http://darkshed.net/files/patches/fluxbox/fluxbox-resize-snap-try2.diff
|
|
Instead of creating the titlebar buttons with a size of 10x10 pixels
and rely on resizing later on we now pick the correct dimensions
right on.
This fixes also bug #1125 ("Detaching a window from a tab-group renders
app-icon to 1/2"); the problem also occurred on restart.
I took the chance to refactor a little bit.
|
|
|
|
|
|
Clang and Gcc-4.9 complaint about some unused variables here
and there. And who are we to not make a compiler happy :)
|
|
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}
|
|
The earlier _GNU_SOURCE definitions possibly did not take effect
everywhere where it was intended.
|
|
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.
|
|
|
|
|
|
placement based on apps file
* 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 79fe2fca1de5140f538e68f6981b27cf7f917e7a 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 45726d3016e 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)
|
|
shown on window (it did nothing before)
|
|
|
|
|
|
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
|
|
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
|