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