building inconsistent mouse-event%

[Metaxal]

It is possible to build an inconsistent mouse event:

> (define ev (new mouse-event% [event-type 'left-down]))
> (send ev get-left-down)
#f

As this has caused me a bit of a headache, I'm willing to fix this, but before doing so I'm checking with you if there may be any downside with such a fix, like backward compatibility---although it may be considered this a bug I guess.

[Metaxal]

There's actually an inconsistency with key-events here:

When pressing shift alone, (send ev get-shift-down) is #false, but when releasing shift, the corresponding release event has (send ev get-shift-down) to #true. Same for control.

However it's the converse for mouse events: when pressing left, (send ev get-left-down) is #true but #false on the release event.

Context: I'm trying to understand why a number of keybindings don't work in DrRacket (for example I could never make it to accept Ctrl-Shift-T, despite showing as "c:s:t" in the active keybindings). I'm guessing the issue is rather deeply buried in the inner workings of the GUI and keymaps.

[Metaxal]

cc @rfindler I guess

[mflatt]

For the original question, I agree that the backward-compatibility issue here looks tricky. I don't know how existing code would be affected.

For the get-shift-down part, that's probably platform-specific where racket/gui doesn't manage to normalize away the difference. I see what you report with Gtk (Unix/X), where key-event% is reflecting the GdkEventKey.state bits directly. On Mac OS, I see the behavior you expected. I guess X/Wayland considers modifiers to take effect for later keys, and not the press of the key itself. Meanwhile, though, I doubt that's the source of problems with Ctl-Shift-T.

[Metaxal]

For the original question, I agree that the backward-compatibility issue here looks tricky. I don't know how existing code would be affected.

For the get-shift-down part, that's probably platform-specific where racket/gui doesn't manage to normalize away the difference. I see what you report with Gtk (Unix/X), where key-event% is reflecting the GdkEventKey.state bits directly. On Mac OS, I see the behavior you expected. I guess X/Wayland considers modifiers to take effect for later keys, and not the press of the key itself.

Hm, I see, that's rather annoying.

Meanwhile, though, I doubt that's the source of problems with Ctl-Shift-T.

In principle I suppose it could, if keybindings in DrRacket are designed with Mac behaviour in mind, but used on X. But you're still probably right, since some other Ctl-Shift-/ keybinding does work for some reason. I wonder if DrRacket/keymaps are not trying to be too smart for their own good.

I'm not sure where to go from here, and I'm pondering whether to close this issue as "won't fix". It feels like these inconsistencies across platforms should be smoothed out though, but if that doesn't solve the DrRacket keybinding problem maybe it's not even worth it.