Gtk 2.0 (was Re: Tracking object deletion)

[Raph Levien <raph acm org>]

On Fri, 12 Dec 1997, Kenneth Albanowski wrote:
> I think you should try to avoid having Gtk 1.0 (used by GIMP) and Gtk 2.0
> (which has all the new features, but GIMP doesn't understand). This is the
> sort of thing which gives Tcl/Tk users fits. How that can be arranged, I'm
> not sure. 

Well, one way to ensure that is to retrofit Gimp 2.0 to use all the cool 
new stuff.

I think we're going to have to start thinking seriously about the 2.0 
versions of both Gimp and Gtk. My personal obsession within Gtk is to 
make handling of huge scrolling windows work well - currently a 
significant weakness of Gtk.

Presently, I deal with this weakness by defining my own parallel widget 
set, Gzw (Gzilla widgets). It's not too bad, because I only need a small 
number of widgets. The only substantial ones are gzw_page for displaying 
the Web page, gzw_table for HTML tables, and eventually gzw_image for 
displaying images. In each case, there is some overlap with an existing 
Gtk widget, but also a lot of new functionality that the Gtk widget 
doesn't provide. For things like buttons, entries, and other form 
elements, I just embed a Gtk widget.

This seems like a good provisional approach, but it makes me uncomfortable
in the long term. Already, we're starting to see a number of applications
that need large scrolling implemented as monolithic widgets, including
gtk_text, Jay Painter's CList, and of course Gzilla.  More applications
are sure to arise, including a spreadsheet. In addition, I'd say speeding
up the list display in the file selector should also be a major
performance priority. I see a lot of duplicated work, limits to
functionality (for example, the CList can handle embedded pixmaps but not
embedded Gtk widgets), and in general a lack of modularity. 

Long term, I think the best solution is to make changes to Gtk that will
enable large-scrolling for all Gtk widgets. This clearly seems like the
easiest approach for new programmers to understand. However, it's
certainly not possible to integrate large-scrolling without breaking
backwards compatibility with existing Gtk code. I think it is possible to
do it in a way that requires fairly minimal rework, but it's still a
hassle. 

It seems to me that the Linux community deals with about one major 
compatibilty-impared upgrade a year, with ELF and glibc being the most 
recent. I don't exactly like it, but this might be the best path for Gtk 
as well.

Raph