Up arrow keybinding changed in 0.96?

[mremski]

Been running WindowMaker on FreeBSD forever, the package repos were just updated to pull in 0.96.0, previous version was 0.95.9. My local ($HOME/GNUStep) config files have not changed.
It looks like the up arrow on the keyboard is now bound to showing a small version of the current desktop in the lower right corner.
Happens regardless of where the mouse cursor is: xterm, in emacs, in vi.

I can't find in any config files where this is bound, nothing in WPrefs.app is jumping out with this.

What am I not seeing?
Thanks.

[mremski]

I went and explicitly bound Up to a different action (randomly chose the Exit Windowmaker internal command), restarted WindowMaker, verified it was bound to exit, then went back and cleared the binding from Exit internal command and it's back to operating as expected.

Edit:
Looks like when cleared, if I exit WindowMaker and then restart, the weird binding is back. I've tried saving the session after the set/clear and it still happens.
Any idea welcom.

[gryf]

Can you check Capture… entries on wprefs shortcut menu? From descriptions it seems that for whatever reason printscr key is assigned to up arrow on your setup.

[mremski]

Yep, I'll take a look there and report.
I also went and mv'd my $HOME/GNUstep directory out of the way and basically did a wmaker.inst to give me a fresh configuration and the problem was still there

Thanks for taking a look.

[mremski]

I moved my $HOME/GNUstep out, ran wmaker.inst so started with a fresh config.
Running wprefs app, keyboard shortcuts preferences "capture entire screen" was checked, the shortcut said "Print". Looking at all the checked options, none had "Up" as the shortcut, pressing the Up arrow looks like it ran the Print function, pressing the Print Screen key resulted in nothing.

For the capture entire screen, I captured a new keybinding and pressed the Print Screen key.
Doing that the Up arrow was not bound to PrintScreen anymore and the PrintScreen key was bound to the Print function.

Unchecking/clearing the "Capture Entire Screen" also let the Up key function as the up arrow again.

As noted in the OP, this happened after updating to the latest FreeBSD port, same keyboards worked fine before the port update.

If noone else has reported this type of behavior, I'm good with the workaround of explicitly clearing the capture entire screen binding or explicity recapturing the binding to PrtScr key.
I can provide any config files if needed or if it just becomes a Release Note item that works too.

Edit: looks like exiting the windowmaker session and restarting the up arrow seems to be bound to Print key again. I'll double check for any odd locale or keymap stuff but I don't think there is any.

[crmafra]

On Wed, 21 Feb 2024 at 4:36:46 -0800, Mike Remski wrote: I moved my $HOME/GNUstep out, ran wmaker.inst so started with a fresh config. Running wprefs app, keyboard shortcuts preferences "capture entire screen" was checked, the shortcut said "Print". Looking at all the checked options, none had "Up" as the shortcut, pressing the Up arrow looks like it ran the Print function, pressing the Print Screen key resulted in nothing. For the capture entire screen, I captured a new keybinding and pressed the Print Screen key. Doing that the Up arrow was not bound to PrintScreen anymore and the PrintScreen key was bound to the Print function. Unchecking/clearing the "Capture Entire Screen" also let the Up key function as the up arrow again. As noted in the OP, this happened after updating to the latest FreeBSD port, same keyboards worked fine before the port update. If noone else has reported this type of behavior, I'm good with the workaround of explicitly clearing the capture entire screen binding or explicity recapturing the binding to PrtScr key. I can provide any config files if needed or if it just becomes a Release Note item that works too.

There have been some recent changes in this area, see the commit https://repo.or.cz/wmaker-crm.git/commit/d045ffcf7d37f60df09cac32698ee4c4b10e1a42 There seems to be no obvious reason for this behavior by looking at the patch. Maybe some size of the structs being modified is hard coded somewhere? But this would be detectable by more people. I am using this feature and had no problems with key bindings. commit d045ffc Author: David Maciejak ***@***.***> Date: Tue Mar 7 19:46:50 2023 +0800 Add a screenshot capture feature

[mremski]

Thanks; I'll look at diffs. For the moment, simply clearing the binding is an acceptable workaround to me.

@crmafra thanks for pointing out that commit. Looking at the diffs nothing jumped out at me; commas in the right places, breaks to avoid falling through cases. Local configuration for fresh install looked fine too.
I also made sure to not have any weird keymaps or language things going on. It was easily
reproducible for me so I can keep poking at it or test ideas as needed.