Difference between revisions of "Features/Can share"
(Created page with "<noinclude>{{TOCright}} Category:Feature Page Incomplete Can_share </noinclude> == Summary == This feature will make it clearer if an activity can colla...") |
|||
| Line 22: | Line 22: | ||
It will be clearer to the user if an activity can collaborate or not. | It will be clearer to the user if an activity can collaborate or not. | ||
| − | == | + | ==Implementation plan== |
I propose to add a field to the activity.info file. This field should be named 'can_share' ad takes the values 'yes' and 'no' (like the 'show_launcher' field). The default value that is assumed if the field is not set will be 'no'. The reason here is that the activity maintainer who cares about collaboration sets the field and there are more activities that do NOT support collaboration than there are who do. | I propose to add a field to the activity.info file. This field should be named 'can_share' ad takes the values 'yes' and 'no' (like the 'show_launcher' field). The default value that is assumed if the field is not set will be 'no'. The reason here is that the activity maintainer who cares about collaboration sets the field and there are more activities that do NOT support collaboration than there are who do. | ||
| + | == Scope == | ||
The shell and the toolkit has to change, furthermore the activities that support sharing have to change their activity.info file. | The shell and the toolkit has to change, furthermore the activities that support sharing have to change their activity.info file. | ||
| Line 34: | Line 35: | ||
== User Experience == | == User Experience == | ||
| − | + | The user will be able to know if he can invite a person to an activity or not. | |
== Dependencies == | == Dependencies == | ||
| Line 40: | Line 41: | ||
== Contingency Plan == | == Contingency Plan == | ||
| − | Revert | + | Revert to previous behavior. |
== Documentation == | == Documentation == | ||
| Line 46: | Line 47: | ||
== Release Notes == | == Release Notes == | ||
| − | + | '''to be written''' | |
== Comments and Discussion == | == Comments and Discussion == | ||
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --> | * See [[{{TALKPAGENAME}}|discussion tab for this feature]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --> | ||
Revision as of 13:07, 14 November 2011
Summary
This feature will make it clearer if an activity can collaborate or not
Owner
- Name: Simon Schampijer
- Email: <simon AT laptop DOT org>
Current status
- Targeted release: 0.96
- Last updated: 14.11.11
- Percentage of completion: 0%
Detailed Description
So far we know inside an Activity if it is able to be shared or not because the share button is changing it's state accordingly (the button is made insensitive if the activity does not support collaboration). But there are other places that need to be aware if an activity supports collaboration or not. For example the buddy palette in the neighborhood view where you can invite a buddy to your activity. An invitation should only be possible if the activity supports collaboration.
Benefit to Sugar
It will be clearer to the user if an activity can collaborate or not.
Implementation plan
I propose to add a field to the activity.info file. This field should be named 'can_share' ad takes the values 'yes' and 'no' (like the 'show_launcher' field). The default value that is assumed if the field is not set will be 'no'. The reason here is that the activity maintainer who cares about collaboration sets the field and there are more activities that do NOT support collaboration than there are who do.
Scope
The shell and the toolkit has to change, furthermore the activities that support sharing have to change their activity.info file.
UI Design
No UI design involved.
How To Test
User Experience
The user will be able to know if he can invite a person to an activity or not.
Dependencies
None
Contingency Plan
Revert to previous behavior.
Documentation
Is there upstream documentation on this feature, or notes you have written yourself? Has this topic been discussed in the mailing list or during a meeting? Link to that material here so other interested developers can get involved.
Release Notes
to be written