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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list