| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
|
|
|
- streamline code
- indicate completion by making use of selection
- fix buggy behavior (notably subsequent completions and FS path
following)
- support "~" in paths
- support chunk completion
(ie. "mp[layer] ~/vid[eos/favporn.mp4]" can be completed in both
tokens; buggy with paths including spaces in non-leafs)
REQUEST: 223
|
|
Entering upcase chars would auto-select them
Seems I don't need upcase chars very often ;-)
|
|
of man 1 fluxbox.
BUG: 950
|
|
still works with bash or zsh, but fish (now) complains about "cat << EOF" ...
no "grep -q"
BUG: 961
echo is troublesome
POSIX doesn't know a "local" keyword
BUG: 975
seems double comments ## aren't supported everywhere
BUG: 1057
|
|
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 reverts commit 4f4d5e25d9a0cf1fc4c0d1a8b7777a560494b7a4.
The patch resolved a problem introduced by the ::setDepth abuse in
FbRootWindow, but this fails if the root window is *really* 32bit
With commit dcdde4d, the broken workaround depth selection is no longer
required.
BUG: 1093
|
|
BUG: 1092
|
|
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™"
|
|
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
|
|
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
|
|
since fluxbox is a f**** WM it should be able to use f**** NETWM hints
in its toolkit ;-)
CCBUG: 702
(does not fix input)
|
|
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 ...)
|
|
CCBUG: 1133
|
|
|
|
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.
|
|
the mouse is likely the trigger, so the popup would cover the
trigger item.
The present behavior of the iconbar suggests such behavior is
desired.
|
|
for a std::string::size_type, the right value to use is not "-1", but
std::string::npos.
|
|
uninitialized variables cause all kind of problems.
|
|
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.
|
|
|
|
in *BSD, /bin/sh is Almquist Shell(ash). the 'hash' built-in command of ash
returns 0, always. 'hash' is not usable for find_it() function in
util/fbsetbg and util/fluxbox-generate_menu.in.
this patch changes the behavior of find_it(): when 'hash' is detected to
not work correctly, switch back to 'which'.
this patch is the work of Yamashiro, Jun and appeared first as patch-160
on sourceforge: https://sourceforge.net/p/fluxbox/patches/160/. i submit
it on behalf of the author.
|
|
Fixes menus more than 1 column wide (such as the Placement menus for
the Toolbar/Slit/Tabs) which stopped working with commit 3e4570b.
|
|
|
|
FbTk::TextBox now acts like any contemporary input field ;-)
|
|
so far, transients are simply unplaced, resulting in a static
0,0 position.
|
|
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>
|
|
|
|
|
|
|
|
|
