I've noticed that when Gio draws the window decorations, the buttons in the title bar are included in the tab order for keyboard focus: After cycling through the widgets in the content of the window, pressing tab goes to the minimize, maximize, and close buttons before returning to the regular widgets.
@whereswaldon suggested: I think we'd just need a way to mark a given gesture.Click and/or widget.Clickable as ineligible for keyboard focus, and we could then use that in the implementation of widget.Decorations
Yes. Or perhaps keyboard/focus handling should be extracted from
widget.Clickableinto its own type.
I guess that's one drawback to the new event filter API. When you call
event.Op, you can't specify whether you want keyboard events, mouse events, or both. I just ran into the other side of the issue today: I wanted a widget to handle certain keyboard events, but no mouse events; I accidentally made it silently swallow all mouse events, so none of the other widgets in the window worked. (The fix was pretty simple once I figured it out: set an empty clip region before callingevent.Op.)
event.Opshouldn't swallow events that you don't provide filters asking for. If you callgtx.Eventwith pointer filters, you'll get whatever events are available, but a top-level widget that doesn't ask for pointer events should not receive them. Were you asking for pointer events at the top level?
Nothing in my code was asking for pointer events directly. But when I called
event.Opwithout setting a clipping area, the buttons on the screen didn't respond to clicks. I think what was happening was that all the click events were being tagged with the tag from myevent.Opcall instead of the tags they would normally have had. So when the buttons set event filters, the clicks didn't match.
~andybalholm, can you provide a small example of the issue, preferably in a new TODO? I'd like to fix the event logic if there's a bug here.