Re: Questions about GTK3

[Havoc Pennington <hp pobox com>]

I'd say a useful emphasis is to focus on enabling deprecation by
adding "the new way," rather than on actually removing the old way.

e.g. on my pixbuf patch, the changes allow dropping any actual use of
the old format. But going on a "compile with
GDK_PIXBUF_DISABLE_DEPRECATED" spree just in pixbuf and gtk without
considering apps, would take for freaking ever and can be done
post-3.0. Also making gdk-pixbuf use cairo in most cases internally
can be done post-3.0

on the "get rid of GdkWindow," there's incremental no-pain-to-apps steps like:

- add an API to get events without a window (can still ship GTK here)
- add an API to get do clip and scroll without a window (can still
ship GTK here)
- fix up public APIs that require a window (textview border windows,
entry icon window) (can still ship GTK here)
- drop input-only windows from no-window widgets that get input (can
still ship GTK here)
- make more window widgets into no-window widgets, can still ship GTK
with 0,1,2,3...N of these fixed
- actually remove GdkWindow (too harsh to do in 3.0 ... but it could
be marked deprecated ... and in any case all of the above work is
still useful even if GTK ships before reaching this)

So much that can be done step-by-step while keeping a shippable lib at
all times, without ever leaving a pile of parts on the floor, or
breaking apps much.

On the widget padding path, I think the goal would be to add the
padding/alignment to widget; but the old stuff would all still be
there, marked deprecated. New variants of box_pack and other methods
that take padding/align args could be added. Actually removing
GtkMisc, GtkAlignment, and box padding would be too radical without a
few years for people to adapt.

If there's a bunch of deprecated code and over future release cycles
that deprecated stuff starts getting purged from GTK itself and other
major libs and apps, then already on many "embedded" type platforms
people can start ripping the deprecated out of their build of GTK, and
designing apps that rely on no child windows, things like that. For
GNOME itself to clean up disk usage would take a GTK 4.x, but it will
arrive someday.

Havoc