[Sugar-devel] Initial implementation of toolbars design

[Aleksey Lim]

On Thu, Jul 30, 2009 at 11:10:23PM -0400, Eben Eliason wrote:
> On Thu, Jul 30, 2009 at 10:28 PM, Aleksey Lim<alsroot at member.fsf.org> wrote:
> > On Thu, Jul 30, 2009 at 06:02:00PM -0400, Eben Eliason wrote:
> >> On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijer<simon at schampijer.de> wrote:
> >> > On 07/29/2009 07:03 PM, Gary C Martin wrote:
> >> >>
> >> >> Hi Simon,
> >> >>
> >> >> On 29 Jul 2009, at 08:55, Simon Schampijer wrote:
> >> >>
> >> >>>> FWIW: Picking the top level tool set is going to be a real tough call in
> >> >>>> a number of cases as we loose toolbar space for each extra tab, plus the
> >> >>>> activity icon on far left (essential for Activity recognition), plus the
> >> >>>> stop icon on far right (essential, no questions, no doubts). The
> >> >>>> features that actually fit in the remaining space may seem quite an
> >> >>>> arbitrary hotchpotch.
> >> >>>
> >> >>> Gary, I am not sure I get your arguments right :/ Can you elaborate?
> >> >>> What I conclude of all the answers, I think that space in the primary
> >> >>> toolbar is an issue. So we need to decide what to put there. Does
> >> >>> activity icon and stop icon sounds good to you as well?
> >> >>
> >> >> Sorry if that wasn't clear. Activity icon and stop icon are essential.
> >> >> The Activity icon is going to be critical for identifying what activity
> >> >> you are in at a glance, especially if the actual title name is hidden
> >> >> away in a sub toolbar. A downside if we loose the title in the primary
> >> >> toolbar is reinforcement of knowing what activity you are in (say you
> >> >> are copy/pasting between two similar Write documents)...
> >> >
> >> > Ok, thanks for the explanation. The differentiation of the running instance
> >> > of two activities of the same type is a good point. But, does this happen
> >> > often? I guess many kids will run one activity of each type at a time, and
> >> > remember performance constraints ;p And one can use the frame to distinguish
> >> > the activities.
> >> >
> >> > Personally, I see more the issue of naming an activity, since as said in
> >> > another post I am not really convinced about the naming alert.
> >>
> >> I'll have to think about this idea more, but: we could also have the
> >> naming "alert" appear as a palette attached to the stop button,
> >> instead. It doesn't change the behavior too much (it requires 2 clicks
> >> to stop an activity for the first time if it hasn't been named), but
> >> the use of the palette might feel more consistent with Sugar in
> >> general. On the other hand, it could be strange to change the behavior
> >> of the stop button between the first and other cases.
> >>
> >> > One little thing I am a bit worried about, is that we miss labels for the
> >> > sub-toolbars. I hope the icons are meaningful enough for the users - but
> >> > then labels can be misleading as well, and many of our users can't possibly
> >> > read.
> >>
> >> Yes, we had some thoughts. We'll hash it out some more.
> >>
> >> > About alignment (attached is a snapshot), should we align the 'share button'
> >> > and the 'keep one' to the left that the way to get to this button is not so
> >> > long, when revealing the toolbar?
> >>
> >> I think we should be thinking about this in the general case.
> >> Sometimes one will need to reach the other end to reach controls (and
> >> (though not for the activity toolbar) this depends on where the
> >> toolbar button sits within the primary toolbar). We should make sure
> >> that the palette behavior works well in these instances. For instance,
> >> it shouldn't disappear immediately on mouse-leave. Perhaps the delay
> >> should be longer than for normal palettes, due to their peculiar
> >> dimensions.
> >>
> >> That said, I'd be fine with aligning these buttons to the left in this instance.
> >>
> >> Eben
> >>
> >> PS a few notes on the design:
> >>
> >> 1. Is this screenshot showing the hover state of the toolbar button
> >> with the toolbar already locked in?
> >
> > Nope, in current implementation there is no way to open hover palette
> > if toolbar is locked in
> 
> OK, then the arrow should still be pointing down at this point,
> indicating that clicking the button will lock it in place below. Once
> locked in, it changes directions to point up indicating that a second
> click will close it. Refer to:
> http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars#06

done

> 
> >> If not, the small arrow beneath
> >> the activity icon should still be pointed downwards, to indicate that
> >> clicking on the button will lock it into place. It should appear
> >> pointing upward only when already locked in.
> >>
> >> 2. We should fix the style for the text entry so it appears correctly
> >> on black backgrounds.
> >>
> >> 3. I'll get you those scissors tonight, for real this time.
> >
> >> Also, can
> >> we change the arrow to match those in the mockups? The one shown here
> >> competes with the icons themselves.
> >
> > What do you mean exactly, position, size or arrows shape
> > (in case of shape it uses paint_arrow gtk function, I guess its much
> > straight forward to use gtk function instead of custom images e.g. using
> > the same shape like arrows in other widgets)
> 
> I'd like it to match the arrow in the mockups. In fact, I think we've
> intended to use this filled triangle everywhere in the UI (such as
> nested menus), so it would be fine to change this at the gtk level.
> Actually, I thought Ben B. had worked on that at one point, but I
> never saw the change take effect. Ben?
> 
> Eben
> 
> >> 4. But these are nitpicks. Fantastic work!!
> >>
> >>
> >> > Thanks,
> >> >   Simon
> >> >
> >>
> >
> > --
> > Aleksey
> >
> 

-- 
Aleksey