[Wayland-bugs] [Bug 748763] warnings when starting drag from GtkEntries

[gtk+ (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=748763

--- Comment #5 from Carlos Garnacho <carlosg at gnome.org> ---
(In reply to Matthias Clasen from comment #3)
> Review of attachment 302730 [details] [review]:
> 
> ::: gtk/gtkwindow.c
> @@ +7333,3 @@
> +      gtk_container_forall (GTK_CONTAINER (widget),
> +                            (GtkCallback) gtk_widget_unrealize,
> +                            NULL);
> 
> Hmm, this seems to manually do what the parent_class unrealize would do
> anyway ?

Mostly, except destroying the window...

> 
> It would be nicer if we could still unconditionally chain up - just clear
> out the hardcoded_window first ?

I tried to do that, ideally the window should be removed (and removed from
being used as gtk_widget_set_window()) before the widget is hidden/unrealized,
it wasn't any easy at that time without rising a bunch other warnings :(

(In reply to Matthias Clasen from comment #4)
> Grr, this is all so ugly.
> 
> Would it be possible to get GtkWindow out of the loop here, at least for the
> cases where we are not force by a gtk_drag_set_icon_widget call ? We're
> mainly using gtk_drag_set_icon_surface/pixbuf/default in GTK+, the one
> exception being GtkNotebook, and we should really rather fix that.

We're clearly hitting the limits of the hardcoded_window hack. I guess It'll be
cleaner overall to expose the drag icon wl_surface on wayland-only api, and
have some gdk_wayland_window_foreign_new (wl_surface*) for these cases where we
can avoid window widgets. I'm concerned that we can't behave properly for the
gtk_drag_set_icon_widget cases though...

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-bugs/attachments/20150501/2ca5860f/attachment.html>