Release 8.2.0 -- pls add critical features

[Eben Eliason]

On Thu, Jul 3, 2008 at 1:39 PM, Morgan Collett <morgan.collett at gmail.com> wrote:
> On Thu, Jul 3, 2008 at 19:30, Daniel Drake <dsd at laptop.org> wrote:
>> Greg Smith wrote:
>>> I'm also not aware of any feasible design proposal which might address
>>> your request. You need a precedent or engineering level suggestion to
>>> move this forward. Is this possible in Firefox at all?
>>>
>>> I know that IE tries to open certain types of documents within the
>>> browser. It ties in a set of editing capabilities without exiting the
>>> browser, but its not the same as opening the document in the
>>> application. I don't know the technology behind it (maybe Mime Types?).
>>> If that is what you are looking for it will require a lot of work which
>>> I believe needs to come from Firefox.
>>
>> This part is actually quite easy. We don't use firefox, but we use the
>> same engine, embedded into a sugar app. It's easy for the parent
>> application to intercept URL requests before the engine goes off and
>> processes them, so it's easy to invent a URL scheme such as activity://pippy
>>
>> The hard part is dealing with Rainbow, because Browse runs under the
>> constraints of rainbow which probably prevents us from making one
>> activity directly launch another in any sane way.
>
> What we have now is show_object_in_journal, which activities can use
> to ask Rainbow to show a journal object. The activity creates a
> journal object, and then calls that resulting in Journal displaying
> that object. You can then resume / instantiate it.
>
> This is how Chat opens URLs in Browse. I imagine that it could be used
> to create a journal object corresponding to the activity type you want
> to open. However, where a specific mime type can be opened with
> multiple activities, you could choose to resume any one of them. So
> this doesn't guarantee a specific activity will be launched.

The default association can be set though, I believe.

In any case, this is quite similar to the behavior which I'd rather
support, which is a Sugar "launching service" of sorts through which
an activity can pass a URL (or file handle? or object id? or bundle
id?) to Sugar, which will display a modal alert asking the user to
choose what to do with it (if it is an activity, launch would likely
be the only option; if it were an object, the option to act on it with
any number of activities might be present.)  The net result is quite
similar, but the action can happen in context and thus feel much more
direct.  It can also be canceled.  In all cases, Sugar is responsible
for the dialog and the resulting action, so Rainbow isn't in the way.
In a partial sense, this also solves the "default handler" issue,
since the option is always presented to choose any supporting activity
to, for instance, open a URL clicked on in Chat.

Further thought could go into such a service in the future to create
powerful flows of data among activities. Perhaps in the future this
type of system can be used to pass the result of a "spawned" activity
back to the "spawner", such as to allow modification of an SVG icon in
a future Draw activity, from within a Develop project.  This goes one
step further than the manual use of the clipboard in providing
inter-activity explorations.

- Eben