Alt-Click resizing interferes with some programs

I've found that some programs hard-code the Alt-Click as a hotkey, but this triggers the window resizing in berrywm and doesn't pass the mouse event on.

A specific example is Purr-Data, you need to hold Alt and left click in order to use the UI (so its currently impossible to use this program in berrywm)

I've just changed my local version to use Super+Alt+Click to be resize rather than Alt+Click,
in config.h:

• old: #define RESIZE_MASK Mod1Mask
• new: #define RESIZE_MASK (Mod1Mask | Mod4Mask)

If it is already possible to change this with berryc then ignore me!

Thanks,
Pat

[JLErvin]

This is currently half-possible in berryc using the resize_mask function. However, that argument takes a single mod as an argument, so you can't currently use two mods in combination with one another.

[Sidd-Dino]

I've been poking the code for bit.
I thought of implementing a way to allow the resize_mask function of berry.
Been tossing stupid ideas to avoid pointless string manipulation.
I've come to rest on the idea of using hashing.
Just wanted to check if i'm being dumb.

Oooh the hash function i thought of using is djb2

The shortcoming for this (hashing in general) would be;
Options that the function fn_str in client.c would deem legal would need to have their has hard coded. To avoid pointless hashing.

After thought : I do loose points on simplicity though :/

[JLErvin]

We can probably think of a much simpler solution than having to hash the resize mask. There's likely a fairly simple solution, actually, now that I think about it. Rather than passing a string to the X11 server, the resize_mask command in the client can simply send the mask itself.

The way that these masks work is that they're just a series of numbers, each with only one non-zero bit. They're defined in X.h as such:

#define ShiftMask		(1<<0)
#define LockMask		(1<<1)
#define ControlMask	(1<<2)
#define Mod1Mask		(1<<3)
#define Mod2Mask		(1<<4)
#define Mod3Mask		(1<<5)
#define Mod4Mask		(1<<6)
#define Mod5Mask		(1<<7)

Then, when we call a function like XGrabButton, we supply a mask which is simply the bitwise or of the masks that we want to use. So, If Mod1 and Mad2 are both valid, we would simply pass in Mod1Mask|Mod2Mask as arguments.

Since the values of these masks are standard across the client and server (the berry client/server, that is), we can probably just have the client send over a masked integer as an int and read that on the server side. It would require some parsing on the part of the client, but I think it's more reasonable than using hashing.

[Sidd-Dino]

Ah i got misunderstood
I intended to parse the human input provided during berryc resize_mask <input>
by hashing and comparing it to some for of table.
But the amount of hard coding needed for the hashing implementation worries me.

I believe berryc uses (c->handler)(ev.xclient.data.l, c->config, i, argv); and another variant for the name_desktop function, but the snippet gives me an idea as to what really gets transferred
ev.xclient.data.l that caries the Mask values is long*

I'm currently concentrating on translating the string
from "Mod1|Mod2" to (1<<3)|(1<<4)
So that i can safely send it as long.

I'll abandon hashing for now and search for other stupid ideas :)

[Sidd-Dino]

I checked out baskerville/sxhkd
I though they definitely would have been plagued by repeated checks.
Oh they were

Looks like avoiding repeated checks is gonna make it pointless seeing that the maximum number of things that need to be checked against are ~8 Modifier Masks

So repeated checks it is

I'm trying to make a parse function as compact as possible.
Difficulty in reading might be a con, I'll aim to minimize it

[JLErvin]

I think simply enumerating all inputs is fine. It’ll be a bit tedious but it’s totally understandable.

[Sidd-Dino]

I gave it a go
Turned out to be pretty simple

Pretty much the same from the source sadly
But resize_mask or move_mask can now accept a string of multiple modifier with | as their separator

Also noticed a potential bug
berryc resize_mask <unintended_value> results in making the pointer have improper interaction with the clients

I believe when said unintended value is passed.
(c->handler)(ev.xclient.data.l, c->config, i, argv); in client.c
sets either 0 or some random value to ev.xclient.data.l

Which when sent as an event to wm.c
Sets conf.resize_mask or conf.move_mask to that unknown value
Which gets grabbed by X in grab_button unchecked

A simple check would do it

[Sidd-Dino]

Yo @hatcatpat I tried a potential solution #146
Have a go at it if you want :D