Childframe doesn't move with parent

[flatwhatson]

When moving the parent window, the childframe remains in its original position.

Before moving:

After moving:

I'm running the X11 backend on Plasma.

[fejfighter]

I have spent some time digging into to this issue. trying to figure out why/how it worked.

when setting up the frame, Emacs subscribes to the configure event with the SubstructureNotifyMask to get relative configure notifications.

Unfortunately it appears that gdk might be ignoring/discarding these before we get the chance to do anything https://developer.gnome.org/gdk3/stable/gdk3-Events.html

[masm11]

the tooltips package should close the tip frame on frame move or raise/lower, shouldn't it?

[fejfighter]

@masm11 these are https://github.com/alexmurray/flycheck-posframe child frames.

not the tooltips (gtk or custom ones from the recent MR

[masm11]

@fejfighter On X, childframing is easy. It needs just reparenting. Child frames automatically follow parent frame's motion and raise/lower.

On Wayland on the other hand, it is hard. We can't reparent. Since we implemented child frames with GTK_WINDOW_POPUP, child frames don't follow parent frame's motion.

Do we need to re-create code to handle child frames with EmacsGtkFixed not GtkWindow?

[fejfighter]

@fejfighter On X, childframing is easy. It needs just reparenting. Child frames automatically follow parent frame's motion and raise/lower.

Setting reparenting through gtk interfaces does not seem to achieve anything but that may be related to

On Wayland on the other hand, it is hard. We can't reparent. Since we implemented child frames with GTK_WINDOW_POPUP, child frames don't follow parent frame's motion.

This was done as it creates the window on a subsurface for Wayland, emulating that "reparented" window effect.

Windows with type GTK_WINDOW_POPUP are ignored by the window manager This may actually be the root of the issues

Do we need to re-create code to handle child frames with EmacsGtkFixed not GtkWindow?

I had thought of doing this, but the emacs manual implies that a child frame is intended to be a full-fledged window, and I am not sure how widgets intending to break out of the parent frame (large error messages) will work. but that should handle the relocation issues

[masm11]

I read Child Frame section of the elisp.info.

Also, the relative roles of child and parent frame may be reversed at any time

That means a parent frame and a child frame can be swapped??

too complex...

[fejfighter]

Yeah I think it's the usual over-flexible emacs approach.

I have had issues with gdk_window_reparent causing windows to hide for me. and GTK_WINDOW_POPUP/GTK_WINDOW_TOPLEVEL swaps have achieved nothing.

My latest approach was to hook on the configure event, which is causing race conditions.

I accidently ended up on the gtk4 window documentation page and noticed that GTK is moving to a gtk_window_add_child() approach, removing gdk_window_reparent in the transition guide.

@flatwhatson hate to be "that" developer but is there a strong reason for using pgtk with X11? The more I look at this, the more it's feeling like GTK inconsistencies across platforms, and given master has a working x11/GTK term, I'm inclined to favour wayland/GTK (for now) given that's a listed goal for the port, but given the work @masm11 put in to get it off the ground, it's really his decision.

[flatwhatson]

I'm interested in having this work on X11 because it provides a significant performance improvement over the existing engine.

I'm still using this port as my daily-driver in spite of the relatively minor usability problems with childframes, so I'd be fine if it goes onto the backlog. I think that X11 use is still wide-spread enough that there would be broad interest in having pgtk working there once it becomes more widely known.

Sorry that this turned out to be quite a rabbit-hole, I really appreciate both your efforts to get this implementation happening!

[fejfighter]

I'm interested in having this work on X11 because it provides a significant performance improvement over the existing engine.

That's interesting to know.

I'm still using this port as my daily-driver in spite of the relatively minor usability problems with childframes, so I'd be fine if it goes onto the backlog. I think that X11 use is still wide-spread enough that there would be broad interest in having pgtk working there once it becomes more widely known.

That would be the preference, and I'd only drop that if this requires major diversion between backends.

Sorry that this turned out to be quite a rabbit-hole, I really appreciate both your efforts to get this implementation happening!

Hardly your fault, I have reached out to the GTK community here I will need a night or 2 off, but I'll try to box out some time on the weekend,

[masm11]

I started re-implementing child frame though I don't know whether I can complete it.

[masm11]

In #51, I'm re-implementing child frame. For now, the relocation issue has been fixed.

[masm11]

fixed by #51.