Re: key bindings for "frame|title" don't work

--pgp-sign-Multipart_Thu_Nov_14_13:06:17_2024-1
Content-Type: text/plain; charset=US-ASCII

At Tue, 12 Nov 2024 15:28:16 -0800, "Greg A. Woods" <[email protected]> wrote:
Subject: key bindings for "frame|title" don't work
>
> I have some key bindings for "frame|title", but they don't seem to
> work.
>
> e.g:
>
> 	"Left"	=		: frame|title	: f.jumpleft "2"
>
> These all seem to get delivered to the app, not to CTWM.
>
> I have some button bindings for "frame" and "frame|title", and these do
> seem to work OK.
>
> Key bindings elsewhere seem to work OK.
>
> I've not looked at the code yet to see if anything obvious jumps out,
> but I'm wondering if anyone else has tried such uses.

So, looking at the code, I got somewhat confused!

First off I didn't realize that contexts are split apart into separate
entries in the parsed key bindings table.  So, that means checking if a
key event matches is valid with a simple equality comparison, no
bit-masks necessary, as the key bindings table will contain an entry for
qeach context specified (including one for each with the magic "all").

Modifiers, on the other hand, are "all-in", or "anded", i.e. despite the
use of the potentially misleading/confusing/overloaded "|" combiner
symbol in the config file (meaning "and" with modifiers, and "or" with
contexts), so again a simple equality comparison suffices (all modifiers
have to be pushed or not pushed in exactly the defined combination for a
match).

Once I figured that out I stumbled upon the next comments and lines in
event_handlers.c:HandleKeyPress():

		/*
		 * Weed out the functions that don't make sense to execute from a
		 * key press
		 *
		 * TODO: add keyboard moving/resizing of windows.
		 */
		if(key->func == F_MOVE || key->func == F_RESIZE) {
			return;
		}

Huh?  That's not documented!  Nor does it cover the myriad of other
movement and resizing functions, never mind custom defined functions
that achieve the same.

It doesn't even make sense.  The pointer could/should follow the window
(i.e. the frame component or the titlebar), just as is documented for
"f.pack".

Anyway, digressions aside....

Then I noticed mention of "NoTitleFocus", and things started to become
clearer to me!

So I set that, and now my bindings for titlebar work, but frame bindings
still do not work.  Doesn't "frame" mean the decoration lines around the
app window proper?  The frame gets button events as expected, and I can
drag frames to resize windows.

Unfortunately "NoTitleFocus" has several adverse affects, including that
if windows are touching then moving the cursor from also doesn't
reliably seem to move focus between the apps (depending on the speed of
the move), while moving over the root window, or moving the pointer very
slowly, is reliable.  I'm guessing this has to do with mouse
"acceleration" and whether or not the pointer actually hits the frame
and delivers and event when it is travelling fast.

So I think the remaining question is why key bindings don't seem to work
in the "frame" context.

--
					Greg A. Woods <[email protected]>

Kelowna, BC     +1 250 762-7675           RoboHack <[email protected]>
Planix, Inc. <[email protected]>     Avoncote Farms <[email protected]>

--pgp-sign-Multipart_Thu_Nov_14_13:06:17_2024-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP Digital Signature

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCZzZmTgAKCRBmfXG3eL/0
fwPTAKCQr4wqiBodUN38K0zJCMF6pWv3bgCfXTjfyG98FWSRFez/YkTus/3eBxY=
=9b7K
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Thu_Nov_14_13:06:17_2024-1--