On Sun, 18 Dec 2022 21:02:20 GMT, Thiago Milczarek Sayao <tsa...@openjdk.org>
wrote:
>> This PR was previously discussed on #905.
>>
>> The approach is to grab the keyboard focus so the window that originated the
>> drag will keep it.
>>
>> I did some cleanup on grabbing related functions as well.
>>
>> `gdk_keyboard_focus()` is deprecated, so is `gdk_device*` functions in favor
>> of `gdk_seat*`. But that's only available in later Gtk versions. I checked
>> and newer Gtk will use `gdk_seat*` inside the deprecated
>> `gdk_keyboard_focus()`.
>
> Thiago Milczarek Sayao has refreshed the contents of this pull request, and
> previous commits have been removed. The incremental views will show
> differences compared to the previous content of the PR. The pull request
> contains one new commit since the last revision:
>
> 8292922 - [Linux] No more drag events when new Stage is created in drag
> handler
This one deserves a laught. Just commenting the `ungrab_mouse_drag_focus();` on
focus lost fixes the problem. I will rework it.
void WindowContextBase::process_focus(GdkEventFocus* event) {
if (!event->in && WindowContextBase::sm_mouse_drag_window == this) {
ungrab_mouse_drag_focus();
}
// if (!event->in && WindowContextBase::sm_mouse_drag_window == this) {
// ungrab_mouse_drag_focus();
// }
if (!event->in && WindowContextBase::sm_grab_window == this) {
ungrab_focus();
}
The rationale is that `glass_gdk_mouse_devices_grab_with_cursor` grabs motion
events so it keeps coming to the window, but there's an explicit "stop
grabbing" on focus lost.
-------------
PR: https://git.openjdk.org/jfx/pull/977
