This patch is adding directional window focus
(like in openbox), where the focus can be passed to
the current window neighboors with a shortcut key.
Comparisons are performed using window centres.
New options are FocusWindowLeftKey, FocusWindowRightKey,
FocusWindowUpKey, FocusWindowDownKey.
Other WM are setting those to SUPER+LEFT/RIGHT/UP/DOWN keys
but currently those are not set by default.
CirculateRaise option which is described in WPrefs as
'Raise window when switching focus with keyboard' is also
used to raise/not raise windows that are fully covered by
other windows.
This patch is treating the _NET_WM_WINDOW_TYPE property as an array
of atoms as defined in X11. Currently, we are only getting the first one,
while the client can set multiple window types ordered from most specific
to least specific.
This patch is adding vim-like window marking, like in i3.
A window can be dynamically assigned a mark label.
Then a marked window can be pulled or jumped to.
Or the current focused window can be swapped with a marked window.
The mark label appears in the Window List in between the window
title and the workspace name.
Those new options in WindowMaker conf file are used to control
the actions: MarkSetKey, MarkUnsetKey, MarkBringKey, MarkJumpKey
and MarkSwapKey.
Those actions are set to None by default.
This patch is preventing X server gravity adjustments from offsetting
the client windows esp when the gravity is non standard as seen
in openoffice with xprop: 'window gravity: Static'.
Also fixing _NET_WM_STATE property query request as in X11 it can
contain multiple atoms simultaneously, acting as an array.
This patch is improving the support for RandR.
It uses version 1.3 released in March 2009.
Most of the support is done in randr.c/randr.h
It is built on top of the mature Xinerama structure
but Xinerama lib is not required.
Like for Xinerama, RandR is now auto enabled if the
library is found at compiled time.
RandR support can be used in 2 modes:
A static mode (which is the default) is to define manually
your setup with external tools like xrandr or arandr,
like for example what Openbox is doing.
A dynamic mode, which is triggered on hotplug events,
like for example what GNOME is doing.
If a new monitor is detected, it will select the best mode
available and add it to the right on the existing monitors.
The mode can be switched with a new option available in WindowMaker
conf file (or via WPrefs expert panel):
HotplugMonitor = NO;
This patch is removing the check for the legacy_minipreview_config struct
which was removed in commit fa8121ee61
Without it we can see the error below when running make check:
Error: structure "legacy_minipreview_config" was not found in ./defaults.c
This patch is fixing the wire frame dimension which
was computed wrongly when FrameBorderWidth was set
and the window snapped top half or bottom half.
In such case, drawTransparentFrame was passed the
width and height of the screen while it should have
used an inner frame size (meaning without frame border).
The result bug was that the wire frame width was too large
and the right edge displayed out of the monitor head.
This patch is setting the _NET_WM_PID atom for WPrefs
to report its PID.
Before the patch, the PID reported is unset (0)
$ wmctrl -lp|grep 'Window Maker Preferences'
0x00a000b0 0 0 Linux Window Maker Preferences
After the patch, the PID is set (20110 in the example below)
0x00a000b0 0 20110 Linux Window Maker Preference
This patch is checking if the session saved window positions fall
in dead space, for example when a monitor no longer exists.
If it's the case the window position is moved to the nearest active
head.
This patch is a follow up of commit
073235ada4
as it appears there is the same issue with the WMState
configuration file when a session state is saved.
For example, with terminator, the file will contain:
...
Applications = (
{
Dock = Dock;
Maximized = 0x0000;
Name = terminator.;
...
After the patch:
...
Applications = (
{
Dock = Dock;
Maximized = 0x0000;
Name = terminator.Terminator;
...
The patch with commit 839061a25a
introduces an issue with dockapps that are creating their main
windows with size 1x1. That new patch is moving the existing
code further below in the wManageWindow function to be able
to check if the window flag is_dockapp is set.
Issue was seen with wmsystemtray and wmmemload.
This patch is adding a new option ScreenshotFilenameTemplate for users
to change the default strftime format "screenshot_%Y-%m-%d_at_%H:%M:%S".
For example, Teams is not allowing the ':' char in the filename of file
to be shared so I always have to rename the file.
This patch is replacing the modelock legacy hardcoded language dropdown
icons with a compact titlebar button based on the current locale.
(it adds also a detection to xkbfile library which is required to get
the short name of the locale).
Now supports up to 4 layouts, clicking on the language button will cycle
through them (XKB officially supports up to four groups).
This patch extends the existing keybindings to support multiple keys and
add an optional "sticky chain" mode that lets a prefix remain active until users press
a cancel key so users can enter the continuation key without re-pressing the prefix.
The idea is to bring Emacs shortcuts keybinding to wmaker.
Normal (existing and enhanced) mode:
Prefix behaves like a one-shot release before the next key if any.
For example: Mod1+h -> hide the active application, that is still working as usual.
But if you want for example to have all your window management keys under the same leader key
you can now do something like that:
"Mod4+w h" which is pressing the Super key with w, releasing them and pressing h.
You can assign that key sequence to an action.
Sticky chain mode:
Pressing a configured prefix enters a short-lived sticky state.
Sticky state expires on timeout or when explicitly canceled (with KeychainCancelKey).
For example, you can define:
"Mod4+a x" -> run xterm
"Mod4+a b f" -> run firefox
"Mod4+a b c" -> run google chrome
In sticky mode, "Mod4+a x x b f", then KeychainCancelKey or KeychainTimeoutDelay, will launch 2 xterm and firefox.
New options for WindowMaker conf file:
KeychainTimeoutDelay: timeout in milliseconds (can be set to 0)
Default: 500
Example: KeychainTimeoutDelay = 500;
KeychainCancelKey: explicit keybinding used to cancel an active sticky chain.
If set to None the feature has no dedicated cancel key and the chain only ends by timeout
or naturally if the keybind pressed is not defined.
Default: None
Example: KeychainCancelKey = Escape;
This patch is checking if the notification wmaker is receiving
from the Defaults directory is coming from a proper expected config file.
Until now, using vim for example to open any of the files,
for example WMRootMenu would reload the configs, even before saving
the file.
You would see in the logs:
warning: Inotify: Reading config files in defaults database.
because vim by default is creating a .swp file in that same directory.
This patch is adding a new ModifierKeyShortLabels option to the
WindowMaker file to let the user specify the modifier key labels
used in the shortcuts like those appearing in the root menu.
For example, to overwrite the default labels, a user can set
the new option value to:
ModifierKeyShortLabels = (
"\342\207\247",
"\342\214\203",
"\342\214\245",
"\342\207\255",
"\342\207\263",
"\342\214\230",
"\342\207\252",
"\342\227\206",
"\342\214\245"
);
Which is using the same symbols as defined in macos.
For example, instead of printing M4+, "\342\214\230"
will print the ⌘ (Command) symbol.
This patch is setting a proper class hint internally
when the app is not setting any.
That issue can be reproduced with terminator 2.1.3,
where the window itself is setting a proper WM_CLASS
$ xprop|grep WM_CLASS
WM_CLASS(STRING) = "terminator", "Terminator
But the window id # of group leader: 0x1000001
is setting only the instance name not the class name.
$ xprop -id 0x1000001|grep CLASS
WM_CLASS(STRING) = "terminator", ""
The issue is that wmaker is using those 2 string values
for the dock apps and to identify linked launched apps.
Those strings are concatenated and used in WMWindowAttributes.
Without the patch, that entry below is created:
terminator. = {
Icon = terminator..xpm;
};
If wmaker is warm restarted, a new entry appears in WMWindowAttributes:
terminator. = {
Icon = terminator..xpm;
};
terminator = {
Icon = terminator..xpm;
};
and the opened window is not linked anymore to the dock app as the
WM_CLASS is different.
So you can launch the app as many times as you want from the dock,
the dock icon will
always have the 3 dots on the bottom left corner showing no window
apps are linked to it.
In case if the group window is not defining a CLASS but the client window
has one, the patch is setting the group window CLASS to the value of the
client window CLASS, or as a fallback, as seen in PropGetWMClass function,
setting it to "default".
With the patch, in WMWindowAttributes, we have now:
terminator.Terminator = {
Icon = terminator.Terminator.xpm;
};
and a warm restart is not creating another entry.
This patch is checking if the passed Drawable exists before calling
XGetGeometry on it, as seen when using Steam and trying to change
the attributes of the 'Friends & Chat' popup window, wmaker is
generating such error in the logs:
warning: internal X error: BadDrawable (invalid Pixmap or Window parameter)
Request code: 14 X_GetGeometry
Request minor code: 0
Resource ID: 0x0
Error serial: 32091
As mentioned in commit 67e2f5e1ca,
for TrueColor display it's not necessary to allocate a color but
it is required to set the pixel property of the XColor.
This patch is adding keyboard control to the wlist widget
(up/down/pgup/pgdw/home/end) and typeahead list search.
That component is for example used in the wmaker icon chooser,
and WPrefs keyboard shortcut, font conf panels.
This patch is fixing memory leaks when pango structures are used
but not freed.
Also according to commit 4f050ebab9,
previous_text string in WMWidthOfString can be not NULL terminated,
the same construct is used in WMDrawString and WMDrawImageString
functions, so to be safe better to also check for the length
of the string.
This patch is fixing a possible memory corruption and abnormal exit
of wmaker when a created child process errored.
This had been kind of mentioned at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040643
and I also experienced it with especially Steam.
At first, I also thought it was a crash or a memory corruption,
but gdb or valgrind are not reporting anything.
In fact, Steam is not setting properly some hints and that is bringing
some issues. More patches will be needed to support that app properly.
For example, WM_COMMAND is not set properly and when you are trying to
relaunch the app from the appIcon the child process is generating an error
and the actual code is calling Exit(-1) which is entirely exiting wmaker,
that's why from gdb you can see the message
[Inferior 4 (process 567278) exited normally] and no crash.
This patch is fixing a window focus issue by ignoring mouse wheel
up/down buttons. How to reproduce the issue:
open 2 xterm with one window overlapping the other, in 1 xterm list
files with ls to have the scrollbar to appear, click the other xterm
to give focus to its window, now mouse wheel up or down on the other
xterm, at that point the window is focused but under the other xterm.
Try to click left button to get it to appear on top, it will not work
cause the focus is set already on it. With that patch the click to
focus is working.
This patch is treating empty _NET_WM_ICON_NAME as unset,
thus the code is falling back to set the appicon title
to the window title. Case seen with virtualbox where
the _NET_WM_ICON_NAME(UTF8_STRING) is set to empty string.
This patch is conditionaly adding some extra room in the window
inspector advanced options frame if modelock is enabled to fit
the extra option. Without it the option text is truncated.
This patch is adding the app icon in between the flags icon and
the window name from the window list.
Feature request from https://github.com/window-maker/wmaker/issues/19
It is disabled by default, it needs WindowListAppIcons to be
set to YES manually in the conf file or "Show app icons in window list."
enabled from WPrefs expert panel.
This patch is making sure the icons shown in the switchpanel
are also those used for the appicon. For example, for xterm
the icon used in the switchpanel is the default app and not the
icon provided by xterm app.
Seems that issue is also present in vanilla wmaker 0.96.
This patch is fixing 2 issues with the modelock language pixmap
located in the titlebar.
If wmaker is compiled with modelock support but modelock is disabled
from the expert preferences, dialog windows like run command or exit
will not show the language pixmap but will show empty frame borders.
When modelock is enabled from the expert preferences, it needs a
warm restart for the titlebars to be updated with the language pixmap.
If afterwards, modelock is disabled from the expert preferences,
any old windows that is gettting focus will be repainted and the language
pixmap will be destroyed but the empty frame borders will still be
present. Now to fully disable modelock for existing opened windows,
wmaker needs a warm restart.
This patch is fixing some initial window position issues
as seen for example with virtualbox.
Now wmaker is not trying to manage the 1x1 app internal windows
which was resulting on some position issues (stacking the window
app on the left side).
It also fixes some window jitters issues when the app is trying
to negotiate some tiny position adjustments.
Related to bug at https://github.com/window-maker/wmaker/issues/26
This patch is factorizing is_same and getBool functions in misc.
is_same is renamed to WMStrEqual
getBool is renamed to WMPLGetBool
to prevent name collision issues.
This patch is to fix an issue seen on FreeBSD 15 where
keybinding are mixed up at the cold start of wmaker.
It is mentioned at https://github.com/window-maker/wmaker/issues/43
Seems that issue is not happening on Linux.
A warm restart ("restart window maker") from the root menu
is getting rid of that issue temporarily.
To solve that issue, now wmaker is reloading the keyboard mapping
via the new wReadKeybindings function when a XkbNewKeyboardNotifyMask
event is received.
It means xkb, which is part of X11 core,
is now used by default and not conditionally with modelock.
I tried to delay reading the keybinding as late as possible but
it did not solve the issue as seems X is started with a improper
keyboard by default.
Here some debug trace when the bindings are loaded by wmaker on FreeBSD:
Keybind F12: keycode=96 modifier=0x0 <--- cold starting wmaker
Keybind F11: keycode=95 modifier=0x0
Keybind Escape: keycode=9 modifier=0x4
Keybind M: keycode=58 modifier=0x8
Keybind H: keycode=43 modifier=0x8
Keybind Up: keycode=98 modifier=0x8 <--- keycode is wrong, provided by X11
Keybind Down: keycode=104 modifier=0x8
Keybind Tab: keycode=23 modifier=0x8
Keybind Tab: keycode=23 modifier=0x9
Keybind Right: keycode=102 modifier=0xc
Keybind Left: keycode=100 modifier=0xc
Keybind 1: keycode=10 modifier=0x8
Keybind 2: keycode=11 modifier=0x8
Keybind 3: keycode=12 modifier=0x8
Keybind 4: keycode=13 modifier=0x8
Keybind 5: keycode=14 modifier=0x8
Keybind 6: keycode=15 modifier=0x8
Keybind 7: keycode=16 modifier=0x8
Keybind 8: keycode=17 modifier=0x8
Keybind 9: keycode=18 modifier=0x8
Keybind 0: keycode=19 modifier=0x8
Keybind Print: keycode=111 modifier=0x0 <--- keycode is wrong, 111 is UP key
/usr/ports/x11-wm/windowmaker/work/WindowMaker-0.96.0/src/.libs/wmaker(execInitScript(main.c:531)):
error: /root/GNUstep/Library/WindowMaker/autostart:could not execute initialization script <--- warm restart from wmaker
Keybind F12: keycode=96 modifier=0x0
Keybind F11: keycode=95 modifier=0x0
Keybind Escape: keycode=9 modifier=0x4
Keybind M: keycode=58 modifier=0x8
Keybind H: keycode=43 modifier=0x8
Keybind Up: keycode=111 modifier=0x8 <--- UP key keycode is correct
Keybind Down: keycode=116 modifier=0x8
Keybind Tab: keycode=23 modifier=0x8
Keybind Tab: keycode=23 modifier=0x9
Keybind Right: keycode=114 modifier=0xc
Keybind Left: keycode=113 modifier=0xc
Keybind 1: keycode=10 modifier=0x8
Keybind 2: keycode=11 modifier=0x8
Keybind 3: keycode=12 modifier=0x8
Keybind 4: keycode=13 modifier=0x8
Keybind 5: keycode=14 modifier=0x8
Keybind 6: keycode=15 modifier=0x8
Keybind 7: keycode=16 modifier=0x8
Keybind 8: keycode=17 modifier=0x8
Keybind 9: keycode=18 modifier=0x8
Keybind 0: keycode=19 modifier=0x8
Keybind Print: keycode=107 modifier=0x0 <--- Print keycode is correct
Alternatively, to mitigate the issue, .xinitrc can be set to:
setxkbmap -layout us
exec wmaker
or whatever layout you are using.
This patch is fixing some text truncation especially
for displaying the total memory allocated in debug mode
and the image formats (when the JXL support is enabled).
This patch is fixing a compiler warning for the implicit
conversion of int to char changes value from 255 to -1
when at the line *ptr++ = 255 the code is trying to store
the value 255 into a char.
This patch is improving the alpha combine function by using int
instead of float. That function is used for example in the
switch panel to merge the transparency mask.
The change is practically indistinguishable to the human eye
for a single-pass blend but the performance gained is huge.
I've been doing some benchmark of wrlib and even implemented AVX2 support.
But the gain compared to the complexity of AVX2 is not worth,
while having int usage in that specific function is a really good trade-off.
Here the result:
Alpha Blending Performance Test
Image size: 1024x768 (786432 pixels)
Iterations: 100
AVX2 support: YES
=== RGBA Source Test ===
Original (float): 2.540 ms/frame (393.8 FPS)
Optimized (int): 1.983 ms/frame (504.2 FPS) [1.3x speedup]
AVX2 optimized: 1.843 ms/frame (542.6 FPS) [1.4x speedup]
By using int, the alpha blending in that use case is 28% faster.
This patch is implementing a new default Catmull-Rom filter
to resize images.
Catmull-Rom is a special case of cubic interpolation with B=0 and
C=0.5 (in the Mitchell-Netravali formulation).
It provides slighlty sharper results than Mitchell with the same
performance.
Catmull-Rom is a better choice for a window manager as it prioritizes
sharpness, making small elements feel crisp.
This patch is fixing some issues in how right and center aligned
wtextfields are handled.
-text selection with mouse was not working properly especially
setting and identifying the cursor position
-middle button paste was only working for left aligned text
xterm is not working properly (it's not advertising its internal icon)
if the window manager's name contains a space, seems to be specific
to xterm as xeyes and xpaint are working fine.
This patch is allowing to control the wpopupbutton entries
via keyboard up/down arrows.
It happens to me a few weeks ago during development,
wmaker crashed and I lost the mouse control.
I was stuck on that dialog box without a way to select another entry.
According to EWMH specification, the active window manager is supposed
to set some information. Those can be gathered for example with
'wmctrl -m'.
Before the patch:
$ wmctrl -m
Name: N/A
Class: N/A
PID: N/A
Window manager's "showing the desktop" mode: OFF
After the patch:
$ wmctrl -m
Name: Window Maker 0.96.0
Class: wmaker
PID: 6866
Window manager's "showing the desktop" mode: OFF
This patch adds an option to enable native CPU optimizations
by adding -march=native to the compiler flags, tuning the
generated code for the build machine at the expense of portability.
In some tests, especially on wrlib I saw 8% perf improvement.
Should be used by developers or those who recompile wmaker for their own usage.
This patch is fixing the issue reported
at https://github.com/window-maker/wmaker/issues/62
where wmaker is crashing if the font specified in WMGLOBAL is not found.
Now by default it will failsafe to DEFAULT_FONT.
The cursor is moved using right/left arrows but as it's blinking
and a XOR function is used to hide/unhide it, it happens the cursor
can be not hidden properly from its previous position.
Better to refresh the view to avoid such issues.
In case the cursor is positioned out of the textfield view
after a delete and more chars are entered, wmaker process
will reach 100% and become unresponsive.
How to reproduce:
in the run command window enter an overly long text (longer than
the current input field view). Then, press home to go back to the
beginning of the string. Then, shift-End to select all the text,
then del to delete all the text. At that point the cursor is still
out of the view and if you enter more text wmaker process will be stuck.
According to the ICCCM, a reply to a TARGETS request must be a list of atoms.
Took the chance to also fix variable naming consistency between wtext and
wtextfield which are using the same kind of code.
This patch adds optional support for compressed files and a new --ignore-unknown option
to ignore unknown image format. It also adds local filename drag-and-drop support.
And a copy current image to clipboard feature with ctrl+c shortcut.
It also fixes:
- fullscreen issue on multi monitors setup by using randr
- app icon advertised via _NET_WM_ICON
- fix UTF-8 filename usage in window title
The patch is fixing a UTF-8 truncation issue that could happen with the window title
when it was shrinked to be displayed in the window list (F11), leading to
an infinite loop.
Issue was reported at https://github.com/window-maker/wmaker/issues/61
Mentioned on the WMaker user mailing list, option disabled by default.
https://groups.google.com/g/wmaker-user/c/pR8P-ZYCDFo/m/Wo42U_xqBgAJ
So basically the patch is adding a new expert option in WPrefs (disabled by
default) to allow the switch panel to cycle over all the windows from all
workspaces. I believe it's useful if you are using a lot of fullscreen apps
each on different workspaces.
When pango is enabled and a window title contains UTF-8 chars,
there is a chance the miniaturized icon title will cut in 2 an UTF-8 char
leading to a glitch in the title.
As mentioned on the WMaker user mailing list some time ago
https://groups.google.com/g/wmaker-user/c/95M_pb_Qlbs/m/6qJLJSqoAwAJ
The Ignore client supplied icon from the windows attributes is not working.
That's especially visible with firefox and thunderbird when they are using
NET_WM_ICON to push the embedded icon.
That patch is making sure to ignore the embedded icon if the user defined one.
As reported in bug https://github.com/window-maker/wmaker/issues/50
X11 XAllocColor() call from wGetColorForColormap() in src/resources.c is returning some errors
especially seen when running GZDoom.
TrueColor display has been the dominant standard for well over a decade, meaning almost all modern X servers default to a TrueColor visual.
The default colormap is predefined and read-only, making allocation with XAllocColor() unnecessary (and meaning no need to free it too).
The patch is checking the display visual, and in case the display is truecolor, it does not allocate or free the color, just looking up for it.
Once the patch applied, GZDoom is not reporting warnings anymore.
As reported in bug https://github.com/window-maker/wmaker/issues/34
when RandR is enabled, everytime a monitor is turned on or off wmaker is restarting
(that happens either manually or automatically with DPMS).
This behavior causes issues with xscreensaver.
How to reproduce the issue:
-install xscreensaver and lock the screen
-turn off then on the monitor manually
-you can see that wmaker was restarted and behind the xscreensaver lock window,
the desktop appears, potentially leaking information
Instead of using the RandR event RRScreenChangeNotifyMask which is too generic,
the patch is using RRCrtcChangeNotifyMask defined since RandR 1.2 (released in 2007).
In the recent RandR version, events for output (hardware) changes are propagated via
RROutputChangeNotifyMask while layout changes (like position, size, rotation)
are propagated via RRCrtcChangeNotifyMask.
The patch is purposedly not listening for RROutputChangeNotifyMask,
thus wmaker is not restarting on DPMS events anymore.
Currently, in case a new monitor is added (or removed) wmaker is not discovering it anyway
even after an automatic restart.
Either, wmaker has to be exited and restarted fully or an external tool like arandr
has to be used to configure the new monitor. So after the patch functionality remains unchanged.
autogen.sh is reporting some warnings as below
./autogen.sh 2>&1 |grep "obsolete"
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:115: warning: The macro `AC_LANG_C' is obsolete.
configure.ac:115: warning: The macro `AC_TRY_COMPILE' is obsolete.
configure.ac:134: warning: The macro `AC_LANG_C' is obsolete.
configure.ac:134: warning: The macro `AC_TRY_COMPILE' is obsolete.
configure.ac:135: warning: The macro `AC_LANG_C' is obsolete.
configure.ac:135: warning: The macro `AC_TRY_COMPILE' is obsolete.
configure.ac:146: warning: The macro `AC_LANG_C' is obsolete.
configure.ac:146: warning: The macro `AC_TRY_COMPILE' is obsolete.
configure.ac:146: warning: The macro `AC_LANG_C' is obsolete.
configure.ac:146: warning: The macro `AC_TRY_COMPILE' is obsolete.
configure.ac:373: warning: The macro `AC_LANG_C' is obsolete.
configure.ac:373: warning: The macro `AC_TRY_COMPILE' is obsolete.
configure.ac:458: warning: The macro `AC_HEADER_TIME' is obsolete.
configure.ac:681: warning: The macro `AC_TRY_LINK' is obsolete.
configure.ac:807: warning: The macro `AC_TRY_LINK' is obsolete.
As the minimum autoconf version required is v2.69,
we need to make sure to update obsolete macros as described at
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Obsolete-Macros.html
Just a cosmetic change as the variable is currently not in use.
According to the Motif Toolkit API and MwmUtil.h, the last long
variable from the Motif WM Hints struct is currenlty used
for the status.
This patch adds a new Central feature under the window menu
"Other maximization" entry.
Shortcut can be configured via WPrefs "Center active window" action.
When called the active window is centered on the screen head.
If the window height or width are bigger than the head size,
the window is resized to fit.
There are some transitions defined as below:
*from fullscreen to center
*from any corner to center
*from top half to center top half
*from bottom half to center bottom half
*from left half to center left half
*from right half to center right half
Undoing the action is done via the window menu "Unmaximize" entry
or the shortcut.
Add mouse pointer position detection to trigger the corner actions.
Screen corners can be assigned an external command to be
executed when the mouse pointer is entering those areas.
In WPrefs, "Hot Corner Shortcut Preferences" can be used
for configuration or by manually adding a "HotCorners" key
and value to "YES" in the ~/GNUstep/Defaults/WindowMaker file.
Actions are specified by the "HotCornerActions" and are defined
as a four entries list ("top left action", "top right action",
"bottom left action", "bottom right action").
A screen corner area is a cube shape defined by the "HotCornerEdge"
which is a number of pixels from 2 (by default) to 10.
To lower the risk of triggering that feature accidentally a
"HotCornerDelay" key can be used which is the time before the action
is triggered while the pointer is in one of the screen corner.
Default value is 250 ms.
Hot Corners feature is disabled by default.
That patch is fixing some Actions entries that are not sorted properly.
One is using some upper/lower cases.
And the other one, is displaying numbers while alphabetic sorting is not
working properly on numbers. For example:
Shortcut for window 1
Shortcut for window 10
Shortcut for window 2
...
As discussed on the ML, the test to check for CARD16 limit is probably innacurate.
Check instead for maxH and maxW which are set by default to twice the size
of the screen or to the max values passed by the window normal hints property.
According to ICCM specs at [1]
*Not changing the size, location, border width, or stacking order of the window at all.
A client will receive a synthetic ConfigureNotify event that describes the (unchanged)
geometry of the window. The (x,y) coordinates will be in the root coordinate system,
adjusted for the border width the client requested, irrespective of any reparenting
that has taken place. The border_width will be the border width the client requested.
The client will not receive a real ConfigureNotify event because no change has actually
taken place.
*Moving or restacking the window without resizing it or changing its border width.
A client will receive a synthetic ConfigureNotify event following the change that
describes the new geometry of the window. The event's (x,y) coordinates will be in
the root coordinate system adjusted for the border width the client requested.
The border_width will be the border width the client requested. The client may not
receive a real ConfigureNotify event that describes this change because the window
manager may have reparented the top-level window. If the client does receive a
real event, the synthetic event will follow the real one.
*Resizing the window or changing its border width
(regardless of whether the window was also moved or restacked).
A client that has selected for StructureNotify events will receive a real
ConfigureNotify event.
Note that the coordinates in this event are relative to the parent,
which may not be the root if the window has been reparented. The coordinates will
reflect the actual border width of the window (which the window manager may have
changed). The TranslateCoordinates request can be used to convert the coordinates
if required.
In Window Maker, the first case is not implemented: doing a synthetic ConfigureNotify
to notify no changes were done. That's creating some issues with app like Citrix icaclient
when sometime windows are blank and need to be moved to be refreshed.
[1]https://x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html#configuring_the_window
Align the old maximization descriptions to the new visual indicator
names. The internal shortcut names had also been updated, meaning a
reconfiguration of the shortcuts in WPrefs is required.
Since 48d4820dee the dock is positioned
dynamically based on the screen midpoint.
The side issue using such method is if in case the screen was temporarily
resized the dock as a chance to be displayed on the other side making
the drawer saved configuration from WMState esp the direction wrong when
wm is started again.
For example, the dock and drawer are displayed on the right of the screen.
Then the screen resolution is downsized temporaily to half or less of
the previous size. The position stored in WMState will be updated and the
direction of the drawer is still opening on the left.
But on next wm start, when reading the conf.
The position of the dock and drawer are corresponding to the
middle or less of the unresized screen. The dock and drawer will be sticked
on the left. But the drawer direction was not updated and still opening
on the left (which is out of the screen).
When that option is on, swapping drawer does not always mean
swapping drawer direction. For example if drawer is on the left
side of the second head and moving to the left side of the first head,
the direction should be the same.
Commit 6e2075f3df from 2020 added
a feature to maximize window when double clicking on the titlebar.
But unmaximizing is not supported so when double clicking again
on the window titlebar the window geometry was not reverted back.
When the workspace pager is displayed it's showing grey mini workspaces
for non rendered/non visited workspaces. That patch is adding an exclamation
mark in the middle of the dummy grey background mini workspaces.
According to the EWMH specs, windows can indicate that they are
non-resizable by setting minheight = maxheight and minwidth = maxwidth
in the ICCCM WM_NORMAL_HINTS property. That should be for example
the case for WPrefs app which is not resizable.
Window Maker currently is overwriting that flag in src/window.c for
apps that are exposing GNUstepHints instead.
This patch is making sure the apps created with WINGs is removing
the WMResizableWindowMask to hide the resizebar.
For some apps the background is not displayed properly, showing
some kind of shawow around the app icon like for example firefox
or skype. This is due to an issue in combining alpha channels.