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'. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
