Re: [Sugar-devel] Share button in the activity toolbar (from the toolbar redesign thread)
On Tue, Aug 11, 2009 at 6:49 AM, Simon Schampijersi...@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 Schampijersi...@schampijer.de wrote: On 07/31/2009 05:14 PM, Eben Eliason wrote: On Fri, Jul 31, 2009 at 8:41 AM, Aleksey Limalsr...@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 Schampijersi...@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. -walter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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] Share button in the activity toolbar (from the toolbar redesign thread)
On Tue, Aug 11, 2009 at 08:02:10AM -0400, Walter Bender wrote: On Tue, Aug 11, 2009 at 6:49 AM, Simon Schampijersi...@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 Schampijersi...@schampijer.de wrote: On 07/31/2009 05:14 PM, Eben Eliason wrote: On Fri, Jul 31, 2009 at 8:41 AM, Aleksey Limalsr...@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 Schampijersi...@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 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 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. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Share button in the activity toolbar (from the toolbar redesign thread)
On Tue, Aug 11, 2009 at 9:19 AM, Aleksey Limalsr...@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 Schampijersi...@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 Schampijersi...@schampijer.de wrote: On 07/31/2009 05:14 PM, Eben Eliason wrote: On Fri, Jul 31, 2009 at 8:41 AM, Aleksey Limalsr...@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 Schampijersi...@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
Re: [Sugar-devel] Share button in the activity toolbar (from the toolbar redesign thread)
On 08/11/2009 03:42 PM, Eben Eliason wrote: On Tue, Aug 11, 2009 at 9:19 AM, Aleksey Limalsr...@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 Schampijersi...@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 Schampijersi...@schampijer.de wrote: On 07/31/2009 05:14 PM, Eben Eliason wrote: On Fri, Jul 31, 2009 at 8:41 AM, Aleksey Limalsr...@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 Schampijersi...@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
Re: [Sugar-devel] Share button in the activity toolbar (from the toolbar redesign thread)
On 07/31/2009 05:14 PM, Eben Eliason wrote: On Fri, Jul 31, 2009 at 8:41 AM, Aleksey Limalsr...@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 Schampijersi...@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 this value to display the sharing option or not. Or did you mean to display it and make it sensitive/insensitive, Eben? Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Share button in the activity toolbar (from the toolbar redesign thread)
On Thu, Aug 6, 2009 at 6:56 AM, Simon Schampijersi...@schampijer.de wrote: On 07/31/2009 05:14 PM, Eben Eliason wrote: On Fri, Jul 31, 2009 at 8:41 AM, Aleksey Limalsr...@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 Schampijersi...@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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Share button in the activity toolbar (from the toolbar redesign thread)
On 08/06/2009 03:37 PM, Eben Eliason wrote: On Thu, Aug 6, 2009 at 6:56 AM, Simon Schampijersi...@schampijer.de wrote: On 07/31/2009 05:14 PM, Eben Eliason wrote: On Fri, Jul 31, 2009 at 8:41 AM, Aleksey Limalsr...@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 Schampijersi...@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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Share button in the activity toolbar (from the toolbar redesign thread)
On Fri, Jul 31, 2009 at 01:47:33PM +0200, Simon Schampijer wrote: Should the activity toolbar contain the share option by default? Disabled by default? I have a vague recollection that sharing was planned to be implemented using VNC for activities that do not implement their own sharing. If you remove the share button completely, then that screen real estate may be used by something else and it will be hard to reclaim it. I also have a vague recollection about the important buttons (like stop) being managed by sugar (broadly defined) and not by the activity using some kind of GtkPlug/GtkSocket type of set up to support the security model. I don't think that got implemented though. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Share button in the activity toolbar (from the toolbar redesign thread)
On Fri, Jul 31, 2009 at 13:47, Simon Schampijersi...@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? Regards, Tomeu erikos a) the sharing button should be optional alsroot erikos: I guess in case of a) we can follow old behaviour - by default all buttons are enabdled, dev is free to hide() them erikos alsroot: I would prefer to hide it by default erikos alsroot: as most of the simple activities do not have sharing facilities alsroot erikos: +1 then erikos alsroot: we could as well make it insensitive erikos alsroot: hmm alsroot erikos: or another option, having full featured activity toolbar and if user wants something different he can create regular gtk.Toolbar and place there activity.widgets components erikos alsroot: hmm, yeah - let's imagine the case: kid does create his first activity erikos alsroot: they will follow guide X - and use the standard toolbar erikos alsroot: even though, no sharing is implemented - they will get the button erikos alsroot: we can ask as well for clarification the design team erikos alsroot: just be to clear: not a blocker to land your work today * alsroot just thinks that mentioning of hiding something from default toolbar in the guide could be more confusing alsroot s/hiding/hiding or showing/ erikos alsroot: lets ask again on the ml, to be sure, sounds good? alsroot erikos: yeah Thanks, Simon ___ 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] Share button in the activity toolbar (from the toolbar redesign thread)
On Fri, Jul 31, 2009 at 02:05:48PM +0200, Tomeu Vizoso wrote: On Fri, Jul 31, 2009 at 13:47, Simon Schampijersi...@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? 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. 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. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Share button in the activity toolbar (from the toolbar redesign thread)
On Fri, Jul 31, 2009 at 8:41 AM, Aleksey Limalsr...@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 Schampijersi...@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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
