<html> <head> <base href="https://bugzilla.gnome.org/" /> </head> <body> <div> <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#c6">Comment # 6</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 <a href="page.cgi?id=describeuser.html&login=mclasen%40redhat.com" title="Matthias Clasen <mclasen@redhat.com>"> Matthias Clasen</a> <pre>(In reply to Carlos Garnacho from <a href="show_bug.cgi?id=748763#c5">comment #5</a>) > (In reply to Matthias Clasen from <a href="show_bug.cgi?id=748763#c3">comment #3</a>) > > Review of <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> <a href='review?bug=748763&attachment=302730'>[review]</a> [review] [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 <a href="show_bug.cgi?id=748763#c4">comment #4</a>) > > 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... May be possible to hack those using gtk_widget_draw, like we do the magnifier in GtkInspector ?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>