On Sat, Jul 11, 2009 at 06:15:21PM +0200, Tomeu Vizoso wrote: > On Sat, Jul 11, 2009 at 16:53, Eben Eliason<e...@laptop.org> wrote: > > On Sat, Jul 11, 2009 at 10:23 AM, Gary C Martin<g...@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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel