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 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.
Revert patches that moved variables from WMScreen to global level
because this broke X displays with multiple independent screens and
caused dock and clip icons to become mixed up. When managing multiple
screens each screen used to have it's own state/dock and clip. This
commit restores that by reverting mainly the commits listed below (and
those that are invalidated by reverting these) and fixing up later
commits to apply after the revert.
Reverted commits:
f60e65001b Moved 'workspace_name_font' from the Screen to a Workspace object in the global namespace
9e103a46e9 Variable workspace_count moved to the workspace object in the global namespace
e5ae684d02 Variable last_workspace moved to workspace object in global namespace
c610b8d7ce Variable current_workspace moved to workspace object in global namespace
f0c5073600 Array of workspaces moved to the workspace object in the global namespace
9c252988f8 Variable workspace_menu moved to workspace object in global namespace
e86b8dcb2f Clip, Dock and Drawers menu moved to appropriate global namespace
074092f319 Removed WScreen args not used
4a7daf2322 AppIcon list moved out of WScreen
2103fe390b Variable clip_icon moved to clip object in the global namespace
014bc52531 wClipIconPaint appicon argument removed
40e1ea08b8 Varible session_state moved to global namespace
6987d4aa40 Removed WScreen argument
0de3e590ce shortcutWindows moved to w_global
2e64831fb6 Removed unused variable wapp_list
b6423a7b4f wmaker: Moved variable Screen Count into the global namespace
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
The function get_default_image_path has the WScreen argument that
is not used, so can be removed.
The function could be static, but perhaps is interesting leave it
as public.
The function get_default_icon_filename(), now get_icon_filename(),
was working in a bad way. Before this patch, the function always
searched the default icon in the second search:
- file_name = wDefaultGetIconFile(winstance, wclass, True);
+ file_name = wDefaultGetIconFile(winstance, wclass, False);
For this reason, the argument default_icon didn't work.
This patch change it. Now, if the default_icon is false, the function
can return NULL, then other functions can do the correct work. For
example, now wDefaultGetImage() doesn't need do nothing, because the
default_icon is set to True. get_icon_filename() checks if the
icon exists in the disk before returning it (except for default icon
in get_default_image_path(scr).
There is a bug in wmaker with icon files set in config files, but
that doesn't exist in the disk. For example, if the config files have:
etc/WindowMaker/WMWindowAttributes:
xcalc = {AlwaysUserIcon = Yes;Icon = "HP-16C-48.xpm";};
share/WindowMaker/IconSets/Default.iconset:
xcalc = {AlwaysUserIcon = Yes;Icon = "HP-16C-48.xpm";};
But the icon "HP-16C-48.xpm" doesn't exist in the disk, wmaker does:
1. Load the config file in memory, in a database
2. When the application is launched, wmaker tries to find their icon in
the database (using wDefaultGetIconFile), the icon is found: HP-16C-48.xpm
3. When WindowMaker try to find the full path for the icon, using FindImage(),
WindowMaker cannot find the icon, and returns NULL.
Even, if the user set the default_icon boolean variable to True, wmaker
finds in the database the wrong icon.
This patch checks that the icon exists both in the database AND in the disk. If the
icon doesn't exist in the disk and the default_icon variable is set to True,
then windowmaker loads the default icon using the function get_default_image()
because this function searches the default icon directly.
The function get_default_image() is moved from icon.c to wdefaults.c because
it is now used in both places. This function is now splitted, to find the file
(get_default_image_path) path and the file image (get_default_image)
The function get_default_icon_rimage name is not correct, because
the function doesn't return the default icon rimage, returns the
rimage from a file name. So the correct function name should be
get_rimage_from_file.
The functions wDefaultGetIconFile(), get_default_icon_filename() and
get_generic_value() use the argument noDefault in order to avoid searching the
default icon. This double negation is difficult to read though. This patch
changes it to be True if the default icon should be included or false if not.
This patch changes the noDefault argument to default_icon, then the
True is now False and False is True.
The main change is at get_generic_value():
- /* Search the default icon name - See noDefault argument! */
- if (!value && !noDefault) {
+ /* Search the default icon name - See default_icon argument! */
+ if (!value && default_icon) {
Because the functions wDefaultGetIconFile() and get_default_icon_filename()
mainly forwards the noDefault argument to get_generic_value().
The code to find the icon in the function getWindowMakerIconImage()
is duplicated, because it is the same code as in get_default_icon_filename()
This patch includes the prototypes of get_default_icon_filename()
and get_default_icon_rimage() in defaults.h, so these functions
can be used in other files.
Icons in the switchpanel are constrained to the value of the IconSize
preference but the grid in which they are arranged is fixed at 64 pixels.
If IconSize is less than 64x64 the panel will show smaller icons with a
wide spacing, which looks pretty stupid.
Fix it by forcing the switchpanel to attempt to load images at the size
it's going to use. The icon it actually gets may of course still be
smaller.
There is no point in having parameter in wDefaultsCheckDomains() and
not using it, so let's simply remove the parameter altogether and
avoid silly-looking things like
wDefaultsCheckDomains("bla");
- Separated the font caches for normal fonts and fontsets in WINGs (they can
have the same names and collide in the cache giving unwanted results)
- Updated the years in the copyright notices
- Also tested the backward compatibility ability of the WINGs proplist code
which seems to work quite well.
Starting with this moment, Window Maker no longer needs libPropList and is
now using the better and much more robust proplist code from WINGs. Also the
WINGs based proplist code is actively maintained while the old libPropList
code is practically dead and flawed by the fact that it borrowed concepts
from the UserDefaults which conflicted with the retain/release mechanism,
making some problems that libPropList had, practically unsolvable without a
complete redesign (which can be found in the more robust WINGs code).
