[racket-dev] another status report on the new `racket/gui'

The new implementation of `racket/gui' is about as usable as my last
report a month ago, at least for Gtk and Cocoa. Bug reports are still
welcome. Editor performance has improved (thanks to Robby and Sam for
testing and feedback), but not much else changed for Gtk and Cocoa,
because I shifted my attention to Windows.


The default `racket/gui' back-end under Windows now uses Win32
directly, instead of building on Gtk. (You can still use the Gtk
back-end under Windows by setting the PLT_WIN_GTK environment
variable.) The Win32 back-end has not quite caught up to the Gtk and
Cocoa back-ends, but it's getting close.

I had hoped that the Gtk back-end might be good enough for Windows, but
there are many little problems with Gtk, and the problems get worse
when you use the latest Gtk instead of version 2.16. Also, 6MB of extra
DLLs to seemed like a bad trade for 5k or so lines of Racket code to
implement a Win32 back-end. If Windows wasn't the most popular platform
among our users, or if I wasn't already familiar with Win32, then we
probably would have gotten by with Gtk. Fortunately, implementing the
Win32 back-end hasn't been that bad. For many of the trickiest problems
(such as managing canvas refresh), solutions that I worked out in Cocoa
and Gtk carried over nicely. For many other problems, I can use
solutions developed in the old C++ code.


Here are the line counts so far on Racket code for the different back
ends, the line count for some shared GUI code, and the line count for
the shared drawing code:

 cocoa:    5284
 gtk:      5466
 win32:    5338

 comon:    1678

 drawing:  6669

I'm impressed by how close the Cocoa, Gtk, and Win32 numbers are to
each other. Although those toolkits all provide about the same kinds of
widgets (for our purposes, at least), the way that a C programmer uses
them is very different: Objective-C classes (Cocoa) versus signal
callbacks with explicit wiring (Gtk) versus a single callback function
for message handling (Win32). Maybe they're the same partly because I
built Racket constructs (such as `ffi/unsafe/objc') to make them all
about equally convenient.

Overall lines counts are about where they should be. At times, I've
been surprised by how small the counts are; 25k lines of code does not
seem like much, considering how long I've been working on them. A
factor of 3 is typical for C versus Racket, though. As a rough
estimate, each back-end previously required 25k-30k lines of C++ code,
including both GUI and drawing, where about 1/3 of each platform's code
was just for drawing. The main additional savings are in using a single
drawing library for all platforms (thanks to Cairo and Pango) and
eliminating glue code to bridge platform-specific C++ classes to
Racket.


The code is still hosted here:

   http://github.com/mflatt/gr2

Beware that I occasionally pull with `--rebase' from the main Racket
repository and push to gr2 with `--force'.