hello everyone,
In the Python plug-in, I want to use the function Gtk.Window.set_transient_for() sets the dialog to stay above the gimp main window (used to place reference images), but I don’t know,How to let the main window widget to Gtk.Window.set_transient_for().
Looking forward to your reply.
Hi,
I think you just want to use gimp_window_set_transient(). It takes care for you of finding the right GdkWindow (though looking at code, it looks like it might not work on Windows, apparently because of some bug in GTK where it was making GIMP hanging, according to code comments).
Thank you for your reply.
Take goat-exercise-py3.py as an example.
I added a line of code “GimpUi.window_set_transient(dialog)”, but，still can’t keep the plugin window above the gimp main window.
Is there something wrong with me?
https://gitlab.gnome.org/GNOME/gimp/-/blob/master/extensions/goat-exercises/goat-exercise-py3.py
goat-exercise-py3.py
dialog = GimpUi.Dialog(use_header_bar=True,
title=_("Exercise a goat (Python 3)"),
role="goat-exercise-Python3")
GimpUi.window_set_transient(dialog) #I add this line
dialog.add_button(_("_Cancel"), Gtk.ResponseType.CANCEL)
dialog.add_button(_("_Source"), Gtk.ResponseType.APPLY)
dialog.add_button(_("_OK"), Gtk.ResponseType.OK)
Operating environment ：manjaro,gnome,wayland.
With you probably not. But possibly with your code or with our API. 
Anyway which OS are you running this on? As said above, I saw in-code comments which were saying this was not working on Windows unfortunately.
Sorry, I didn’t mention my usage environment,
Operating system: manjaro
Desktop: gnome, wayland
Gimp version: 2.99.13
Oh answering to myself! I didn’t see the bottom info. You already said which OS:
It’s possible that Wayland is the “problem” here. We lose a lot of features related to knowing other processes windows info and the like (since GIMP plug-ins are run as separate processes, it might be a problem here).
It would be worth testing this by switching temporarily to X11. Then you’d know at least if Wayland makes a difference.
The gegl filter can be kept above the gimp main window (for example: lens blur), so does this have nothing to do with wayland?
GEGL filters are not plug-ins. Their dialog are not run from a separate process and therefore would not have such a problem.
I tested gtk3. Window set_ transient_ For (win1, win2), win1 can be kept above win2, so gtk3 should not be a problem on wayland. Gimp has a similar GimpUi. Dialog set_ transient_ For () function,
but I don’t know how to obtain the main window widget. If it can be obtained, it should succeed.
Is there a way? 
I just tested on x11, and the plug-in window can be above all software windows, which is very good.
I paint in gimp. I want to put reference pictures in the plug-in window. I know that in wayland, it is impossible to implement plug-in windows on all software windows. I just want the plug-in window to be above the main gimp window, which is convenient for reference when practicing painting.
But was win1 and win2 in separate processes? I.e. 2 independent programs running separately. This is the problem we are trying to solve here as plug-ins are separate applications and Wayland tries to contain them. Now there may be ways (or will be?) since one of the program is run by the other (the plug-in is run by GIMP) and they communicate. I don’t know, someone will have to look further into it.
Wayland is still proving quite challenging for big software with advanced needs, such as GIMP.
Cool. Then it seems to confirm that it’s a problem because of Wayland here. That was expected.
I definitely see the need. Actually the concept of reference window has been running around for some time and is definitely some feature we’d like to add in core GIMP someday. In one way or another.
For such a feature, going through plug-ins might have been a good idea years ago (before Wayland), but might prove challenging nowadays, considering that Wayland now tries to compartment all applications (and plug-ins are technically a separate application), preventing them from interacting with each other.
There might be some portals or some Wayland protocol to go around this when one process is run by the other, I don’t know. It will have to be studied, and possibly implemented. 
Thank you very much for your answer. 
Yes, that’s possible to do: gdk_wayland_window_export_handle() will (asynchronously) export a handle that you can use with gdk_wayland_window_set_transient_for_exported(). It’s up to the caller to pass the handle across process boundaries, of course, but that is also true for X11.
The main difference between X11 and Wayland is that the handle is created asynchronously by the Wayland display server, and has to be destroyed explicitly. The handle creation can also fail if the compositor does not support the correct protocol.
1 Like
Thanks! That’s very useful information. It should be easy to implement with this API.
See you say that,I’m looking forward to it!
thanks,But i can’t find these two functions. They should be gdk_ wayland_ toplevel_ export_ Handle() and gdk_ wayland_ toplevel_ set_ transient_ for_ Exported()?
Those are GTK4 functions; the corresponding GTK3 ones are not documented, but they are exported: https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gdk/wayland/gdkwaylandwindow.h#L63
That’s really good.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.