[Sugar-devel] [PATCH Sugar] Extend sugar-launch with more options

[Martin Abente]

Guess i need to clarify (again) that this patch only add new arguments to
sugar-launch (in order to pass an uri to browse). But sugar-launch can
already open activities, and activities can already use it to open any other
activity today.

On Fri, Jan 21, 2011 at 2:13 PM, Gary Martin <garycmartin at googlemail.com>wrote:

> On 20 Jan 2011, at 10:24, Sascha Silbe wrote:
>
> > Excerpts from Martin Abente's message of Thu Jan 20 02:51:19 +0100 2011:
> >
> >> Anyways this patch does not change what sugar-launch already does
> (right?),
> >> just gives it more options that can be useful even though we don't use
> it
> >> for what i need in upstream (whenever rainbow is back).
> >>
> >> Any good reason to not include it? :)
> >
> > Yes, there is: It encourages activity authors to start other activities
> > from within their own activities, exactly like you're going to do. We
> > shouldn't give them easy access to functionality that we already know
> > will stop working in the future.
> >
> > I'm also not convinced that this is good UI design, so I'm CC'ing Gary
> > for advice. To recollect:
> >
> > Martin would like to add an option to sugar-launch that allows
> > activities to invoke other activities (already possible) with a given
> > URI (new). Launching activities from within another activity won't work
> > on Rainbow-enabled systems (by design). The stated use case is starting
> > Browse for URLs in the activity UI.
>
> Well, it is a common UI in other operating systems, so I would not
> specifically call this out as poor from a UI stand point. There have been
> many long threads about this in the past, with folks wanting to launch
> activities from each other (common case cited is having lesson plan
> documents of some kind, that can launch the related activities as you work
> through them). However, in the discussions I remember, all of them hit the
> issue of breaching Rainbow and its desired security model. I would also be
> keen to see Rainbow back in Sugar.
>
> > My suggestion was to offer a very simple HTML widget in sugar-toolkit
> > that could be used by the activity to display the document inside the
> > running activity.
>
> Whatever the outcome of this thread, I'd love to see a sugar-toolkit HTML
> widget that activities could easily embed. The issue for activity authors
> for a longtime is that it may be easy to fork Browse and add in your own
> html content, but it is very solution brittle and your activity will almost
> certainly break on each new Sugar release.
>
>
Why we would go for embedding limited html renderers on activities when you
already have a powerful browser.


> > This is another iteration of the "online" (i.e. runtime) activity
> > documentation topic.
> >
> > Gary, what's your take on this?
>
> Yes, though I think Martin may be after this as part of his Notification
> work? I've seen one screen shot where some part of the notification text
> message was a URL link, kind'a worried me at the time (given the above
> reasons).
>
>
Yes, that is certainly a use case, and since the notification system is part
of sugar itself there should not be security concerns (the invoker is
trustworthy). Then, if the content is your concern, why would you be
concern? browse will be protected by rainbow any ways (the content is sand
boxed).

For the activities scenario, it might be possible to set the default browser
as the only available activity to be launched by another, and even add more
constraints like: once browse instance per activity at once.

Regards,
> --Gary
>
> > Sascha
> >
> > --
> > http://sascha.silbe.org/
> > http://www.infra-silbe.de/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20110121/ab1e80f8/attachment-0001.html>