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. Regards, Tomeu > Eben > _______________________________________________ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel