[Sugar-devel] Initial implementation of toolbars design

[Aleksey Lim]

On Sat, Aug 01, 2009 at 04:37:24PM +0200, Tomeu Vizoso wrote:
> On Sat, Aug 1, 2009 at 16:33, Aleksey Lim<alsroot at member.fsf.org> wrote:
> > On Sat, Aug 01, 2009 at 03:19:46PM +0100, Gary C Martin wrote:
> >> On 1 Aug 2009, at 14:51, Aleksey Lim wrote:
> >>
> >> >On Sat, Aug 01, 2009 at 02:12:50PM +0100, Gary C Martin wrote:
> >> >>On 31 Jul 2009, at 10:54, Simon Schampijer wrote:
> >> >>
> >> >>>>1). I was hoping for more feedback before we lock things down,
> >> >>>>but it's
> >> >>>>been pretty quiet. I was hoping to hack TurtleArt with a temporary
> >> >>>>toolbar imitation and get some real usability input from kids,
> >> >>>>but not
> >> >>>>sure we have the time?
> >> >>>
> >> >>>We land it today, Browse and Write are ready, so we can get
> >> >>>feedback on them. From the schedule we still have a bit of time.
> >> >>>So I am positive.
> >> >>>
> >> >>>>2). Is it possible to have the "title entry" input field default
> >> >>>>width
> >> >>>>set to allow for 9 icons on the right (this is the maximum
> >> >>>>needed for
> >> >>>>current Activity designs), then allow it scale down to some min
> >> >>>>width if
> >> >>>>extra icons are added? I would rather there was a little
> >> >>>>flexibility in
> >> >>>>the "title entry" rather than have the "Stop" and "Keep" buttons
> >> >>>>be the
> >> >>>>first to disappear.
> >> >>>
> >> >>>Looks like we are over this point, following the other discussions
> >> >>>in this thread.
> >> >>>
> >> >>>>3). FWIW, I'm considering the "share with" icon should really be
> >> >>>>over on
> >> >>>>the right (if sharing feature are present). So the far right
> >> >>>>icon order
> >> >>>>would be "share with", "keep version", "stop".
> >> >>>
> >> >>>Same here.
> >> >>>
> >> >>>Btw - we went at the moment for eben's design. Gary, we could use
> >> >>>your design (with title entry in the top) and test it out, if you
> >> >>>think it is worth doing comparing tests.
> >> >>
> >> >>Let's get feedback with what has been implemented so far and iterate
> >> >>on it if there are agreed issues. My main concern at the moment is
> >> >>that we have complicated the trivial Activity case, in that there is
> >> >>no longer an option for just providing a single main toolbar. Every
> >> >>Activity has to now deal with loss of canvas space and dynamic
> >> >>resizing caused by the secondary activity toolbar design (that's one
> >> >>reason I didn't like that path).
> >> >>
> >> >>Who is the poor soul that's going to have to sort out TamTamMini, I
> >> >>vote for alsroot ;-b
> >> >
> >> >Well, I have around 14(including TamTamMini) activities on git.sl.o
> >> >to switch to new toolbars.. so you can wish me luck.
> >>
> >> Good luck!
> >>
> >> Quick question: Are you going to try and support existing
> >> deployments and keep and maintain both toolbar implementations? That
> >> is certainly (but painfully) my plan, as that's where 99.9% of our
> >> users are. You might need to wish me luck as well, as I'm not half
> >> as code prolific as you ;-)
> >
> > I have secret weapon, sugar-port[1] for that purpose :)
> 
> You mean each of those activities will ship with its own copy of the
> new toolbars? That's quite a bit scary from the support POV.

Well, not so much as you can think..
API for new toolbars won't be changed(I hope), so I need only `cp`
proper sources from master repo(if it will contain fixed code)
anyway I don't see another way except not using new toolbars at all.
I'm personally dislike idea of having several branches in that
particular case where there is no changes in activity code but only
changes in 3rd party components.

> 
> Regards,
> 
> Tomeu
> 
> > [1] http://wiki.sugarlabs.org/go/Development_Team/sugar-port
> >
> >>
> >> Regards,
> >> --Gary
> >>
> >
> > --
> > Aleksey
> >
> 

-- 
Aleksey