Re: Powerbox for SWT?

Sorry if the conversation has moved beyond what I'm responding to here.

We tamed SWT, the taming files are part of the E distribution. I'd
swear we also rewrote CapDesk, but not DarpaBrowser, with SWT; I'm not
in a position at the moment to double check this, but look for a file
with a name like capdesk.e-swt. Thomas is correct that you cannot hand
out the currentDisplay, it is a god-power. The SWT taming wraps
currentDisplay, i.e., the powerbox uses currentDisplay to create a new
Shell, and the Shell is handed to the application. This all assumes my
memory is not playing tricks on me :-)

--marcs

On Sun, Jun 27, 2010 at 6:10 AM, Thomas Leonard <[email protected]> wrote:
> I had a go at integrating 0install with the new E loader stuff. This
> turned out to be quite easy: a package's dependencies given in its
> feed turn into loaders in its environment. The idea is that you do
> e.g.
>
> $ e-install Editor http://example.com/Editor
>
> This creates a directory called 'Editor' with the program's
> configuration, which can be run as:
>
> $ ./Editor/AppRun
>
> The program gets <file:Editor/data>.shallowReadOnly() as a place to
> store configuration and state.
>
> The (read-only) program code lives outside the directory, in the
> 0install cache, allowing it to be shared between programs, users, etc.
> Selecting versions, choosing dependencies, checking for updates etc
> all happens through 0install as normal.
>
> Now, I'd like to run programs in a restricted environment by default.
> I thought I could just reuse the caplet stuff (e.g.
> powerboxControllerMakerAuthor), but it all seems to be Swing-based. As
> I understand it, SWT is now the preferred toolkit for E:
>
> "E will continue to support Swing, but we expect to increasingly
> support and emphasize SWT as we increasingly deemphasize Swing. In
> particular, due to its size, we don't expect to ever properly tame
> Swing, and so locally untrusted code (including all caplets) can never
> be given access to the Swing API."
> (http://www.erights.org/download/swt/index.html)
>
> Is there any useful existing code I can use? It's not obvious to me
> what subset of privilegedScope I should give out. For example, stdout,
> stderr and print are fine. I think interp is OK too. "makeCommand" and
> "rune" probably not.
>
> For SWT, it's even less clear. I guess I shouldn't be giving out
> currentDisplay, as then the program can create as many windows as it
> likes and with any title. I tried providing a powerbox that allows
> creating a new shell and returns a proxy to it. But all kinds of
> operations (e.g. listening for dispose, adding a menu bar, adding a
> drop-down menu) require access to the shell, e.g.
>
> def menuBar := <widget:makeMenu>(shell, SWT.getBAR())
> def fileMenuHeader := <widget:makeMenuItem>(menuBar, SWT.getCASCADE())
> fileMenuHeader.setText("&File");
> shell.setMenuBar(menuBar)
> def fileMenu := <widget:makeMenu>(shell, SWT.getDROP_DOWN())
> fileMenuHeader.setMenu(fileMenu)
>
> Do I need to provide my own version of all of these? Also, I need
> something to provide Open and Save dialogs. How does copy-and-paste
> work? Has someone solved this already?
>
> Thanks,
>
>
> --
> Dr Thomas Leonard               ROX desktop / Zero Install
> GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
> GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA
> _______________________________________________
> e-lang mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/e-lang
>