May be is a good idea use max_participants in the .info file, allowing us to limit the number of participants if needed, and set the property in the sugar.activity class. Gonzalo <div class="gmail_quote">On Wed, Nov 16, 2011 at 2:11 AM, Gary Martin <<a href="mailto:garycmartin@googlemail.com">garycmartin@googlemail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Simon, <div class="im"> On 14 Nov 2011, at 18:38, Simon Schampijer wrote: > Hi, > > I would like to propose the following Feature for inclusion into Sugar: "Can share" [1]. > > This feature will make it clearer if an activity can collaborate or not. So far we know inside an Activity if it is able to be shared or not because the share button is changing it's state accordingly (the button is made insensitive if the activity does not support collaboration). But there are other places that need to be aware if an activity supports collaboration or not. For example the buddy palette in the neighborhood view where you can invite a buddy to your activity. An invitation should only be possible if the activity supports collaboration. > > I propose to add a field to the <a href="http://activity.info" target="_blank">activity.info</a> file. This field should be named 'can_share' ad takes the values 'yes' and 'no' (like the 'show_launcher' field). The default value that is assumed if the field is not set will be 'no'. The reason here is that the activity maintainer who cares about collaboration sets the field and there are more activities that do NOT support collaboration than there are who do. > > The shell and the toolkit has to change, furthermore the activities that support sharing have to change their <a href="http://activity.info" target="_blank">activity.info</a> file. </div>How does this relate to the self.max_participants = 1 value set inside current activities? Can it replace this previous api? If not, chances are will bump into bugs were the two values conflict and we end up with different parts of the UI showing different things. Is there any value in making 'can_share' an integer like 'self.max_participants' so the Sugar shell can know not to allow excess users into an activity that is already maxed out? Is anyone aware of any activities that actually use the self.max_participants for anything other than switching off collaboration UI? --Gary <div class="HOEnZb"><div class="h5"> > > Regards, > Simon > > [1] <a href="http://wiki.sugarlabs.org/go/Features/Can_share" target="_blank">http://wiki.sugarlabs.org/go/Features/Can_share</a> > _______________________________________________ > Sugar-devel mailing list > <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> > <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> _______________________________________________ Sugar-devel mailing list <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </div></div></blockquote></div>