On Thu, Jul 30, 2009 at 06:02:00PM -0400, Eben Eliason wrote: > On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijer<si...@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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel