[Sugar-devel] Initial implementation of toolbars design

[Aleksey Lim]

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

> 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)

> 4. But these are nitpicks. Fantastic work!!
> 
> 
> > Thanks,
> >   Simon
> >
> 

-- 
Aleksey