I think that the addition of a new property in the activity.info 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 <c...@msbit.com>: > 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 <wad...@gmail.com> >> >> There might be something in the Sugar Almanac, >> see http://sugarlabs.org/go/ActivityTeam/Resources for a link. >> Alternately, an example of how to disable sharing is here: >> >> http://git.sugarlabs.org/projects/math/repos/mainline/blobs/master/mathactivity.py#line75 >> 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.simm...@walgreens.com> >> 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 >>> de...@lists.laptop.org >>> http://lists.laptop.org/listinfo/devel >> >> >> _______________________________________________ >> Devel mailing list >> de...@lists.laptop.org >> http://lists.laptop.org/listinfo/devel >> > > > > -- > "Don't think for a minute that power concedes. We have to work like our > future depends on it." -- Barack Obama > > _______________________________________________ > Devel mailing list > de...@lists.laptop.org > http://lists.laptop.org/listinfo/devel > > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel