Re: Questions about GTK3

[Matthias Clasen <matthias clasen gmail com>]

On Sat, Sep 4, 2010 at 4:56 AM, Benjamin Otte <otte gnome org> wrote:
> So,
>
> I've been busy the last few days making all expose events use Cairo
> contexts exclusively and while doing that had to wander into the
> cobwebbed regions of Gtk code and other exciting places. While doing
> that a few questions about general cleanup occured to me:
>
> 1) How to handle old-school widgets
> We have widgets that are in real need of a makeover. They look like
> they haven't been touched this century. So far, I stumbled across
> GtkRuler - see https://bugzilla.gnome.org/show_bug.cgi?id=613942#c2 -
> should I expect they get a clean redone API for 3.0 or should I expect
> they stay as they are?

One thing is for sure: You shouldn't expect anything to get 'cleanly
redone' unless you are willing to put work into it... unfortunately,
we don't have huge hordes of code refactorers toiling away in secret
anywhere.

For the concrete example of GtkRuler, we've come pretty close to
dropping it, and we could still decide to do so.

> 2) "no needless API churn"
> Matthias mentioned this as a general rule on IRC yesterday. Do we have
> any agreed-on idea what we mean by that? Of course everybody thinks
> his changes are the most important and certainly not needless, so
> agreeing on what is and is not needless might often be somewhat hard.
> Some examples:
> - GTK3 will likely not have GdkDrawable anymore (useless class after
> pixmap removal), but it has a lot of useful functions that would need
> to be moved to GdkWindow, like gdk_drawable_get_size() =>
> gdk_window_get_size(). Do we just keep the old name? Add a new version
> and deprecate the old one? Only provide the new one?
> - 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?

Let me try to clarify what I meant with needless API churn.

The two examples you give are pretty good here: the rendering cleanup
work has really big benefits in terms of cleaning up our code base,
and making future work easier / possible. This comes at a modest cost
for applications (since it turns out that relatively few apps were
making heavy use of GdkGC or GdkPixmap).

Removing GtkHBox on the other hand, will have almost zero benefit for
our code base. Its a self-contained source file with no complications
and very small api. But it will have a huge impact on applications,
since hboxes are very widely used.

Therefore my instinct is to say: lets push ahead with the rendering
cleanup for GTK3, but keep the harmless H/V variants for now. Also, as
Havoc recently proposed, we may be able to do better than deprecating
GtkH/VBox in favour of GtkBox, by deprecating all boxes _and_ GtkTable
in favor of a more flexible grid widget.

> 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 don't think anybody is. For GtkItem, folding the signals into
GtkMenuItem should be a pretty painless operation, and might be a nice
cleanup. Not sure about GtkEditable.

> 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?

I think it this needs to be decided on a case-by-case basis, but I
would tend to say that we should prefer understandable code and
documentation.
If we can clearly identify what the workaround was for, it might be
good to mention it in the release notes, and explain how to do things
properly.

The example you cite was to preserve some assumptions made by theme
engines, and I am not as worried about breaking theme engines as I am
about breaking applications.

> 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 we need to focus on doing cleanups and api additions now that
will enable us to work on these things during 3.x.