Difference between revisions of "Features/New Toolbar Design"

Latest revision as of 14:35, 5 November 2013

Summary

Redesign the activity toolbar to not use tabs and use toolbar buttons that can reveal secondary functionality instead.

Owner

Name: Aleksey Lim
Email: send an email

Current status

Targeted release: 0.86
Last updated: 19 Sep 2009
Percentage of completion: 100%

Detailed Description

sugar.graphics.toolbar module consists of 2 widgets:

Toolbar main widget which represents toolbar itself
ToolbarButton tool button to insert to Toolbar, which could be expanded to sub-widget

NOTE: Toolbar was designed to have only one level of sub-widgets.

Toolbar

sugar.graphics.toolbar.Toolbar extends gtk.VBox:

top property to access to gtk.Toolbar interface
padding horizontal padding for top toolbar and all sub-widgets
modify_bg method to modify background color of toolbar itself and all sub-widgets

ToolbarButton

sugar.graphics.toolbar.ToolbarButton extends sugar.graphics.toolbutton.ToolButton:

toolbar RO property, if parent of button is sugar.graphics.toolbar.Toolbar
page RW GObject property, sub-widget to expand
expanded RW property, if page expanded

If sugar.graphics.toolbar.Toolbar.palette property wasn't set manually it will contain palette with page.

Example

from sugar.graphics.toolbar import Toolbar, ToolbarButton

toolbar = Toolbar()

tollbarbutton_1 = ToolbarButton(
       page=gtk.Button('sub-widget #1'),
       icon_name='computer-xo')
toolbar.top.insert(tollbarbutton_1, -1)

tollbarbutton_2 = ToolbarButton(
       page=gtk.Button('sub-widget #2'),
       icon_name='button_cancel',
       tooltip='with custom palette instead of sub-widget')
toolbar.top.insert(tollbarbutton_2, -1)

Benefit to Sugar

Make process of switching between toolbars more clear, use tool buttons that are showing all the time (in main toolbar), i.e., having Close/Help buttons visible all the time could be very useful.

Scope

implementation in sugar-toolkit
provide API in sugar.activity.activity for new toolbars

One option for new API is supporting bunch of methods to create most useful toolitems/sub-toolbars. (see [1] for example usage).

activity.toolbar() toolbutton with activity sub-toolbar
activity.stop_button()
activity.undo_button()
activity.redo_button()
activity.copy_button()
activity.paste_button()

Implementation

sugar-toolkit
Example implementation in Write
Example implementation in Terminal
Example implementation in Log
Example implementation in Read

How To Test

Features/New Toolbar Design/Testing

In progress..

User Experience

If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice.

Dependencies

only sugar-toolkit

Contingency Plan

None necessary, revert to previous release behaviour.

Documentation

Gary's Design_Team/Proposals/Toolbars/Activity-wide_Toolbar_mock-ups proposal. Eben's initial Design Team/Designs/Toolbars mockups.

Release Notes

Solution for the stop activity issue, pointed out at http://dev.sugarlabs.org/ticket/452

Comments and Discussion

See discussion tab for this feature

@@ Line 1: / Line 1: @@
-<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude>
+<noinclude>{{GoogleTrans-en}}{{TOCright}}
+[[Category:FeatureLanded|New Toolbar Design]]
+[[Category:Feature Accepted 0.86]]</noinclude>
 <!-- All fields on this form are required to be accepted.
@@ Line 7: / Line 9: @@
 == Summary ==
+Redesign the activity toolbar to not use tabs and use toolbar buttons that can reveal secondary functionality instead.
-Implement widgets for [[Design Team/Designs/Toolbars]] proposal.
 == Owner ==
@@ Line 17: / Line 18: @@
 == Current status ==
 * Targeted release: 0.86
-* Last updated: Thu Jul  9 19:11:41 UTC 2009
+* Last updated: 19 Sep 2009
-* Percentage of completion: 0%
+* Percentage of completion: 100%
 == Detailed Description ==
