Hi; On 31 December 2016 at 16:03, Richard Shann <rich...@rshann.plus.com> wrote: > On Sat, 2016-12-31 at 15:44 +0000, Emmanuele Bassi wrote: >> Hi; >> >> >> Deprecations will only impact you if you want to update the code base >> to the next major API bump. > > Yes, it is to be ready for GTK4 that I am working on these. > >> Since you don't have or want to commit resources to do so, > > I am committing my meagre resources to this.
I'm sorry to say this, but then you'll likely need more than just replacing deprecated API. In some cases we do expect changes in how applications are designed, if they want to keep up with new environments and human interface guidelines. That's also why we generally expect mature, low-maintenance applications, to bundle a copy of GTK+ if they rely on a specific API. On Linux, you can look at using Flatpak to build and distribute your application. > I have just got to this > one: > > gtk_widget_reparent() is deprecated. > > Following the suggestion it seems this can be avoided with this: > > #define gtk_widget_reparent(w,p) > (g_object_ref(G_OBJECT(w)),gtk_container_remove(GTK_CONTAINER(gtk_widget_get_parent(w)), > w),gtk_container_add(GTK_CONTAINER(p), w),g_object_unref(G_OBJECT(w))) More or less, yes. The reparent() call was a call needed to avoid costly mapping/unmapping of real X11 resources, back in the day; once we stopped using real windowing system resources for each widget, reparent() relied on side effects and widget authors always doing the right thing, which exposed a bunch of bugs every time somebody wrote a new widget. So the idea is to always remove and add a widget, instead of reparenting it. This way, all code paths get consolidated. > I think it would make developers of applications feel happier if some > indication was given as to why something was deprecated so as to guide > them in re-working the code. Please, feel free to file bugs when a deprecation does not have a suggestion. We usually try to be explicit, but sometimes it's either complicated or we simply forget. > (I'm assuming there's some reason that this > macro is not simply put into a header). Because macros are not bindable anyway, so we generally don't use them as API. The only exceptions are the type system macros, but we are kind of replacing them with inlined functions, and those are implemented by other means in language bindings anyway. We also do not provide a "compatibility layer" because now we'd have to deal with the bugs in two separate layers, and the bad interactions with applications and toolkit. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
