[Sugar-devel] Initial implementation of toolbars design

[Gary C Martin]

On 11 Jul 2009, at 14:40, Aleksey Lim wrote:
> On Sat, Jul 11, 2009 at 11:12:31AM +0200, Simon Schampijer wrote:
>> a) DESIGN: discuss the design further and get some mockups  
>> together, one
>> question that came up is: do we always have a one line secondary tool
>> bar?
>
> Do you mean hiding sub-toolbars like palettes?
> I'm using new toolbar in Memorize, and should say - its much useful to
> have persistent sub-toolbar(and not auto-hiding them like palettes)

Ebens designs describe both interaction methods:

1). If you hover over one of the new tab replacement buttons the  
palette appears (over the top of the canvas) and will auto-hide if you  
move the mouse way (just like any normal palette)

2). If you click one of the new tab replacement buttons the palette  
appears (and shifts the canvas down the screen) and is locked in  
place. Clicking the button a 2nd time unlocks it so it behaves like a  
regular palette again.

>> How would more complex widgets like the color chooser look like
>> http://wiki.sugarlabs.org/go/File:ColorToolButton.png ? Or would they
>> open from the secondary palette?
>
> I'm personally, +1 for
> http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars#11

I guess one unanswered question is do you allow the stacking of more  
than 2 rows of toolbar... And, how much work is going to be needed on  
all the Activities if you start hand redesigning and customising each  
edge case. I think the current colour palette in Write would work as  
is, at least that's how I was going to show it in a mockup, Activity  
bar -> text bar below -> existing drop down colour palette from its  
icon.

>> Maybe we should step through some of
>> the activities and just remodel them to see what would work and  
>> find out
>> about the edge cases (think gary is already working on that)
>>
>> b) API: we need a rock solid API. This is public API and will be  
>> used by
>> all the activity authors, so very important to get this right - so  
>> we do
>> not need to change it again afterwards
>
> So, we need activity authors use new toolbar in their activities
> I guess they could add toolbar.py to activity project(like sugar-port)
> if they want activities be runnable in <0.86 environment

As an Activity author, this is what breaks my heart. 99.5% or more of  
our users will be unable to get the benefits of new Activity releases.  
That's real tough psychology, and very de-motivating for volunteer  
authors.

Regards,
--Gary