[Sugar-devel] Initial implementation of toolbars design

[Eben Eliason]

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

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