[sugar] Distribute activity
Tue Feb 19 12:03:03 EST 2008
On Tue, 2008-02-19 at 11:23 -0500, Benjamin M. Schwartz wrote:
> Tomeu Vizoso wrote:
> | On Mon, 2008-02-18 at 22:37 -0500, Benjamin M. Schwartz wrote:
> |> In light of the many requests for a way to distribute arbitrary Journal
> |> I am writing an activity tentatively named "Distribute". This activity is
> |> little more than the HTTP server code from the Read activity, made more
> | Cool.
> |> Distribute should be able to open _all_ journal entries. Therefore, I
> |> like to associate it with all mime types. How can I do this, with
> |> or mimetypes.xml?
> | What do you mean by "open"? You want Distribute to appear as an activity
> | able to start with all journal entries?
> | I don't see a way of doing this
> | without hacking the journal (could be a simple hack, though).
> | Another possibility would be for the user to start Distribute as a blank
> | activity, and then choose the object to share with the ObjectChooser
> | component.
> Isn't the ObjectChooser also supposed to be filtered by mime type?
Not currently. Perhaps Michael could tell us what his plans are
regarding this, but if we are aiming for a quick hack, then it shouldn't
> | Some other people were interested in working on something similar (me
> | included), should we try to join our efforts? I remember SJ, Mako,
> | Michael, Scott and Chris showed interest at some point.
> I'm happy to work with others on this. Currently, my code is quite
> literally Read, without Evince. I cannot test it, because all the jabber
> servers are down and I'm missing one of my XOs, but I suspect it does not
> yet work.
Hmm. I think two sugar instances in the same network should work through
link local. This can be any combination of XOs or jhbuild instances.
> Ultimately, this is supposed to be a quick hack, to be replaced in future
> versions by distribution functionality built into Sugar. That makes
> design decisions (like ObjectChooser vs. launch from Journal) even more
> difficult, since the "right" answer may not be the best choice.
I understand. I see possible that the solution devised by the user
experience team is also easy to implement. I think we should have this
More information about the Sugar-devel