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.
