[racket-dev] update on reimplementing GRacket

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Sat Jun 12 21:57:28 EDT 2010

At Sat, 12 Jun 2010 21:43:09 -0400, Sam Tobin-Hochstadt wrote:
> First, do the difficulties you've had integrating eventspaces with
> modern toolkits suggest that perhaps eventspaces should be designed
> differently?

Not as far as I can tell. The fundamental problem is being able to use
some GUI elements (e.g., DrRacket's GUI) while a callback associated
with another set of GUI elements might be blocked. GUI toolkits like
Cocoa and Gtk2 don't support that in any simple way that I see.

> Second, how much will the distinction between gracket and racket exist
> once gracket2 is implemented? 

On platforms with a distinction between GUI and console applications
(Windows and to a lesser extent Mac OS X), there's still a role for a
GUI-mode executable in addition to a console-mode executable. Starting
`racket' will not prevent you from using `racket/gui/base', though.

> Will there still be a concept of a "gui
> namespace", for example?

There must be only one instance of `racket/gui/base' in a Racket
process, because various global hooks must be set for GUI toolkit and
the Racket run-time system. So, it will still be important to attach
`racket/gui/base' to another namespace where you want to use it.

> Third, to what degree will the underlying toolkit be exposed in a
> gracket-compatible way?  For example, will it be possible to use
> gtk-specific methods to implement custom dialogs on X?

I don't know. At best, directly using the underlying toolkit would be
unsafe with respect to eventspaces, but maybe that won't be much
different than the unsafety of using the FFI.

Posted on the dev mailing list.