-''Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better.''
+sugar.graphics.toolbar module consists of 2 widgets:
+* ''Toolbar'' main widget which represents toolbar itself
+* ''ToolbarButton'' tool button to insert to ''Toolbar'', which could be expanded to sub-widget
+NOTE: Toolbar was designed to have only one level of sub-widgets.
+==== Toolbar ====
+sugar.graphics.toolbar.Toolbar extends gtk.VBox:
+* ''top'' property to access to gtk.Toolbar interface
+* ''padding'' horizontal padding for ''top'' toolbar and all sub-widgets
+* ''modify_bg'' method to modify background color of toolbar itself and all sub-widgets
+==== ToolbarButton ====
+sugar.graphics.toolbar.ToolbarButton extends sugar.graphics.toolbutton.ToolButton:
+* ''toolbar'' RO property, if parent of button is sugar.graphics.toolbar.Toolbar
+* ''page'' RW GObject property, sub-widget to expand
+* ''expanded'' RW property, if ''page'' expanded
+If sugar.graphics.toolbar.Toolbar.palette property wasn't set manually it will contain palette with ''page''.
+==== Example ====
+ from sugar.graphics.toolbar import Toolbar, ToolbarButton
+ toolbar = Toolbar()
+ tollbarbutton_1 = ToolbarButton(
+        page=gtk.Button('sub-widget #1'),
+        icon_name='computer-xo')
+  toolbar.top.insert(tollbarbutton_1, -1)
+ tollbarbutton_2 = ToolbarButton(
+        page=gtk.Button('sub-widget #2'),
+        icon_name='button_cancel',
+        tooltip='with custom palette instead of sub-widget')
+ toolbar.top.insert(tollbarbutton_2, -1)
 == Benefit to Sugar ==
-''What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?''
+Make process of switching between toolbars more clear, use tool buttons that are showing all the time (in main toolbar), i.e., having Close/Help buttons visible all the time could be very useful.
 == Scope ==
 * implementation in sugar-toolkit
-* use new toolbars in Journal
+* provide API in sugar.activity.activity for new toolbars
-== How To Test ==
+One option for new API is supporting bunch of methods to create most useful toolitems/sub-toolbars. (see [http://git.sugarlabs.org/projects/write/repos/toolbars/blobs/master/AbiWordActivity.py#line58] for example usage).
-''This does not need to be a full-fledged document.  Describe the dimensions of tests that this feature is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.''
+* ''activity.toolbar()'' toolbutton with activity sub-toolbar
+* ''activity.stop_button()''
+* ''activity.undo_button()''
+* ''activity.redo_button()''
+* ''activity.copy_button()''
+* ''activity.paste_button()''
-''Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.''
+=== Implementation ===
-''A good "how to test" should answer these four questions:''
+* [http://git.sugarlabs.org/projects/sugar-toolkit/repos/toolbars sugar-toolkit]
+* Example implementation in [http://git.sugarlabs.org/projects/write/repos/toolbars Write]
-* ''What special hardware / data / etc. is needed (if any)?
+* Example implementation in [http://git.sugarlabs.org/projects/terminal/repos/toolbars Terminal]
-* ''How do I prepare my system to test this feature? What packages need to be installed, config files edited, etc.?
+* Example implementation in [http://git.sugarlabs.org/projects/log/repos/toolbars Log]
-* ''What specific actions do I perform to check that the feature is working like it's supposed to?
+* Example implementation in [http://git.sugarlabs.org/projects/read/repos/toolbars Read]
-* ''What are the expected results of those actions?''
+== How To Test ==
+{{:{{PAGENAME}}/Testing}}
 == User Experience ==
 ''If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice.''
 == Dependencies ==
-''What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like python?''
+* only sugar-toolkit
 == Contingency Plan ==
-''If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Sugar will not be in jeopardy.''
+None necessary, revert to previous release behaviour.
 == Documentation ==
-''Is there upstream documentation on this feature, or notes you have written yourself?  Link to that material here so other interested developers can get involved.''
+Gary's [[Design_Team/Proposals/Toolbars/Activity-wide_Toolbar_mock-ups]] proposal.
+Eben's initial [[Design Team/Designs/Toolbars]] mockups.
 == Release Notes ==
-''The Sugar Release Notes inform end-users about what is new in the release. An Example is [[0.84/Notes]]. The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the release team and shipped with the release.''
+''Solution for the stop activity issue, pointed out at http://dev.sugarlabs.org/ticket/452''
 == 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 -->
-==[[Features]] Subpages==
-{{Special:PrefixIndex/Features/}}
-----
-''You can add categories to tie features back to real deployments/schools requesting them, for example <nowiki>[[</nowiki>Category:Features requested by School Xyz]]''
-[[Category:FeaturePageIncomplete]]
-[[Category:Feature]]
-[[Category:Feature 0.86]]