Re: Questions about GTK3

[Kristian Rietveld <kris gtk org>]

Hi Benjamin,

Great that you bring this up for discussion.

I think another trade-off you want to make in this discussion is what
amount of backwards compatibility you want to have with GTK 2.x.  In
the original GTK+ 3 plans a few years ago it was argued to have a very
smooth migration path by limiting API removal to deprecated API so
that existing applications can be very easily ported.  (With an
exception for theming, since people really wanted to see that fixed).
There are obviously arguments in favor of this (easy porting), but
also against, typically: if you want to break ABI, then make a good
use of it.

The plans have seen changes and discussion and I cannot immediately
recall what has been decided in the end.  I think that the additional
clean up that is going on around GdkGC (which has been long
deprecated) is great, that this is requiring some adaptations in
non-deprecated code is something that we have to take for granted.  I
am pretty much in favor of all other rendering clean up that is being
proposed (especially as an OS X backend hacker :), since it makes the
GDK/GTK+ code base significantly easier and I think more flexible as
well.  However, each further modification that we make, will come at a
cost of making applications impacted by that harder to port.  Even
though GTK+ 2.x will not go away, it is likely in best interest of
both GTK+ developers and the application developers to have
applications make the switch to GTK+ 3 better the sooner than the
later.

So basically I am arguing that we should proceed with caution for
larger scale changes of things that currently are not deprecated, and
really think about the impact in extra work involved in porting
applications.  I am afraid that changes like removing HV classes (even
though it would be great to clean up!), removing window widgets, etc.,
will make it much more complex and time consuming to port applications
while application developers are currently not anticipating that.
Either way, if we are to make such changes, we better make it known
ASAP.

Some more comments below:

On Sat, Sep 4, 2010 at 10:56 AM, Benjamin Otte <otte gnome org> wrote:
> - Same for GtkHFoo/GkVFoo classes. They're absolutely useless now that
> we got GtkOrientable, but removing them breaks API. Do we just remove
> them? Do we only keep the functions from it that are actually used? Do
> we deprecate but keep the functions? Or do we even keep the classes?

Like I mentioned above, I think as a clean up it would be great, but
it comes at a massive cost for porting applications (unless that can
be automated somehow, but that might not always be wished).  IIRC
there have been discussions about this earlier on this mailing list.

> 3) Cleanup of useless classes
> With the removal of the deprecated widgets, we now have objects in the
> widget hierarchy that make no real sense anymore (i.e. GtkItem or
> GtkEditable). Should they be removed? Should they be kept? Is anyone
> working on that or intending to?

I am wondering about the case if such a class is in the middle of a
class hierarchy (e.g. GtkMisc).  What amount of breakage would that
introduce?  Or would things continue to compile more or less fine?

> 4) How to treat workarounds?
> Example: http://git.gnome.org/browse/gtk+/tree/gtk/gtkentry.c?id=e6da33a302a51783777e8da41c680cdf4dc783eb#n3292
> There's sections of code that say 'work around problem foo in barapp"
> and then do something very weird. We could just remove these and end
> up with clean code, but would make barapp harder to port to GTK3. Or
> we could keep weird behavior. Do we have any preferences here?

Hard one.  Fixing up such things can trigger really obscure bugs in
applications.  From what I remember, I have a couple of functions or
cases in tree view where I would also want to change behavior.  But
also such changes can trigger completely different behavior in certain
applications, which is why such changes were for me usually a big
no-no in 2.x.

If we decide to fix such cases (which might not be a bad idea when
breaking ABI, I don't know what would be a better moment to make such
changes), we should make sure to have detailed documentation on each
of these changes.

> 5) How proactive are we?
> In the rendeirng-cleanup work we've talked about switching widgets to
> a no-window drawing model. Unfortunately, some APIs are not very
> helpful for that approach (i.e. GtkEntry leaking windows via
> gtk_entry_get_icon_window ()). Should we look at cleaning this up
> before 3.0? Or do we wait until we actually want to remove windows?
> I'm sure there's similar problems for other efforts. How are things
> handled there?

I think this again really depends on how much you want to get out of
the current ABI break, and whether there are plans to break ABI more
frequently in the future.  The original GTK+ 3 plans called for ABI
breaks at certain intervals (which again has arguments in favor and
against).  With that you could envision a model of operation of
deprecating the get_window() functions first, prepare for migration to
a no-window drawing model in the meantime, and 2 releases later you
remove the get_window() functions and make the switch.  Difficult to
manage, but gives application developers some more time to adapt.


To conclude, I think it's clear that there is a big trade-off between
whose life we make easier, our life as library developers or the life
of application developers using our library.



regards,

-kris.