Re: Powerbox for SWT?

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.


Hi Thomas, what is 0install?




> 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)
>

Yes. As a result of the DarpaBrowser security review, we realized that we'd
need more time than we were able to find (or get anyone to pay for) to do an
adequate taming of Swing. It's just too large and messy. At
e/src/esrc/scripts/capDesk.e-swt MarcS did start to convert capDesk from
AWT/Swing to SWT, but IIRC did not get to the powerbox/caplet logic before
the effort ran out of steam.



>
> 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.
>

It depends on your goals. Returning to AWT/Swing-based capDesk as the
example, if you intend newly installed apps to resemble capDesk's default
caplet launch with no install time endowments, then you would give very
little, not even stdout, stderr, and print. Giving an installed app any more
than that at install time should require some sort of user authorization, as
in the capDesk install dialog.



>
> 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?
>

MarcS?


>
> 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
>



-- 
Text by me above is hereby placed in the public domain

   Cheers,
   --MarkM

_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang