I’m involved in the pure-gtk port of emacs, currently working on issues with the implementation of child-frames/ child gtk windows.
These are used by many elisp packages for error messages, completions or general interaction as glorified text boxes.
I have some issues getting child windows to move with their parents, despite this working fine in the mish-mash x/gtk emacs in master.
this works fine for wayland, as the new windows are created as GTK_WINDOW_POPUP types with gtk_window_transient_for and are handled as subsurfaces of the parent, and get relocates as part of the surface being moved.
on X the child windows are always fixed until an internal resize/reposition call to gtk_window_move with new absolute coords relative to the position of the parent.
Is there a recommended call/attribute to ‘pin’ child windows relative to their parent?
alternatively would signalling on a configure event cause excessive performance issues?
I’m wondering if this is related to the issues I’ve observed (see my question below regarding popup menus). It is not clear to me what the common layer expects of the frontend implementation in terms of positioning child windows. I ended up coercing the GtkWindow x and y fields inside the move_to_rect callback, but that doesn’t feel right.
Right, those differences reflect the differences in the implementation, wayland representing a toplevel as a tree of surfaces.
GTK_WINDOW_POPUP in X11 (or override-redirect in x11 parlance) always had this trait, actually one of the redirects it overrides are Configure requests… It means the client must do that itself, the WM can’t.
There’s none, esp. with GDK_WINDOW_POPUP. GDK_WINDOW_CHILD (if you are using gtk3) is something that moves along with its parent, although that cannot float outside the toplevel window coordinates. Not sure if that’s ok with you.
X11-specific code is also plausible. Shouldn’t be expensive, inasmuch as the WM is judicious with XMoveWindow(). Although probably it will feel like the window lags behind, as the windows still don’t move “atomically” like on Wayland.
GTK_WINDOW_POPUP in X11 (or override-redirect in x11 parlance) always had this trait, actually one of the redirects it overrides are Configure requests… It means the client must do that itself, the WM can’t.
fejfighter:
This makes sense, especially for tooltips etc,
GDK_WINDOW_CHILD (if you are using gtk3) is something that moves along with its parent, although that cannot float outside the toplevel window coordinates.
I think this would be acceptable, I believe the X-only port has similar restrictions (I’ll need to confirm later tonight) as it does XReparentwindow to achieve it. The window relocation appears more important.
Would this require creating a GDKWindow and building it up manually? I had tried a gdk_window_reparent(gtk_widget_get_window(window)) but I hit the window != GDK_WINDOW_CHILD assertion when calling gtk_widget_show()
Although probably it will feel like the window lags behind
This would be a “work around” fix that I’d rather avoid if possible.
Jeff, do you have a repository for the emacs work that I can try out? The main impetus for me to start working on a GTK frontend for my system was to get the GUI version of emacs, only to find out that even with GTK3 it still relies on X11
it builds libgccjit from tree and builds a combined pure-gtk wtih gcc native compilation of the elisp. It’s a slower build but a snappier end result
These have been my daily driver emacs builds for a while on wayland/gnome, and for others on wayland. It’s only now that others have tested them on X11 backends that we are finding issues
