[racket-dev] update on reimplementing GRacket

At Sat, 12 Jun 2010 22:06:06 -0400, Sam Tobin-Hochstadt wrote:
> On Sat, Jun 12, 2010 at 9:57 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> > 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
> 
> What do other GUI programs that run untrusted code do to handle this?
> For example, Firefox (and Chrome and Safari) runs untrusted JavaScript
> - can that just lock up the GUI?  Or alternatively, what does Eclipse
> do (SWT, Eclipse's toolkit, is based on gtk)?

I am not aware of a system that gives untrusted code a similar level of
GUI capability as trusted code within a single process. In web
browsers, untrusted Javascript doesn't get to create arbitrary windows
or menus at the same level as the browser. In Eclipse, plug-ins are
trusted to run in the same process, while a program being developed is
run in a separate OS process.