| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
|
The function failed if the last event window was actually the tab.
|
|
|
|
The user needs to enter his chain within 5 seconds
Otherwise the chain is reset.
REQUEST: 291
|
|
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)
|
|
Unclutter the desktop by using the MinOverlapPlacement
for all matching windows.
REQUEST: 248
|
|
When trying to doAction(ButtonPress, ...), we check whether the
action would hit for type==MotionNotify.
In this case we do nothing but return "true" to tell the caller that
this event is "for us". Otherwise the event would be replayed to the
client and there'd go out MotionNotify grabs.
tl;du: This fixes MoveX actions.
|
|
fluxbox uses std::unique_ptr<> where it previously used std::auto_ptr<>.
C++0X was approved in 2011. among other things, it deprecates std::auto_ptr.
5 years is long enough for compilers to catch up the standard.
|
|
This allows to catch if a grabbed key (combo) is actually w/o effect
(because eg. the OnDesktop condition does not match) and then replay
the event ungrabbed to pass it to the focused client.
Just like mouse grabbing, this BEARS THE POTENTIAL TO LOCK INPUT, thus
needs AS MUCH TESTING AS POSSIBLE
BUG: 1137
|
|
NOTICE!!!! THIS IS HIGHLY EXPERIMENTAL!
The patch alters the button grab mode to GrabSync
in order to ReplayPointer the event.
THIS CAN FREEZE ANY INPUT TO FLUXBOX!!!
The toolbar (and other things?) grab buttons in order to
handle MouseN events for the entire bar, INCLUDING all child
windows.
This causes two problems:
1. The bar handles events which are not meant for fluxbox at all
(but the systray icons)
BUG: 940
2. The bar will intercept (and suck) *every* press, even if only
doubleclicks are desired
BUG: 949
The problem with this patch is that an oversight here has the potential
to completely freeze input event processing in fluxbox (ie. the process
needs to be killed from outside), SO IT NEEDS TESTING!
As much as possible.
|
|
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
|
|
The feature suggests to behave like this bug actually only supported
mouse clicks (because the latest event window needed to be the tab)
This condition will break with two future patches (OnTitlebar context
selection and Sync Pointer grabbing) so the code to determine the tab
client needs to be a bit more sophisticated and, as a bonus, keyboard
shortcuts to activate the tab under the pointer will work as well =)
|
|
BUG: 1075
|
|
There's a setting about maximization which allows to control whether the
resize increments should be honored when maximizing windows.
This is currently used to control whether maximized windows may resize
themselves via (rare) configure events, but not when maximizing windows
- what's somehow not what the config item sells.
BUG: 914
|
|
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
|
|
|
|
Otherwise the iconbar would be capped when showing more (eg. all instead
of iconified) windows
|
|
Should reduce exposure events, notably since the
windows are not in stack order.
|
|
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.
|
|
Command is "RelabelButton button.foo $LABEL"
This is useful to eg. hint the amount of unread mails in a
button to start your MUA, reflect the $USER in a session menu button
etc.
|
|
With this patch you can add buttons like
*.toolbar.button.foo.label: F
*.toolbar.button.foo.commands: RootMenu:Exec foo
*.toolbar.tools: button.foo, iconbar, ...
button.*.label is mandatory
button.*.commands suppots 5 mouse buttons, but the way
stringtok works, it's required to add a blank
(or some junk) between to colons to skip a button
|
|
required to allow labeled general action
buttons in the toolbar
|
|
|
|
Trying to control a timer bound to an unconditional toggle, caused by
opposing events does not work. <- That's a period.
The toolbar implementation would act too seldom, the slit to often.
Instead, fire the timer whenever the state does not match the event and
bind it to a function that queries the pointer position and acts
accordingly.
|
|
|
|
toggle(Toolbar|Slit)Above toggles the resp. item between its
regular and the AboveDock layer (ie. above everything, even visible on
active fullscreen windows)
Also required step for autoraising.
REQUEST: 222
|
|
Allows to maintain access to desktop fractions etc. against
maximized windows. Also permits to OnToolbar clicks in this case, eg. to
raise it.
REQUEST: 150
|
|
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
|
|
The evenly distributed space causes a lot of whitespace and otoh. cut
items, so we use the items internal size as indicator IF the item is a
textbutton (the regular usecase in fluxbox)
Also publish the function to be triggered from outside (because the
caller can, in theory, much better compress several text changes)
|
|
|
|
Notably shells will cause brief interim titles when calling
short-lived commands (try "ls"...)
This covers such by waiting 100ms after every title update before
reacting (the title will have returned in the mentioned cases, the UI
remains steady)
|
|
so that interested parties (the iconbar ;-) can use/forward them
|
|
This allows to add random spacers, fixed size or stretching, to the toolbar.
CCBUG: 1141
|
|
According to Peter Ganzhorn, there's a transparency issue when using an
autohiding slit, but I don't use a slit at all.
However, the explanations in the bug do make sense and this is just an
alternative approach on the problem (that does not require interim
showing)
BUG: 1132
|
|
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
|
|
a fixed position of the style menu won't help (the menu geometry changes
*because* the item geometries do) - warping the pointer would likely be
possible, but warping the pointer is cc. "evil"
BUG: 715
|
|
Also reconfigure menus (recursively) on style load
The most critical call is the shape update - the menus often become
cut-off, preventing mouse interaction with lower items, but also colors
are not applied correctly to menus w/o updating them.
BUG 1022 is most likely this and only a misinterpretation (for the
mentioned items are those with lacking color updates on style updates)
BUG: 1146
BUG: 1017
CCBUG: 1022
|
|
m_cycling_next can either be WinClient or a FluxboxWindow
In case of the latter, client->fbwindow() needs to be matched in
setFocusedWindow when protecting against client side focus juggling.
BUG: 1148
|
|
|
|
|
|
We've better things to do and the focus is moving around anyway
BUG: 1048
|
|
Latter happens when eg. closing windows, including such with
locked focus
|
|
as cycle start (former is where we wanted to go and X11 is still async)
|
|
applyState also requires some updates implied by moveResize, notably the
reconfigure, the setBackground on the window etcetc.
Instead of testing what'd be missing from a moveResize, we just force
the latter to apply even when seeming unrequired.
This has notable impact when switching fullscreen state for a window
with fullscreen dimensions.
BUG: 992
|
|
This allows to complete random things, useful along the -print flag but
also to limit the commands to those found my menumaker etc.
|
|
While any window can be centered using the apps file, fbrun can serve many
purposes and sometimes (runner) makes sense being centered, sometimes
(button/menu triggered input) near the mouse, sometimes ("application")
regularily placed.
REQUEST: 282
|
|
the default is 1024-1025, values are read from the FBRUN_HISTORY_SIZE
environment variable
NOTICE: the limit isn't hard, but will typically be n+1 and only n if
the new entry is already present in the last n entries
REQUEST: 202
|
