[Sugar-devel] Initial implementation of toolbars design

[Aleksey Lim]

On Sat, Jul 11, 2009 at 06:15:21PM +0200, Tomeu Vizoso wrote:
> On Sat, Jul 11, 2009 at 16:53, Eben Eliason<eben at laptop.org> wrote:
> > On Sat, Jul 11, 2009 at 10:23 AM, Gary C Martin<gary at garycmartin.com> 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.
> >
> > Yup, that's the idea. I think it should be up to the activity, by the
> > way, to decide if any of the secondary toolbars are "locked in" when a
> > new activity instance is created. For instance, Paint might decide
> > that making the colors available by default is the wise choice.
> >
> > We should also institute policy for retaining toolbar state in the
> > metadata for a given activity entry in the Journal, so that resuming
> > restores that context. Perhaps this is something that the toolkit can
> > do so that activity doesn't have to think about 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
> >
> > Just to be clear, this new toolbar design is in no way intended to
> > replace palettes in general. Instead, it's provided as a unique
> > alternative to tabs that allows palette-like interaction, but also
> > allows these secondary toolbars to be locked in place persistently,
> > which can be of great usefulness. Therefore, we needn't ask ourselves
> > "how does <this palette> look/work in the new toolbar design?" at all.
> > We should be asking "which of <these palettes>" would work better
> > functionally as a secondary toolbar?".
> >
> > I think that Paint, for instance, would gain heaps of usability if the
> > colors were a secondary toolbar, and that were shown by default. That
> > doesn't mean that Write, for instance, necessarily needs to replace
> > the current color chooser palette. It's should be up to activities to
> > decide what parts of the UI are best suited to the two modes.
> >
> > Both primary and secondary toolbars can have as many normal "palette
> > buttons" as desired.
> >
> >> 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
> >
> > This is something we tossed around a little bit while designing them.
> > I think the answer is no, personally, since it adds a lot more
> > complexity to the UI, and also begins to consume too much of the
> > screen. I'm hoping that [primary toolbars > secondary toolbars >
> > palettes] are sufficient for most use cases here; we don't want to
> > wind up with MS Word-like feature complexity!
> >
> > That said, if we do support it, I think the rule is basically that
> > closing any parent toolbar hides all of its children, and reopening a
> > parent toolbar that had child toolbars open when it was last hidden
> > should reveal all those same children open as they were. But again,
> > I'd much rather just support one level of secondary toolbars.
> >
> >> all the Activities if you start hand redesigning and customising each
> >> edge case. I think the current colour palette in Write would work as
> >
> > Yup.
> >
> >> 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
> >
> > One advantage of this design is that the primary toolbar is always
> > visible, and secondary toolbars can be shown or hidden as needed. The
> > mockups of Browse and Paint try to illustrate how useful this can be
> > in defining a set of "core tools" that are always—or nearly
> > always—applicable to interacting with the activity. In the case of
> > browse, the forward and back buttons, address bar, and bookmarking
> > button are always available in the primary toolbar. In Paint, some of
> > the core painting tools are surfaced.
> >
> > So, the idea here is to define a primary toolbar which contains a) the
> > "core" set of tools/controls and b) toolbar buttons for the secondary
> > sets of tools/controls.
> >
> > In the case of Write, I'd expect some of the basic text editing
> > controls (bold, italic, underline, font-size, font, for example) to be
> > surfaced in the primary toolbar, while tables, images, paragraph
> > formats, and other secondary features each had a secondary toolbar of
> > their own. In this way, it would be possible to reveal the table
> > controls, while retaining the basic text controls, which is clearly
> > quite useful since you can edit text within a table.
> >
> >> 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.
> >
> > Yeah, that's a hard one to get around. We've had these designs since
> > the first release of Sugar, but there just wasn't time or resources to
> > make it happen. On a positive note, these new designs were developed
> > based directly on feedback from kids and teachers, and address a
> > number of issues that they found frustrating or confusing. Based on
> > the enthusiastic responses to the designs among all of you as well, I
> > think we're onto something good.
> >
> > I wish I had some suggestions on how to avoid the backwards
> > compatibility problem, though...
> 
> I think that Aleksey's sugar-port addresses well that problem. The
> downside is that when someone files a bug for an activity, we won't
> know at first if the activity was running code in a copy of sugar-port
> or in sugar-toolkit, but well... Perhaps sugar-toolkit should be
> maintained by the Activity Team, so they can make these decisions with
> more knowledge of cause.

My dream is having this(these) library out of sucrose release cycle
so, its should use only dbus api to cooperate with shell

http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.86#Decoupling_of_Sucrose

-- 
Aleksey