[Sugar-devel] Initial implementation of toolbars design

[Aleksey Lim]

On Sat, Jul 11, 2009 at 03:23:34PM +0100, Gary C Martin wrote:
> 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.

Looks like more useful then current implementation(ToolbarsButton uses
palette and sub-widget appears only after clicking), I'll tune it

>>> 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...

Why not, if activity developer wants(I think its up to him entirely)

> And, how much work is going to be needed on  
> all the Activities if you start hand redesigning and customising each  
> edge case.

But whats the problem in having both designs at the same time(I guess
its not a nice idea to convince all activity developers to redesign
their activities after each sucrose release)

> 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.

Having colors in sub-widget(instead of palette) have several benefits:
* this palette(imho) looks a bit complex; so, having it in sub-widget
  makes more sense
* its more straightforward to have all complex palettes in sub-widgets

>>> 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.

Thats why sugar-port was created

-- 
Aleksey