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.
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)
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 =)
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
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
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)
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
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
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
and align calculation on init and reconfigure
As a result, if a menu has no label, the title height is determined
only by menu.titleHeight (and the border sizes), not by the unused font.
commit 98313bf broke (i'm terribly sorry) this because m_cycling_last stores
the first client in a tabgroup, thus cannot be abused for this purpose.
So we explicitly store a value and btw. do it before sending the focus,
ie. "in time" for sure instead of "for sure™"
Testing one bug, the function seems usually be called with the root
window as parameter, so we can save a pointless lookup for the root of
the root by testing against window before testing against window_root.
Elegantly, this will "fix" the bug where XGetGeometry of the second
heads root will either report the first heads root or some junk (xephyr
case?)
BUG: 1128
the menu focuses which tries to set the current tab, but fails because
the iconified client won't have the input focus (yet), so we pass it a
dedicated "set this client and do not try to set input because we're
going to do next anyway explicitly" call =)
BUG: 997
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 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 ...)
The depth member of FbWindow was abused to store the maximum depth
but that gets overridden with geometry changes of the root window
(screen layout changes) so we store and read the value explicitly while
::depth() maintains the actual depth of the root window
The result of this is that frames for ARGB windows were created with a
wrong depth and failed to reparent the client window.
BUG: 1102
BUG: 1058
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.
Clients which implement a client-side modality might cause
livelocks by reverting the focus to the transient (after the
WM tried to put it on the leader as the transient's modality
is unknown)
So while cycling we revert the focus whenever it moves somewhere
where we don't expect it.
When done, we also focus the window that should have the focus anyway
to allow the client to redistribute the focus (as we prevented it
during cycling)
Hall of Shame: Softmaker Freeoffice uses (only) client side modality.
Allow setting relative value for x and y or width and height separately in
the apps configuration file. This makes these settings compatible with ones
available in the keys file.
Previous buggy behavior:
If someone has specified, e.g. "[Dimensions] {50% 100}" it was parsed as
"{50% 100%}" not as "{50% 100px}" which was inconsistent with the "keys"
configuration file.
From now on it is possible to write something like this:
[app]
[Position] (RIGHT) {50% 0}
[Dimensions] {300 100%}
[end]
Signed-off-by: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>
A bug sneaked into my implementation of Boyer-Moore-Horspool. This lead
to not finding certain patterns. Given the text 'abcdde' and the pattern
'dd', the faulty implementation would not find 'dd':
1. 'ab' does not match, skip 2 (length of pattern)
2. 'cd' does not match, skip 2 (length of pattern) <- the bug.
3. 'de' does not match, end of string
The bug in step 2 is to not use 'd' to detect how far to skip but to
use 'c' (which is not in the skip-table) and thus 2 bytes are skipped).
Different styles makes the menu width different.
When the original menu width is bigger than the newly selected style's
width, the rendering produces pretty strange effects:
The old style's frame not cleared, so it was rendered and visible next
to the new style edge.
With this change, the menu width will be as wide as the widest menu
item.
Style switching still not perfect, because the height of a menu item is
from the "first" selected menu, also font color are not updated.
We define the value ICONV_NULL = -1, but when we attempt to set the
s_iconv_convs array to all NULL values, we zero the array instead of setting
its entries to -1.
This patch properly initializes and wipes s_iconv_convs.
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.
