On Thu, Jul 3, 2008 at 1:39 PM, Morgan Collett <[EMAIL PROTECTED]> wrote: > On Thu, Jul 3, 2008 at 19:30, Daniel Drake <[EMAIL PROTECTED]> 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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel