When composite manager (like picom or xcompmgr) is used together with
Window Maker, some of the windows (i.e. terminator) might have
transparent border. This patch will prevent from such situation.
Closes: https://github.com/window-maker/wmaker/issues/58
Currently, when switchpanel is invoked (usually by alt-tab), icons are
taken with the order from higher priority to lower:
* appicon
* user defined icon
* net_icon
* default icon
Using appicon, when no net_icon nor user icon is defined is good,
although it will provide another confusion with user defined icons,
which will be ignored for all apps which provide appicons. With this
patch order of selecting icon for an app is:
* user defined icon
* appicon
* net_icon
* default icon
Note, that even, if there is icon defined for certain application,
usually it need to have "Ignore client supplied icon" checkbox ticked,
especially for the apps like Firefox.
With commit e45a3bc07d a behavior change
was introduced that may disrupt the workflow of a user who may
intentionally want to give focus to a window without bringing it to the
front. Using the scroll wheel is less intrusive compared to the left,
right, and especially the middle (in the case of a terminal) mouse
buttons.
This commit introduces the ability to change the behavior by enabling or
disabling the ability to focus a window with mouse wheel in the expert
panel.
Previous patch has correct the way, how reserved area found in
_NET_WM_STRUT was calculated. Unfortunately, the calculation was not
precise, as for not reserved areas (i.e. values of 0 for one of the
cardinals is set) must be calculated anyway for given head, otherwise
usable area might be too broad.
Applications such a panels or docks have ability for reserving space so
that no windows should cover or overlap them. There is (partially)
support for it by checking the _NET_WM_STRUT property, although
calculation for the reserved space was wrong in case of several heads
enabled.
In this patch calculation for reserved area has been corrected.
In this patch we will fix an issue during compilation on systems, which
have ImageMagick version 7, and slightly more recent version of
compiler. If we define USE_MAGICK with null value, compilation will fail
on preprocessor check on such defined variable.
Simplify handleMaximize function for "not effective" case, where there
was couple of duplicate code, now there is one indentation level less
and readability increased.
Mouse pointer can be now moved together with window if keyboard was used
for arrange maximized windows on screen. This feature can be turned on
in WPrefs.app in Expert tab by selecting "Move mouse pointer with half
MAXIMIZED windows.", or setting "PointerWithHalfMaxWindows" to "Yes" on
~/GNUstep/Defaults/WindowMaker file.
Now it is possible for change a bit pattern for changing state between
half-maximized windows. Half maximized windows will become maximized if
there is issued half-maximizing shortcut in opposite direction. Issue
half-maximizing command on same direction on already maximized window,
will have no effect.
Added new option to Window Maker for enabling alternative way for
half-maximized windows movement. Option can be found on Expert section
in WPrefs app.
Previous bugfix introduced another regression. It fixed the issue with
size of the unmaximized window, but break new functionality. Revert back
code for maximizing using mouse, leaving out head detection for keyboard
actions, since it is already calculated.
Mouse actions for maximize also has to be fixed due to different
behaviour in original implementation - movement of the window which is
called in handleMaximize filter out MAX_KEYBOARD from argument passed to
the wMaximizeWindow, so that it will always assume that all the actions
have to be done on the head where mouse pointer resides. For moving
windows between heads feature, calculated head is always passed and
used, regardless of how maximizing was invoked (keyboard or mouse) and
mouse pointer position.
Using MoveHalfMaximizedWindowsBetweenScreens option user can enable
ability for moving half-maximized windows not only within current
screen/head/display, but also to other heads, if they exists. Note, that
only vertically or horizontally maximized windows can be transfered to
another display. Quarter-maximized windows are not supported, since it
is ambiguous to predict in which direction such window should be moved.
Added new option to Window Maker preferences to enable half-maximized
windows movement on all available heads. Option can be found in WPrefs
app on Expert section.
gryf