Opened 13 years ago
Last modified 8 years ago
#2702 assigned defect
"Invite to <activity>" shown even for activities that don't support sharing
Reported by: | sascha_silbe | Owned by: | walter |
---|---|---|---|
Priority: | Normal | Milestone: | Unspecified |
Component: | Sugar | Version: | Git as of bugdate |
Severity: | Minor | Keywords: | patch |
Cc: | rgs, erikos, garycmartin, walter, humitos | Distribution/OS: | |
Bug Status: | New |
Description
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.
Change History (17)
comment:1 Changed 13 years ago by sascha_silbe
- Cc rgs erikos added
comment:2 Changed 13 years ago by erikos
- Keywords 11.2.0 added
OLPC ticket: http://dev.laptop.org/ticket/10535
comment:3 follow-ups: ↓ 4 ↓ 5 Changed 13 years ago by 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.
comment:4 in reply to: ↑ 3 Changed 13 years ago by sascha_silbe
- Cc garycmartin walter added
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).
comment:5 in reply to: ↑ 3 Changed 12 years ago by 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.
comment:6 Changed 12 years ago by erikos
- Keywords 11.3.0 added; 11.2.0 removed
comment:7 Changed 12 years ago by erikos
- Keywords 11.3.0 removed
- Milestone changed from 0.94 to 0.96
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.
comment:8 Changed 11 years ago by erikos
- Milestone changed from 0.96 to 0.98
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
comment:9 Changed 11 years ago by humitos
- Cc humitos added
comment:10 Changed 11 years ago by erikos
- Milestone changed from 0.98 to 1.0
- Owner set to erikos
- Status changed from new to assigned
Moving this out as it is again uff :( late in the cycle and it would take activity changes.
comment:11 Changed 10 years ago by dnarvaez
- Milestone changed from 1.0 to Unspecified
comment:12 Changed 10 years ago by dnarvaez
- Bug Status changed from New to Unconfirmed
comment:13 Changed 10 years ago by dnarvaez
- Bug Status changed from Unconfirmed to New
- Priority changed from Unspecified by Maintainer to Normal
comment:14 Changed 9 years ago by walter
- Owner changed from erikos to walter
comment:15 Changed 9 years ago by godiard
- Keywords patch added
GCI code here https://github.com/sugarlabs/sugar/pull/434
comment:16 Changed 8 years ago by erilyth
Has this issue been addressed? If not I would like to try fix it.
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.