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 769788 - Fix stacking order of flatpak portals on Wayland
Fix stacking order of flatpak portals on Wayland
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Wayland
unspecified
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-08-12 10:08 UTC by Jonas Ådahl
Modified: 2016-08-29 17:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
wayland: Add API for creating exported window handles (7.88 KB, patch)
2016-08-12 10:08 UTC, Jonas Ådahl
committed Details | Review
window: Add Wayland implementation of gtk_window_export_handle (3.19 KB, patch)
2016-08-12 10:08 UTC, Jonas Ådahl
committed Details | Review
wayland: Add API for setting an exported as a parent (5.75 KB, patch)
2016-08-12 10:08 UTC, Jonas Ådahl
committed Details | Review

Description Jonas Ådahl 2016-08-12 10:08:32 UTC
This adds support for using xdg-foreign to stack portal dialogs correctly under
Wayland. Required mutter patches can be found in bug 769786.
Comment 1 Jonas Ådahl 2016-08-12 10:08:37 UTC
Created attachment 333168 [details] [review]
wayland: Add API for creating exported window handles

Using the xdg_foreign protocol, expose a way to get handles to windows
that may be shared between processes.
Comment 2 Jonas Ådahl 2016-08-12 10:08:42 UTC
Created attachment 333169 [details] [review]
window: Add Wayland implementation of gtk_window_export_handle
Comment 3 Jonas Ådahl 2016-08-12 10:08:48 UTC
Created attachment 333170 [details] [review]
wayland: Add API for setting an exported as a parent

Add an API that enables an application to, given an exported window
handle, set its own window as a transient of the window associated with
the exported window handle.
Comment 4 Matthias Clasen 2016-08-17 07:45:08 UTC
Review of attachment 333168 [details] [review]:

looks good to me
Comment 5 Matthias Clasen 2016-08-17 07:46:45 UTC
Review of attachment 333169 [details] [review]:

ok
Comment 6 Matthias Clasen 2016-08-17 07:49:15 UTC
Review of attachment 333170 [details] [review]:

::: gdk/wayland/gdkwindow-wayland.c
@@ +3303,3 @@
+ *
+ * Stability: unstable
+ */

Do you not consider this stable yet ?
Comment 7 Jonas Ådahl 2016-08-17 08:03:08 UTC
(In reply to Matthias Clasen from comment #6)
> Review of attachment 333170 [details] [review] [review]:
> 
> ::: gdk/wayland/gdkwindow-wayland.c
> @@ +3303,3 @@
> + *
> + * Stability: unstable
> + */
> 
> Do you not consider this stable yet ?

The idea was to try it out for a release and then mark it as stable. The underlying protocol is also not declared stable yet.
Comment 8 Emmanuele Bassi (:ebassi) 2016-08-17 09:07:16 UTC
If 3.22 becomes the last API stable/feature frozen release of the 3.x API series then API introduced in this cycle will have to be stable.
Comment 9 Jonas Ådahl 2016-08-17 09:11:01 UTC
(In reply to Emmanuele Bassi (:ebassi) from comment #8)
> If 3.22 becomes the last API stable/feature frozen release of the 3.x API
> series then API introduced in this cycle will have to be stable.

I thought that was at least 3.24? FWIW, I'd rather see it be 3.24 since we still need to make a backward incompatible "xdg_shell" bump, and would be nice if that could be done bofore we declare "gtk3" stable.
Comment 10 Matthias Clasen 2016-08-20 02:45:13 UTC
do you mean the bump to v6, or another bump ?
Comment 11 Jonas Ådahl 2016-08-21 03:29:41 UTC
(In reply to Matthias Clasen from comment #10)
> do you mean the bump to v6, or another bump ?

I mean yet another bump. My intention is to try to declare "xdg-shell" stable for 3.24. Not until then can we promise backward compatibility without having a unstable old unused protocol implementation in every compositor GTK+ 3 is intended to run on for ever.
Comment 12 Jonas Ådahl 2016-08-22 10:36:20 UTC
Just landed the mutter patches. What should we do about the stability tag of this API?
Comment 13 Matthias Clasen 2016-08-24 10:40:01 UTC
I would suggest that we just declare the api stable. It doesn't directly expose wayland protocol objects. As long as we have optional window ids at all, we should be able to keep it working. No ?
Comment 14 Matthias Clasen 2016-08-29 17:29:13 UTC
Attachment 333168 [details] pushed as 127d2ac - wayland: Add API for creating exported window handles
Attachment 333169 [details] pushed as f98c9fe - window: Add Wayland implementation of gtk_window_export_handle
Attachment 333170 [details] pushed as 340b596 - wayland: Add API for setting an exported as a parent