Re: libgtk3deprecated (Re: About GTK+ 3.0 and deprecated things)

[Tim Janik <timj gtk org>]

On Thu, 17 Jul 2008, Sven Herzberg wrote:

> Hi,
>
> Am Donnerstag, den 17.07.2008, 20:18 +0200 schrieb Tim Janik:
> > On Thu, 17 Jul 2008, Martin Meyer wrote:
> > > 2) Is it entirely possible from a gtk perspective to have all that
> > > code detached from gtk-core and placed in a different library? Are
> > > there any deprecated things that this would *not* work for? Maybe we
> > > can detach as many as possible and leave the rest in place for now.
> >
> > Complete deprecated widgets should be fairly easy to separarte,
> > single deprecated functions that some components may have can be
> > hard to impossible to move when the implementation requires
> > access to internals.
>
> But this could be worked around with a strange compile setup, right?
> With something like this:
> ~/sources/gtk+
> ~/sources/gtk-deprecated
> and gcc -I$(top_srcdir)/../gtk+/gtk
> to access potential gtkwidgetpriv.h, right? Would mean "recompile with
> every source change to gtk+" but if some (many?) people depend on this,
> I think they can easily distribute the burden of maintaining a parallel
> version.

There is no point in having libgtk3deprecated access gtk+ internals and
not go through public interfaces only. If we did that, we'd simply preserve
the maintenance burden on Gtk+ internal definitions. We really want to
get rid of a bunch of stuff, be free to refactor structures and internal
methods to implement new things cleanly. If libgtk3deprecated kept acessing
and relying on internals it'd either constantly break or hinder us on doing
reorganisations.

Also, this'd tie release cycles and maintenance resources of libgtk3deprecated
closely to Gtk+ again. The main point in seperating deprecated code is to
load off the core team though, so application developers or distributors
that still have an interest in deprecated components can take over its
maintenance as long as that's necessary.

> > A closing word on the library name, since this'd be an ABI break,
> > such a library only makes sense for Gtk+-3.0 (or 2.99.0) and should
> > probably advertise that it ships deprecated Gtk+ stuff. So the best
> > name is probably libgtk3deprecated for this (there could possibly
> > be a libgtk4deprecated as well at some point).
>
> Well, so GTK+ 4.0 could be accompanied by these two:
> libgtk3deprecated-4.0.so
> libgtk4deprecated-3.0.so
> Right?

I'd guess that if deprecated 2.x components that landed in libgtk3deprecated
are still required when a libgtk4deprecated is released, they could
possibly need some porting and simply be included as real parts of
libgtk4deprecated. This is highly speculative though and can be considered
when we have the Gtk+-4.0 discussion. We're not quite there yet ;)

> Regards,
>  Sven

---
ciaoTJ