"Invite to <activity>" shown even for activities that don't support sharing

[sascha_silbe]

On the Neighbourhood and Group Views, we show "Invite to <activity name>" even for activities that don't support sharing (i.e. sugar.activity.Activity.max_participants = 1).
This is confusing to the user. It advertises a capability that the activity doesn't have and leaves the user to wonder how to use it.

[sascha_silbe]

We currently key the invite menu off the "active activity" (jarabe.model.shell.ShellModel.get_active_activity(), based on mapped X11 windows) and don't have API to query the collaboration capabilities of a running activity from within Sugar (the "Shell").

Whatever API we choose, it should be compatible with non-Sugar applications (that get started from within Sugar, e.g. via Terminal). CC'ing rgs as he has done some work on making Gnome applications collaborate with Sugar activities.

[erikos]

OLPC ticket: ​http://dev.laptop.org/ticket/10535

[martin.langhoff]

Notes from an outsider... it seems to me that this should not be keyed on max_participants. Instead, it should be keyed on whether a currently open activity is being shared at this moment (ie: if the user has selected 'share with... ')

Perhaps this is also easier -- the telepathy/tubes stack knows about currently running shared sessions.

[sascha_silbe]

Replying to martin.langhoff:

Notes from an outsider... it seems to me that this should not be keyed on max_participants. Instead, it should be keyed on whether a currently open activity is being shared at this moment (ie: if the user has selected 'share with... ')

That was my thought exactly. Unfortunately we currently conflate "no sharing" with "private sharing", at least on the UI side. Pulling in Gary and Walter to (re)consider the UI (Christian does not seem to have a Trac account).

[erikos]

Replying to martin.langhoff:

Notes from an outsider... it seems to me that this should not be keyed on max_participants. Instead, it should be keyed on whether a currently open activity is being shared at this moment (ie: if the user has selected 'share with... ')

Perhaps this is also easier -- the telepathy/tubes stack knows about currently running shared sessions.

But the moment you invite the first person to your activity it is not shared yet. So this does not work neither.

As Sascha said we have the information in the activity instance with 'max_participants' but can not access it from the shell.

Another option might be to add the information to the activity.info file, this would at least be accessible by the shell.

[erikos]

Discussed this with Sascha and Gary at the Sugar Camp:

As stated above the solution will be to add the information to the activity.info file, that way we know in the shell if an activity supports sharing. Entry in the activity.info file set to off by default, the activity maintainer who cares about it can set it and there are more activities that do NOT support sharing.

Sadly too late for this cycle.

[erikos]

See more info at: ​http://wiki.sugarlabs.org/go/Features/Can_share and the thread ​http://lists.sugarlabs.org/archive/sugar-devel/2011-November/034260.html

[erikos]

Moving this out as it is again uff :( late in the cycle and it would take activity changes.

[godiard]

GCI code here ​https://github.com/sugarlabs/sugar/pull/434

[erilyth]

Has this issue been addressed? If not I would like to try fix it.

[quozl]

​https://github.com/sugarlabs/sugar/pull/625