Age | Commit message (Collapse) | Author | Files | Lines |
|
Signed-off-by: Petr Vorel <pvorel@suse.cz>
|
|
Otherwise implicit focus changes by the workspace change would be
perceived as focus stealing and the focus restored to the last window on
the original desktop
|
|
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()
|
|
whenever dealing with unsigned, there's better no "-" in the line ...
|
|
This is notably an issue if the focused font differs from the unfocused
font (eg. is bold or bigger)
Updating the value with the state leads to ugly judder (nasty when minimizing
a window through the iconbar) and not handling this causes random button
widths (depending on whether the button was focused when checking the value)
|
|
Ein Schrumpffreibetrag, faktisch schon Kommunismus ;-)
When short on space, items would be squeezed evenly, but this can turn
"a" and "a very long item with useless information text" into
"a very long item" and "", so in a pre-pass we check whether some very
large items cause the shortage and preferably squeeze them.
|
|
typically buttons will call for this quite some, eg. when switching
workspace or (now) when altering the focused window. This compresses
various changes happening at the same time and re-layout the toolbar
only once for them
|
|
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
|
|
On the run, make it raise on left-clicks (like the toolbar)
The enum already existed ;-)
REQUEST: 113
|
|
... actions in keys.
This allows to override the default behavior as well as adding actions
for the mouse wheel.
Special casing of the two "geometry" related buttons (eg. to perform
smart maximization, reverse the partial maximzation, add shading to the
min button or whatnot)
All other buttons have a rather dedicated meaning and are only really
interesting for adding mouse wheels or eg. the window menu on rmb
clicks.
Needs docu.
|
|
latter protected only.
|
|
The fixes a permanent (sync) button grab.
Well, oversaw global buttonpresses.
Let's wait for more to come ;-)
|
|
passing the "make_fit" parameter isn't sufficient to ignore constraints
|
|
|
|
|
|
We have a nifty counter-based grab, so use it
|
|
|
|
Operate on inverse iscntrl check which allows us to avoid wide character
conversions.
|
|
|
|
aka "Flüxbøx"
βµγ, pardon,
BUG: 720
|
|
REQUEST: 185
also PATCH 92
|
|
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
|
|
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
|