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
Adds (secret) opaque resize mode. It sure would be nice if it was documented....
The relevant init file resources and their default values are:
session.screen0.opaqueResize: False
session.screen0.opaqueResizeDelay: 40
Improve switching between 12H and 24H in Clock Tool
configuration
Having:
session.screen0.strftimeFormat: %d-%m-%y %02k:%M
The switch[1] between 12H and 24H did not work due to the digits (02).
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.
Some applications supply -1 in base_width / base_height. One example is
the Preferences dialog of pcmanfm-qt:
WM_NORMAL_HINTS(WM_SIZE_HINTS):
...
program specified base size: -1 by -1
Without this commit the program will crash due to overflow of unsigned int.
This way it is only parsed once in the constructor. Updating the
TrayWindow order is now a method which is called once when the icon is
created.
sortClients/rearrange is now only called on adding and removing icons.
The user options screenname.systray.pinLeft and
screenname.systray.pinRight in .fluxbox/init are read as comma sperated
list of window classnames.
While preserving the order of the lists, systray icons are sorted so
that pinLeft'ed classnames appear left and vice versa.
This fixes:
src/FbTk/XftFontImp.cc: In member function ‘virtual bool FbTk::XftFontImp::load(const string&)’:
src/FbTk/XftFontImp.cc:81:53: error: no matching function for call to ‘max(unsigned int, int)’
changes the selection's deselection mechanism for oversized (e.g
larger than window width) text
new behaviour ensures the maximum selection width remains whilst
the selection length is 'oversized'. only when the selection length
has a width less than the window width will the selection (i.e. the
highlight / inverted colours) reduce in size
this is in contrast to the existing approach which would immediately
decrease an oversized selection down to nothing visually, leaving
the remainder of the selection 'off screen'. this 'looks like nothing
is selected' when in fact it is, gives a poor UX
Don't evaluate trusted variables in *ExportCmd::parse as they will be
always false for SetEnv, Export and SetResourceValue and never executed
via fluxbox-remote.
In 393ba45f91 added the possibility to
add custom buttons to the toolbar. However, if the toolbar is rotated
the buttons stays horizontal.
Update the button to rotate the text and update the width/height of the
button if rotated
'Vertical' Workspace warping is a variant of the existing Workspace
warping feature: When a user drags a window to the edge of the Screen,
the window is warped to the next / previous workspace.
'Vertical' Workspace warping detects a drag towards the upper / lower
border of the screen and warps the current workspace about an 'offset'.
Example given, lets say the user has 9 workspaces and considers them to
form a 3x3 grid:
+-+-+-+
|1|2|3|
+-+-+-+
|4|5|6|
+-+-+-+
|7|8|9|
+-+-+-+
An 'offset' of 3 warps from workspaces 2 to workspace 5 (or 8), when a
window is dragged to the bottom / top border.
New configuration ressources:
session.screenN.workspacewarpingvertical: true
session.screenN.workspacewarpingverticaloffset: X
