Gdk: get_current_mask implementation on windows

Platform
,
1

I believe the current implementation could be improved like this:

static GdkModifierType
get_current_mask (void)
{
	GdkModifierType mask;

	mask =  ((GetAsyncKeyState(VK_LBUTTON)&0x8000) ? GDK_BUTTON1_MASK : 0) |
		((GetAsyncKeyState(VK_MBUTTON)&0x8000) ? GDK_BUTTON2_MASK : 0) |
		((GetAsyncKeyState(VK_RBUTTON)&0x8000) ? GDK_BUTTON3_MASK : 0) |
		((GetAsyncKeyState(VK_CAPITAL)&0x8000) ? GDK_LOCK_MASK    : 0) |
		((GetAsyncKeyState(VK_CONTROL)&0x8000) ? GDK_CONTROL_MASK : 0) |
		((GetAsyncKeyState(VK_MENU)   &0x8000) ? GDK_MOD1_MASK    : 0) |
		((GetAsyncKeyState(VK_SHIFT)  &0x8000) ? GDK_SHIFT_MASK   : 0);

	return mask;
}

That way the mouse button state is propagated correctly regardless of what events the application has received.

I have no idea how to actually submit a patch.

2

We have a guide on how to contribute, but a good first step would be to open an issue.

1 Like
3

That might or might not be a good idea. GetAsyncKeyState() gets the state of the key at the time of the function call, whereas when doing event processing you usually want the state of the key at the time when the event happened. Since GTK does not work in real time, these two moments might not be simultaneous.

4

Well currently functions like gdk_device_get_state don’t return the correct mouse state for me at all. So at least they work for me with the given “fix”. So while you are right I think it’s less of an issue than having gdk_device_get_state not work.

5

Then there’s a bug in gdk_device_get_state() in W32 GDK backend. Or maybe not. That function gets current state of the device, without tying it to any event. Maybe the state it returns is correct at the moment when you are calling it (basically, the same argument as above, only in reverse).

6

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.