Is it possible to disable "sharing" for an Activity?

Eben Eliason eben at
Mon Feb 2 18:41:54 EST 2009

I think that the addition of a new property in the file
would be logical here.  Make it an integer indicating the maximum
number of supported participants.  "Unshared" activities would report
'1', activities like video chat (with technical limitations) or chess
(with obvious player limits) might specify 2, and others could specify
another cap based on resource requirements and/or a constant to
indicate an unbounded number.

That number could be used both to show/hide the sharing controls (in
the activity or elsewhere) for that activity, and also help keep the
participants list at a manageable size for the given activity.
Limitations are natural, and activity specific; it's not reasonable to
expect all collaborative activities to scale in the same way.

Scott (CC'd) has already come up with some really nice proposals for
adding VNC as an alternate colaboration mechanism for all activities.
In my mind, this would work perfectly with the above scheme, whereby
any activity that already has max_participants in it could be viewed
in that manner.  Scott, could you point to any materials you've
already written up on the matter?  Would you have time and/or desire
to assist others who are interested in taking on such a feature?  I'd
love to see this happen, myself, and have given some preliminary
thought to the UI already.

- Eben

2009/2/2 Carol Farlow Lerche <cafl at>:
> I'm guessing someone has already suggested this on some list or other, but
> in my experience kids like to watch over each other's shoulder, and a
> default collaboration of "everyone watches, one person types" vnc would in
> my opinion be the 80 of a collaboration 80-20 rule.  I think this ought to
> be implemented in the sugar infrastructure, and then let activities that
> have an obvious extended collaboration (such as two person games or shared
> authorship documents) do something more.
> 2009/2/2 Wade Brainerd <wadetb at>
>> There might be something in the Sugar Almanac,
>> see for a link.
>> Alternately, an example of how to disable sharing is here:
>> Note to Sugar toolkit guys, I'd love to have a formal API to indicate
>> "collaboration not supported".
>> Best,
>> Wade
>> On Mon, Feb 2, 2009 at 6:10 PM, James Simmons <jim.simmons at>
>> wrote:
>>> First, I want to praise whoever put together the Sugar packages for
>>> Fedora 10.  After struggling with Xubuntu and with sugar-jhbuild on
>>> openSUSE I finally have a sugar test environment where everything seems
>>> to work!  It was well worth wiping out my openSUSE install and starting
>>> over with a new distribution.  I'll probably do the same to my Xubuntu
>>> box eventually.
>>> Second, now that I have this I want to perfect collaboration on my two
>>> Activities, Read Etexts and View Slides.  Unfortunately, I am convinced
>>> that collaboration in View Slides that involves sending large Zip
>>> archives over the network is not and never will be practical.  What I'm
>>> thinking about now is making the person "sharing" a slide show see only
>>> the image being viewed on the XO that has the full presentation.  The
>>> master XO would page through the slides and those sharing would follow
>>> along.  I'm not sure that's practical, either.
>>> While I'm figuring this out, what I'd really like to do is release a
>>> version of View Slides that has no collaboration at all.  This would
>>> mean hiding the control on the Activity toolbar that supports
>>> collaboration.  When I figure out something intelligent to do with
>>> collaboration I'll restore it.  Is this possible, and how would I go
>>> about doing it?
>>> Thanks,
>>> James Simmons
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at
>> _______________________________________________
>> Devel mailing list
>> Devel at
> --
> "Don't think for a minute that power concedes. We have to work like our
> future depends on it."  -- Barack Obama
> _______________________________________________
> Devel mailing list
> Devel at

More information about the Devel mailing list