On Fri, Jun 20, 2014 at 9:01 PM, Jasper St. Pierre <jstpie...@mecheye.net> wrote:
> On Fri, Jun 20, 2014 at 11:57 PM, A. Walton <awal...@gnome.org> wrote: > >> On Fri, Jun 20, 2014 at 6:00 PM, Jasper St. Pierre <jstpie...@mecheye.net >> > wrote: >> >>> To better support Wayland with fewer copies and less drawing artifacts, >>> I've pushed some potentially breaking changes to GDK, namely around >>> gdk_cairo_create and gdk_window_begin_paint_region. >>> >>> >>> https://git.gnome.org/browse/gtk+/commit/?id=d48adf9cee7e340acd7f8b9a5f9716695352b848 >>> >>> https://git.gnome.org/browse/gtk+/commit/?id=be30e440c350f0f3e0f2572f7f3eab54ef96af0e >>> >>> With these changes, it is now illegal to call gdk_cairo_create outside >>> of a begin_paint / end_paint. This was always sketchy, and would never work >>> on Wayland anyway. If your code does this, we will print a warning and >>> return a dummy surface which won't ever be composited back into the main >>> surface. >>> >>> Additionally, it is now forbidden to call gdk_window_begin_paint_region >>> more than once. Previously, the code had a "paint stack" which tracked >>> paints, but since GTK+ never used this codepath it was never actually >>> tested and was indeed broken on Wayland due to the way the Wayland backend >>> was written. Again, we will print a warning in this case and return. >>> >>> As part of these changes, gtk_widget_set_double_buffered was deprecated >>> and removed. Again, it will never work on Wayland, as that is natively >>> double-buffered, and it would simply break there. >>> >>> I tested with some local big applications like Ardour and the GNOME >>> applications, but don't have a GTK+3 build of Firefox, LibreOffice, >>> Eclipse, or any big GTK+ apps like Inkscape or The GIMP. >>> >>> Please double-check to make sure your apps still work fine. If you have >>> a problem with any of this or I broke your apps by accident, please reply >>> and I'll try to fix it. >>> >> >> While I don't have anything negative to say about this particular patch >> series (I honestly think it's somewhat overdue), encoding knowledge such as >> this into commits and mailing list messages make it much, much harder to >> develop applications against Gtk+. >> >> None of the commits that changed this did anything to touch the >> documentation saying why this was the case and how to fix your applications >> if they're busted. "This is not allowed" should be "This is not allowed >> since [when]". The commit that removed the double buffering property should >> emit a warning if an application sets the flag to false so that application >> developers can catch this kind of thing in development. >> > > We haven't ever emitted runtime warnings for using deprecated APIs, and > I'm not sure I want to start doing that for now. Are the compile-time > deprecation warnings not enough for you? > > I'm not aware of how applications might be broken by the > gtk_widget_set_double_buffered deprecation, and the other cases had runtime > warnings attached to them. > [Commercial Developer Hat - speaking on behalf of myself and not the company] My day job is maintaining an application called VMware Workstation. The application is among one of the oldest and largest Gtk+ codebases at 15 years old, and has survived almost every major GNOME regime change from Gtk+ 1.3 to Bonobo to the D-Bus revolution to GIO to Gtk+ 3. As you might imagine, we're stuck using a few deprecated APIs (like, e.g., stock icons, of which we get thousands of warnings for alone while compiling). As such, we hit all kinds of these random issues through the ages, where subtle changes are made in Gtk+ and we spend our time tracking them down through Google and grepping hopefully through git logs. It's tiresome and it is rapidly turning my beard gray. The runtime warning would be incredibly helpful for tracking down these kinds of things in development - we build shipped versions of our application with these warnings suppressed anyways, and the GNOME team has already done(/undone ;) this in many other occasions: https://git.gnome.org/browse/glib/commit/?id=85e9455f68c6cc6093a1ede1c5f15587bba08b51 https://git.gnome.org/browse/glib/commit/?id=f2f66bfe45f41d18e7437341e5ebf4c70d815958 -Andrew Walton > >> I beg of you guys as both a commercial and open source GTK+ application >> developer, show us a tiny bit of mercy and document changes like this in >> places other than commit messages and mailing list threads. >> > > Any suggestions for where else to document them? I marked all the > appropriate functions as deprecated and changed their documentation to say > that they do nothing. I'd be happy to adjust the documentation, but I'm not > aware of anywhere else I can do it. > > Thanks for your work Jasper, >> >> -Andrew Walton >> >> >>> Thanks! >>> >>> -- >>> Jasper >>> >>> _______________________________________________ >>> gtk-devel-list mailing list >>> gtk-devel-list@gnome.org >>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list >>> >>> >> > > > -- > Jasper >
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
