After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 781845 - GTK_WINDOW_POPUP cannot gain keyboard focus when using gtk_window_set_transient_for
GTK_WINDOW_POPUP cannot gain keyboard focus when using gtk_window_set_transie...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Wayland
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2017-04-27 15:56 UTC by ipun
Modified: 2017-05-09 13:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Snippet that demonstrates keyboard focus problem (1.31 KB, text/x-csrc)
2017-04-27 15:56 UTC, ipun
Details
Modified code (1.33 KB, text/plain)
2017-04-28 15:53 UTC, Olivier Fourdan
Details
temp window as xdg_popup (2.45 KB, text/plain)
2017-05-02 16:01 UTC, Olivier Fourdan
Details

Description ipun 2017-04-27 15:56:32 UTC
Created attachment 350560 [details]
Snippet that demonstrates keyboard focus problem

Run the included snippet to see the issue. 

The textbox in the new popup cannot be clicked/focused on, causing issues with our application. We have GTK_WINDOW_POPUP windows that need keyboard focus and was working in X11.
Comment 1 Olivier Fourdan 2017-04-28 15:53:22 UTC
Created attachment 350659 [details]
Modified code
Comment 2 Olivier Fourdan 2017-04-28 15:55:50 UTC
I don't think "popup" windows are supposed to be focused by default, not even on X11 (where they translate as override-redirect, which are not focused). As a matter of fact, that particular code snippet doesn't work on X11 (GDK_BACKEND=x11 ...) here.

For this particular use, I reckon a popover would be more appropriate though and would do all that for you transparently, but I understand that might require some changes in the code.

That being said, with the code as it is, under Wayland that translates as a subsurface because you didn't setup a grab. But I doubt you'd want a grab or popup for this intended use, I think.

Best imho is to simply add a "gtk_grab_add (popup);", see attached code.
Comment 3 ipun 2017-05-01 13:33:01 UTC
(In reply to Olivier Fourdan from comment #2)
> I don't think "popup" windows are supposed to be focused by default, not
> even on X11 (where they translate as override-redirect, which are not
> focused). As a matter of fact, that particular code snippet doesn't work on
> X11 (GDK_BACKEND=x11 ...) here.
> 
> For this particular use, I reckon a popover would be more appropriate though
> and would do all that for you transparently, but I understand that might
> require some changes in the code.
> 
> That being said, with the code as it is, under Wayland that translates as a
> subsurface because you didn't setup a grab. But I doubt you'd want a grab or
> popup for this intended use, I think.
> 
> Best imho is to simply add a "gtk_grab_add (popup);", see attached code.

Thanks Olivier,

Im getting a bit closer to what I need. Although it was able to grab the focus with gtk_grab_add(), I am not able to lose the focus. I would like the popup to be able to lose/gain focus freely, just that I'd like it to have the ability to focus (and focus on default). The popup should initially grab focus on showing, but able to lose focus if clicked on parent window, etc.

The way we implemented it in x11 was using an override-redirect implementation, which we are trying to translate over to Wayland.
Comment 4 Olivier Fourdan 2017-05-02 06:50:58 UTC
(In reply to ipun from comment #3)
> [...]
> The way we implemented it in x11 was using an override-redirect
> implementation, which we are trying to translate over to Wayland.

Would you say your use case is similar to a menu, i.e. a short lived window that shows up on a user input action and closes down if clicked outside?

If so, then yes, an xdg_popup would match.
Comment 5 ipun 2017-05-02 14:22:24 UTC
(In reply to Olivier Fourdan from comment #4)
> If so, then yes, an xdg_popup would match.

I briefly looked into xdg_popup, but I am not 100% clear on how to use it with GTK. The use case is pretty much what you described (a menu). As it is not feasible for us to migrate over to popovers at this time, I would like to know how i could use xdg_popup with GTK in order to get the same outcome.
Comment 6 Olivier Fourdan 2017-05-02 16:01:40 UTC
Created attachment 350894 [details]
temp window as xdg_popup

(In reply to ipun from comment #5)
> I briefly looked into xdg_popup, but I am not 100% clear on how to use it
> with GTK. The use case is pretty much what you described (a menu). As it is
> not feasible for us to migrate over to popovers at this time, I would like
> to know how i could use xdg_popup with GTK in order to get the same outcome.

Well, gdk will automatically use an xdg_popup for a temp window if the required conditions are met, i.e. when a grab is available.

I have attached a new code sample that does that. Click in the main window to show the popup with input focus.
Comment 7 Olivier Fourdan 2017-05-09 07:28:59 UTC
Hi, does this answer the question, can I close the bug then?
Comment 8 ipun 2017-05-09 13:35:13 UTC
(In reply to Olivier Fourdan from comment #7)
> Hi, does this answer the question, can I close the bug then?

Hi Olivier, yes it does. Feel free to close it.
Comment 9 Olivier Fourdan 2017-05-09 13:36:00 UTC
Thanks!