Re: [Sugar-devel] Is it possible to disable sharing for an Activity?
On Thu, Feb 5, 2009 at 3:17 PM, John Gilmore g...@toad.com wrote: 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. If robust activity sharing is ever going to make it past the Sugar GUI barrier, adding sharing properties to a Sugar-specific config file will just create an issue that needs cleaning up later. Wouldn't it be better to add a function or argument to the sharing API, that an application can use to limit the number of participants sharing the application? The world and the kids would be better off with e.g. a GNU Chess/ XBoard that's able to share on any platform, rather than a Chess Activity that only shares under Sugar. +1. And if and when sharing is maintained upstream from Sugar, we all win... until then, we need to keep pounding away at the Sugar bits. John http://www.tim-mann.org/xboard.html ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Is it possible to disable sharing for an Activity?
I think this project often makes the perfect into the enemy of the good. Consequently we end up having less collaboration than, e.g., any system in the last 10 years that could install vnc server, while claiming that collaboration is a principal focus of the project. On Mon, Feb 2, 2009 at 3:34 PM, Wade Brainerd wad...@gmail.com wrote: I think some simplistic automatic collaboration being built into Sugar, has been discussed, possibly even prototyped. Just a matter of engineering motivation/time perhaps. -Wade On Mon, Feb 2, 2009 at 6:30 PM, Carol Farlow Lerche c...@msbit.comwrote: 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 -- Don't think for a minute that power concedes. We have to work like our future depends on it. -- Barack Obama ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Is it possible to disable sharing for an Activity?
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
Re: [Sugar-devel] Is it possible to disable sharing for an Activity?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: 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. OK, but as an Activity author I might like to specify that cap at runtime, depending on many things, such as the size of the document. I might even want to let the initiator choose the number of participants. I think we should also have a runtime API, so that the cap that can be varied at any time. In fact, it might be nice to have a a generic solution for defining config variables that can be controlled either statically or at runtime. We have mentioned a wide variety of such variables, including things like whether screen rotation is supported. 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. I don't see why any Activity should be excluded from such VNC sharing, regardless of max_participants. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmHkNIACgkQUJT6e6HFtqQBlQCdF4AhUy+NWkwYqVR/qMyl/m2H UpAAniXtXxWRQuM8o8iqtiyJ0uB4o05Z =BI5d -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Is it possible to disable sharing for an Activity?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: On Mon, Feb 2, 2009 at 7:33 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: 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. I don't see why any Activity should be excluded from such VNC sharing, regardless of max_participants. Of course not. I didn't mean to imply such a limitation; only that the VNC solution would be the /only/ option after some participants limit was reached. That is, you could either Join or Watch any shared activity, but the Join option would disappear once full...Watch would remain. It's possible we'd have an upper bound on the number of people who could watch as well, but I don't think that's an activity-specific parameter. Oh! That's beautiful. Let's do that. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmHl60ACgkQUJT6e6HFtqTXXACdH1WGy6vrO8JibUPy+AbPXQs0 5X0An1Y3zcLXrr3kP9itQ8pUHZ7ujjpD =YKXn -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Is it possible to disable sharing for an Activity?
On 3 Feb 2009, at 01:02, Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: On Mon, Feb 2, 2009 at 7:33 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: 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. I don't see why any Activity should be excluded from such VNC sharing, regardless of max_participants. Of course not. I didn't mean to imply such a limitation; only that the VNC solution would be the /only/ option after some participants limit was reached. That is, you could either Join or Watch any shared activity, but the Join option would disappear once full...Watch would remain. It's possible we'd have an upper bound on the number of people who could watch as well, but I don't think that's an activity-specific parameter. Oh! That's beautiful. Let's do that. I don't mean to rain on the parade here, but am I the only one who finds VNC slow even on high spec equipment over a dedicated broadband connection? I do use it occasionally for remote support, so it does have its uses – but a handful of XOs in the same wireless spectrum? Ouch. From a technical stand point VNC is going to be almost always more memory hungry, more cpu hungry, and more bandwidth hungry than most activity collaborations, seems to be an overly hopeful collaboration method to fallback on. Happy to be proven wrong, and I guess it could be a Sugar feature not really intended for XOs. Regards, --Gary - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmHl60ACgkQUJT6e6HFtqTXXACdH1WGy6vrO8JibUPy+AbPXQs0 5X0An1Y3zcLXrr3kP9itQ8pUHZ7ujjpD =YKXn -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Is it possible to disable sharing for an Activity?
On Mon, Feb 2, 2009 at 9:26 PM, Gary C Martin g...@garycmartin.com wrote: Happy to be proven wrong, and I guess it could be a Sugar feature not really intended for XOs. Let's let the flowers bloom: I don't doubt that there are many ways to make *better* collaboration, on an activity-by-activity basis. But VNC is something that can be created as a common baseline. Let's start by doing that, and improve it on a case-by-case basis, instead of having *no collaboration* as our baseline. FWIW, I second Carol's comments: VNC works quite nicely on fast local networks, such as direction connections between XOs, and I've used it on clients as simple as a Palm Pilot and a Mac SE/30. Reducing graphic busy-ness and palette size helps a lot! Also: don't run xvncviewer remotely: VNC is network efficient, but the way its X client uses the network between it and the X server is definitely *not*! --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
