Calculate actual popover position for mouse event detection #63
Conversation
src/Services/PopoverManager.vala
Outdated
| current_indicator.get_parent ().get_allocation (out container_allocation); | ||
|
|
||
| int wingpanel_width; | ||
| current_indicator.get_root_window ().get_geometry (null, null, out wingpanel_width, null); |
There was a problem hiding this comment.
Can't we just use the already available owner field here?
There was a problem hiding this comment.
Thanks for the review, @donadigo
Since get_root_window returns a Gdk.Window, not a Gtk.Window. We still need the call to get_root_window. However, we still get the same resulting window if we get it through the owner and it may be slightly more efficient, so I've push a commit that switches to that.
Thanks.
There was a problem hiding this comment.
Okay, looks good. I actually didn't understand the part about getting the root window, but now I do. Both versions in this case are correct. You can revert the latest commit if you want. This to be tested by someone else with multi-monitor setup to confirm it's working as intended.
Fixes #62
The allocation of the
Gtk.Boxcontaining the indicator popover is used to determine if a click was inside the popover or not when deciding whether or not that click event should close the currently open popover.Because an
Allocationis relative to its parent this was always(0, 0)causing there to be a box the size of the current indicator popover to be in the top left that prevented you from clicking to close indicators. So, this PR does some maths to move the allocation calculation underneath the actual popover relative to the mouse co-ordinates.I considered removing the mouse bounds check altogether as items inside the popover still receive click events properly. But removing it causes the application menu to be closed when clicking a blank space inside it, so not ideal.