Opened 8 years ago

Last modified 3 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 8 years ago by sascha_silbe

  • Cc rgs erikos added

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.

comment:2 Changed 8 years ago by erikos

  • Keywords 11.2.0 added

comment:3 follow-ups: Changed 8 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 8 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 7 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 7 years ago by erikos

  • Keywords 11.3.0 added; 11.2.0 removed

comment:7 Changed 7 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:9 Changed 7 years ago by humitos

  • Cc humitos added

comment:10 Changed 6 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 5 years ago by dnarvaez

  • Milestone changed from 1.0 to Unspecified

comment:12 Changed 5 years ago by dnarvaez

  • Bug Status changed from New to Unconfirmed

comment:13 Changed 5 years ago by dnarvaez

  • Bug Status changed from Unconfirmed to New
  • Priority changed from Unspecified by Maintainer to Normal

comment:14 Changed 5 years ago by walter

  • Owner changed from erikos to walter

comment:15 Changed 4 years ago by godiard

  • Keywords patch added

comment:16 Changed 3 years ago by erilyth

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

Note: See TracTickets for help on using tickets.