On Sat, 2016-12-31 at 20:10 +0000, Emmanuele Bassi wrote: > 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.
I haven't thought of trying to do either of those - I'm happy if people with a computer with keyboard, mouse and one (preferably two) large screens can use the program - I'm not sure if touch screens, virtual keyboards etc would be feasible for this sort of work. > > 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. Thanks for this pointer - I'm not sure how we create binaries for GNU/Linux at the moment, but I'll flag this up as a possibility. > > > 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. Ah, a macro wouldn't be a good thing, I see. Though I'm still not so clear why the implementation of the function was not just simplified to the above code when the fancier stuff had become unnecessary. No need to invoke the deprecation machinery. Perhaps it's in the interest of a shorter, "cleaner" API, or is there some (conceivable) type of GtkWidget for which the above code would not work? Richard _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
