<html>
<head>
<base href="https://bugzilla.gnome.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - warnings when starting drag from GtkEntries"
href="https://bugzilla.gnome.org/show_bug.cgi?id=748763#c5">Comment # 5</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - warnings when starting drag from GtkEntries"
href="https://bugzilla.gnome.org/show_bug.cgi?id=748763">bug 748763</a>
from <span class="vcard"><a href="page.cgi?id=describeuser.html&login=carlosg%40gnome.org" title="Carlos Garnacho <carlosg@gnome.org>"> <span class="fn">Carlos Garnacho</span></a>
</span></b>
<pre>(In reply to Matthias Clasen from <a href="show_bug.cgi?id=748763#c3">comment #3</a>)
<span class="quote">> Review of <span class=""><a href="attachment.cgi?id=302730&action=diff" name="attach_302730" title="window: Avoid destroying the hardcoded window">attachment 302730</a> <a href="attachment.cgi?id=302730&action=edit" title="window: Avoid destroying the hardcoded window">[details]</a></span> <a href='review?bug=748763&attachment=302730'>[review]</a> [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 ?</span >
Mostly, except destroying the window...
<span class="quote">>
> It would be nicer if we could still unconditionally chain up - just clear
> out the hardcoded_window first ?</span >
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 <a href="show_bug.cgi?id=748763#c4">comment #4</a>)
<span class="quote">> 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.</span >
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...</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>