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
Max size per client (setMaxSizePerClient) was computed for
iconbar.alignment = Relative not taking into account that a fixed size
can be given when iconbar.alignment = Left/Right.
In a "recent" change, relative alignment was changed, to better handle
items with long titles. This is breaking existing behavior, the new
behavior is (with this commit) now denoted RelativeSmart.
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
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
This commit fixes primarily a race condition that occurs when xinit(1) shuts
down: by not acting properly fluxbox gets caught in an infinite loop. It
caused bug #1100.
xinit(1) sends a SIGHUP signal to all processes. fluxbox tries to shutdown
itself properly by shutting down workspaces and screens. While doing that, the
Xserver might be gone already. Additionally, fluxbox used to restart() itself
on SIGHUP, which is clearly not the right thing to do when xinit(1) is about
to end the session.
So, fluxbox does this:
* handling SIGHUP now shuts down fluxbox without clearing workspaces and
screens.
* A 2 second alarm() is triggered in Fluxbox::shutdown() as a last resort
* XSetIOErrorHandler() is used to recognize the disconnect from the xserver.
* SIGUSR1 is for restarting fluxbox, SIGUSR2 for reloading the config
* FbTk/SignalHandler.cc/hh is gone; this unused abstraction served currently
no real purpose. Signal handling is now done in main.cc
* Unrelated to the issue itself src/main.cc was trimmed down quite a bit and
the code (responsible for handling the command line interface) was moved to
src/cli*
