[Sugar-devel] Decoupling of Sucrose (was Re: Initial implementation of toolbars design)

[Tomeu Vizoso]

On Sat, Jul 11, 2009 at 19:42, Aleksey Lim<alsroot at member.fsf.org> wrote:
> 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

I'm having trouble understanding this. Which D-Bus services would we
need to add?

Regards,

Tomeu

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