<div dir="ltr">I don't know if we need replace the subtoolbars,<div style>but I think should be good re evaluate the need of the use of timeuts</div><div style>to open/close the subtoolbars when hover.</div><div style>
In fact, that does not works with touch devices,</div><div style>and do code more complicate in places, like when interact with drag and drop </div><div style>in the journal.</div><div style><br></div><div style>Gonzalo</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 25, 2013 at 4:37 PM, Manuel Quiñones <span dir="ltr"><<a href="mailto:manuq@laptop.org" target="_blank">manuq@laptop.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For Sugar Web, I would like to revisit subtoolbars, considering the<br>
usage in GTK activities and the nature of the web.<br>
<br>
In GTK we have to deal with two issues:<br>
<br>
- toolbars allow a limited amount of buttons<br>
- the subtoolbar shrinks the canvas when it is triggered<br>
<br>
The first one is specially bad in vertical screen, aka portrait mode.<br>
The second one can be handled, but I saw activities like Paint dealing<br>
with it.  Having your work area shrinking and expanding all the time<br>
is not fun.<br>
<br>
And I'll add a personal opinion here: I think many controls around<br>
make the activity look too complex.  Toolbars were a great discovery<br>
in UI, but soon the idea distorted and went overused.  See Microsoft<br>
Office 98 for a bad example.  We need to provide a clean view to the<br>
user, make only the important items visible, hide the advanced<br>
options, and let the user find them through discovery.<br>
<br>
So I was wondering if palettes could be the general solution for<br>
controls.  This is aligned to what I see in android and ipad apps.  I<br>
think custom palettes was a limitation in GTK, but in web we can add<br>
more powerful palettes to our toolkit.  For a good example of powerful<br>
palettes, see CScott Nell Colors activity:<br>
<br>
<a href="http://cscott.github.io/nell-colors" target="_blank">http://cscott.github.io/nell-colors</a><br>
<br>
One contra regarding palettes is that they can occlude the canvas.<br>
For example, in Measure Activity you want to see how the wave changes<br>
while you tweak controls.  I think in this cases, the controls should<br>
be moved to the main toolbar or to the cavas itself.<br>
<br>
I discussed this with Lionel and Suraj, and the latter is already<br>
working on an Activity Palette that contains the title and description<br>
entries.  But I wanted to open a design discussion.  Comments?<br>
<br>
Lastly, an implementation detail.  There are important differences in<br>
how GTK layouts widgets, compared with the web.  In web apps, the<br>
layout tends to be scroll-oriented.  In windowed apps like the GTK<br>
activities, the layout tends to be window-oriented.  I mean: if you<br>
add a Gtk.Box with buttons inside to a Gtk.Window, you end with an<br>
array of buttons covering the window.  Instead, if you add <div> tags<br>
with <button> tags inside an html page, you end with those buttons in<br>
the corner of the page.  To make the elements fit the canvas while it<br>
shrinks and expands activities, we need to do the maths in the<br>
Javascript code.  I mean, is not following the nature of the medium.<br>
<br>
--<br>
.. manuq ..<br>
_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
</blockquote></div><br></div>