[Sugar-devel] Share button in the activity toolbar (from the toolbar redesign thread)

[Eben Eliason]

On Tue, Aug 11, 2009 at 9:19 AM, Aleksey Lim<alsroot at member.fsf.org> wrote:
> On Tue, Aug 11, 2009 at 08:02:10AM -0400, Walter Bender wrote:
>> On Tue, Aug 11, 2009 at 6:49 AM, Simon Schampijer<simon at schampijer.de> wrote:
>> > On 08/06/2009 04:59 PM, Simon Schampijer wrote:
>> >> On 08/06/2009 03:37 PM, Eben Eliason wrote:
>> >>> On Thu, Aug 6, 2009 at 6:56 AM, Simon Schampijer<simon at schampijer.de>   wrote:
>> >>>> On 07/31/2009 05:14 PM, Eben Eliason wrote:
>> >>>>> On Fri, Jul 31, 2009 at 8:41 AM, Aleksey Lim<alsroot at member.fsf.org>
>> >>>>>    wrote:
>> >>>>>> On Fri, Jul 31, 2009 at 02:05:48PM +0200, Tomeu Vizoso wrote:
>> >>>>>>> On Fri, Jul 31, 2009 at 13:47, Simon Schampijer<simon at schampijer.de>
>> >>>>>>>    wrote:
>> >>>>>>>> Another question that came up today:
>> >>>>>>>>
>> >>>>>>>> Should the activity toolbar contain the "share" option by default?
>> >>>>>>>> Disabled by default?
>> >>>>>>> Maybe we could use the max_participants property to know when to
>> >>>>>>> disable the button?
>> >>>>> This makes sense to me. I think it's useful to keep it in view to
>> >>>>> indicate that the activity is private. A non-collaborative activity
>> >>>>> still has a sharing scope.
>> >>>>>
>> >>>>>> So, the question is - what is default value for max_participants :)
>> >>>>>>
>> >>>>>> In current code it equals to 0 but old sharing component compares it
>> >>>>>> with 1 thus share combo is visible by default.
>> >>>>> An activity that supports 0 participants (or fewer!) sounds pretty
>> >>>>> useless. Clearly 1 is the logical default for this property.
>> >>>>>
>> >>>>>> btw all activities, I've seen before that don't want sharing, hide
>> >>>>>> share combo by share.props.visible not by max_participants, I guess
>> >>>>>> it signalizes about not consistency of current implementation where
>> >>>>>> user can hide/show share button by two different methods.
>> >>>>> Yup, we should push towards consistency here. I'd bet activities
>> >>>>> wouldn't bother to hide it if Sugar made it insensitive properly.
>> >>>>>
>> >>>>> Eben
>> >>>> So, sounds like max-participants should be set to '1' by default. And we use
>> >>> Definitely.
>> >>>
>> >>>> this value to display the sharing option or not.
>> >>>>
>> >>>> Or did you mean to display it and make it sensitive/insensitive, Eben?
>> >>> I think it should always be shown, but made insensitive accordingly
>> >>> based on max_participants.
>> >>>
>> >>> Eben
>> >>
>> >> Sounds good to me.
>> >>
>> >> Thanks for following up,
>> >>      Simon
>> >
>> > There had been some discussions on the max_participants property in the
>> > last days. What we agree on is that the share_button should be made
>> > insensitive when the activity does not provide that functionality. The
>> > API at the moment let's you set max_participants to 1, or just use
>> > sensitive property of the button and set it to false.
>> >
>> > The max_participants property makes sense, when we have more things that
>> > need to change in the UI accordingly, not only the share button. For
>> > example, the invite option in the neighborhood view. Though the shell
>> > can not access that property neither. An option would be to move this
>> > property to the activity.info.
>> > And to give the max_properties a real meaning, we would have to know how
>> > many participants are currently in that activity. To grey it out in the
>> > mesh view, when not more people can join or similar. This request would
>> > need to be made to the PS, not sure if there exist such an option. All
>> > in all I wonder if this would be a needed functionality for 0.86, or if
>> > we should better invest in making collaboration more stable.
>> >
>> > Comments appreciated,
>> >    Simon
>> >
>> >
>>
>> Somewhat tangential, but I don't actually know what the upper bound
>> for my activities are. It so much depends on how they are being used
>> and what the network is like they are being used on... For example, I
>> had no problem sharing Turtle Art among 25+ students on a wired
>> network when they were all essentially using it to get a copy of a
>> project from the teacher. As soon as they all started making
>> modifications, all hell broke out. So my long-winded point is,
>> max_participants is a really fuzzy concept. (I suppose in the case of
>> Turtle Art, I should restrict "modifications" to a max_partiicipants,
>> but let how every many people who want to copy (or watch) the action.
>
> +1
>
> I suspect that exact value for max_participants won't be so popular
> and will be useful only in special cases(e.g. chess), so I'm not sure we

That's true, but fuzzy numbers (let's call it an upper bound) could
still be marginally useful.

> should add so complex logic(which should cover both sides, server and
> all possible clients).
>
> Activities that restrict number of playable participants could do it on
> theirs own like add spectator mode or on opening shared instance send

Actually, it would be my desire that the shell would handle "watching"
generally for all activities, and that's one of the reasons that
having this exposed is important. It's also nice to be able to either
prevent others from joining, or change "join" to "watch" accordingly.
If choosing a static number is problematic, perhaps we can make it a
method the shell calls on the activity while running instead. In fact,
maybe it doesn't return a number, but instead a boolean indicating
whether or not it can accept more participants.

> notification to the shell(we should implement this, btw it could be
> useful in other cases as well e.g. arrived message in Chat) and close
> instance immediately.

This doesn't seem friendly from a user perspective. It would be much
better to indicate the circumstances up front instead of failing to
launch.

Eben


> --
> Aleksey
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>