Re: gtk_dialog_get_action_area() deprecation

[Emmanuele Bassi <ebassi gmail com>]

Hi;

On 31 December 2016 at 16:03, Richard Shann <richard 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]