| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
[PURPOSE]
In editors such as vi and emacs, a user can mark a line in a file with
a shortcut key and afterwards jump back to that line using the shortcut.
The idea is extended to opened windows. A user can assign a keyboard
shortcut to an opened window. Afterwards, the shortcut can be used to
switch focus back to the marked window.
Such shortcuts save the user from pressing "alt+tab" multiple times to
cycle through windows until the desired one is found.
[EXAMPLE USAGE]
The following binding is added to file "~/.fluxbox/keys":
Mod1 m ARG :MarkWindow
Mod1 g ARG :GotoMarkedWindow
User enters "alt+m x" to mark the currently focused window with shortcut
key 'x'
User enters "alt+g x" to switch focus to the marked window
[IMPLEMENTATION SUMMARY]
- Two new commands were added :MarkWindow and :GotoMarkedWindow
- Keys.cc was modified:
- addBinding() method supports parsing an argument placeholder where
the user can pass in a shortcut key
- doAction() method forwards the shortcut key to the command to execute
- Class Keys::t_key was modified to recognize a placeholder key
- New class ShortcutManager was added to maintain mapping of shortcut
keys to marked windows
|
|
A priori, there is no reason why the workspace warping functionality should
treat the horizontal and vertical directions at all differently. Even if
traditionally horizontal warping was more common, for some in recent times
as aspect ratios tend to become larger, stacking virtual workspaces
vertically may make more sense. Similarly, some might want to traverse
an array of workspaces in column-major, rather than row-major, order.
Prior to this commit, there were extra parameters for vertical warping (a
controlling flag and an offset for how many workspaces to jump) as opposed
to horizontal warping. Also it was impossible to allow vertical warping while
disallowing vertical warping.
This commit makes all of the parameters and behavior for horizontal and
vertical warping equivalent. For backwards compatibility, there is an
overarching flag controlling whether warping occurs at all, as well as a
separate control flag and offset for each of horizontal and vertical warping.
The relevant init file resources and default values are:
session.screen0.workspaceWarping: true
session.screen0.workspaceWarpingHorizontal: true
session.screen0.workspaceWarpingVertical: true
session.screen0.workspaceWarpingHorizontalOffset: 1
session.screen0.workspaceWarpingVerticalOffset: 1
|
|
Adds (secret) opaque resize mode. It sure would be nice if it was documented....
The relevant init file resources and their default values are:
session.screen0.opaqueResize: False
session.screen0.opaqueResizeDelay: 40
|
|
'Vertical' Workspace warping is a variant of the existing Workspace
warping feature: When a user drags a window to the edge of the Screen,
the window is warped to the next / previous workspace.
'Vertical' Workspace warping detects a drag towards the upper / lower
border of the screen and warps the current workspace about an 'offset'.
Example given, lets say the user has 9 workspaces and considers them to
form a 3x3 grid:
+-+-+-+
|1|2|3|
+-+-+-+
|4|5|6|
+-+-+-+
|7|8|9|
+-+-+-+
An 'offset' of 3 warps from workspaces 2 to workspace 5 (or 8), when a
window is dragged to the bottom / top border.
New configuration ressources:
session.screenN.workspacewarpingvertical: true
session.screenN.workspacewarpingverticaloffset: X
|
|
The iconbuttons delay their update to cover multiple changes, so if the
labels are repositioned early, they'll operate on dated titles
BUG: 1155
On the run, centralize the delay value in IconButton::updateLaziness()
|
|
playing with the side borders I figured that clicking them
(after ading them ;-) would freeze the pointer.
In addition harden the menu-triggering paths for slit and toolbar.
The menu will implicitly grba/release stuff, but in case it fails to
show up .... better safe than sorry.
|
|
on the run (yes sucks, sorry) fixes a bug where windows were not
activated on hovering the tab (for focus-follows-mouse policies)
REQUEST: 95
The iconbar already shows tooltips and I doubt the claim that (untabbed)
titlebars are "often" too short for the window title.
|
|
We simply re-use the move code.
The major pitfall is that we must not unmap the dragged window, since it
holds a pointer grab (which will break by unmapping it, so we fail to
continue or finish the tab drag)
Instead, the window is always send to the current workspace and if
detached, all other clients in the group are send back to their original
desktop.
REQUEST: 234
|
|
BUG: 1149
|
|
For the shaky ones.
Since this introduces a visible gap between trigger and move event, we
temporarily manipulate the coordinates in the global last event what
covers the outdated patch #134
REQUEST: 178
|
|
Originally patch #170 by gregor_b
Desktop stype windows will typically have their config dialogs as
transients. If those are confined to the desktop layer, they're stashed
behind everything else, so we don't force them there.
If the transient already is in the desktop layer otherwise it's a(nother)
desktop, not a dialog, and belongs to that layer, there's no need to
artificially raise it.
It's entirely sufficient to leave these windows untouched.
|
|
REQUEST: 190
|
|
|
|
So far, altering the head would potentially move the window
out of the workspace area (by moving a far right/bottom window from a
HUUUUUGE to a small screen)
This preserves edge alignments (w/ topleft preference), otherwise
moves the window to it's relative topleft position on the new head
(ie. if it was 10% left and 3% top into the screen, it will still be)
|
|
the tabcontainer is usually true and the releases were only
handled for the WINDOW context.
This relies on the patch to control OnTitlebar ./. OnWindow !
BUG: 1073
|
|
On concurrent shortcuts OnTitlebar implies OnWindow and was so
far resolved to OnWindow while OnTitlebar is the more precise
condition.
This also requires to exclude buttons from the titlebar context,
ie. pass the position to the getContext function on press events
BUG: 1035
The patch depends on the patch to correctly resolve the tab under the
mouse since we're now passing the actual subwindows around
|
|
Clients can still be stupid (feh constrains itself to the root window
...) or lazy (llpp uses the last size - if that was in pivot mode ...)
and create windows which exceed the workspace dimensions, resulting in
both opposing edges being off-screen (for all tested placements)
This applies partial maximization instead and resizes the (restored)
window to soem sane size (size constraints applied)
CCBUG: 688
CCBUG: 984
|
|
ML confirms that be.time seems to be dated or junk and
causes permanent freezes. Seen such myself but couldn't
sufficiently reproduce to pin a culprit.
|
|
The available space is distributed reg. the preferred width
of items (spacers and the iconbar ;-) instead of evenly.
The preferred width of the iconbar is calculated from its buttons.
This allows to align the iconbar using spacers and makes better use of
the available space
|
|
dialogs can be bigger than the mainwindow and the unsigned dimensions
then overflow in the subtraction (the window would still be moved into
screen bounds but appear on ugly 0,0)
|
|
otherwise compositors will update the texture and operate on (fade) the
frame instead of the client.
Didn't test why this only happens on ARGBs, but could be the colormap
installation.
BUG: 1110
|
|
closing a keyboard driven popup had the sideeffect to return the focus
where the pointer is, regardless of whether that window had the focus
before (due to a NotifyUngrab crossing event), bug #597
This was resolved by simply ignoring NotifyUngrab mode crossings, but
that had the unfortunate sideeffects to break focus passing when the
mouse was actually moved (in a DnD operation, 730) or the focus shall be
passed on for strict mouse focus and a mouse triggered lower action (1012)
So instead we record the window that was last entered by a *real*
crossing and only ignore the NotifyUngrab event if this window didn't
change.
BUG: 1012
BUG: 730
CCBUG: 597
|
|
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.
|
|
|
