On Thu, Jul 30, 2009 at 11:10:23PM -0400, Eben Eliason wrote: > On Thu, Jul 30, 2009 at 10:28 PM, Aleksey Lim<[email protected]> 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<[email protected]> > >> 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 _______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
