<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">> There are various possible solutions. In order from smallest to largest
<br>> changes:<br>><br>> 1. Move the select tool onto the Edit toolbar, or put it in both places.<br>> 2. Automatically change to the select tool for as long as you're using the<br>> edit toolbar.<br>> 3. Move from an select - action (object - verb) metaphor to an action -
<br>> select (verb - object) metaphor. In other words, have a 'copy tool' which is<br>> just a select tool which copies as soon as you let up the mouse. In a larger<br>> graphics program, like Inkscape, this would mean a separate selection tool
<br>> for every possible transformation, and some sort of UI 'pronoun' idiom (a<br>> graphical menu on the side? Or a dropdown from the tool?) for reselecting a<br>> recent selection set, for when you want to do various transformations on the
<br>> same set of objects.<br><br></div>All of these are valid suggestions.  The drawback to all is that they<br>make assumptions about the types of selections that can be made (More<br>specifically, they don't allow for compound boolean selections).
<br>Perhaps that's not something many (any?) kids will want or need, but<br>we have to observe the limitations that come with decisions we make.<br>Actually, the 3rd is the only one which strictly limits this.  I'd
<br>lean to 1 or 2 myself, which would allow a complex compound selection<br>to be made should a child desire one, and then offer a subset of<br>selection tools to modify or change the selection with the toolbar<br>visible.
</blockquote><div><br>This problem suffers not from too few solutions, but too many. Right clicks, tool settings menus (from the tool or using a right click on the canvas), little indicators in the corner of the tool pointer, modifier keys, and doing compound actions part-by-part: these are all possibilities. Of course there are disadvantages, too: obscurity (hard to 'discover'), complication, limitations. I think that the best solution will end up being some judicious combination.
<br><br>A good interface would have a variety of selection styles - lasso, marquee, fill ('magic lasso'), as well as add/subtract(/xor?) for all of the above. This should be indicated in the pointer, and accessible using sticky keyboard modifiers (I think all keyboard modifiers should be sticky for the duration of one complete action), right-click context menus within the canvass, or hover menus on the tool itself. Note that the possibility of a compound selection means deviating from the verb-object model (choose tool - construct selection - computer processes result and begins to blink result - press enter or choose other tool to apply result).
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Of course, we're really<br>talking about special cases of bitmap graphics, as with vector
<br>graphics, the model you speak of makes more sense, which the objects<br>are truly discrete objects, and not part of a flattened whole.  I</blockquote><div><br>Actually, as far as I can see, it's more case-by-case. 'Paint' has limited selection possibilities, and most of the verbs are pretty commutative and associative, so my model is simple. A more full-featured photo editor has much trickier forms of selection; and a more full-featured vector editor like Inkscape has some verbs which are neither commutative nor associative, and some which can only act on different classes of objects (shapes, paths, bezier points, or text).
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">in<br>fact, in most SVG editors, the transform 'tool' is implicitly<br>available when an object is selected.
</blockquote><div><br>For simple translations or orthogonal dilations - but not rotations or skews.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><div class="Ih2E3d"><br>> Some more random sugar-related UI ideas:<br>><br>> -- Obviously, the 'preferences dialog box' becomes the 'preferences screen',<br>> to be selected via the toolbar tabs, as if it were a toolbar.
<br><br></div>I'm not sure this is necessarily obvious.  The tabs should really be<br>defining sets of tools, and not separate screens when at all possible.<br> Moreover, the design of palettes bears preferences in mind, with the
<br>intent that the secondary palette be used to provide contextual<br>preferences for the specific control.  In this manner, preferences<br>and/or parameters of the brush tool can appear in its secondary<br>palette.  We're steering away from global preferences as much as
<br>possible.<br><div class="Ih2E3d"></div></blockquote><div><br>Granted, and laudible. But I doubt they can be avoided altogether, even if you end up calling them something else. An email program, for instance, will always need its account settings... and yet you will not want the controls for that to be everpresent on the screen.
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>> -- The current Sugar spec on the wiki says almost nothing about the game
<br>> buttons - a good interface should allow give a consistent way for you to<br>> select any control or menu, including contextual menus, using just these<br>> buttons. As it is, the directional rocker is just useful for moving around
<br>> inside text, and the four shape buttons seem to move around rather than<br>> doing actions or changing modes (X=select, O=context menu, square=toggle<br>> focus from main window/toolbar/frame, which leaves check free as a modifier
<br>> key to use as shift with the arrow buttons... but that would be another<br>> thread)<br><br></div>Actually, while the HIG doesn't have too much to say on this yet, it<br>does outline clearly that the UI will transition to fullscreen (no
<br>toolbars) when in Handheld mode, and the cursor itself will be hidden<br>by default.  The shape buttons will then be assigned special functions<br>relevant to the current activity, providing a limited but tailored set
<br>of functions for the current activity.  The spec for Browse on the<br>wiki outlines in detail how this could work.<br><div class="Ih2E3d"></div></blockquote><div><br>'Special functions relevant to the current activity' is fancy talk for 'ad-hoc and obscure'. Some consistency is necessary - even if it's just cell-phone-like, with an indicator of what the buttons do when you press them (a little picture of the four buttons with meaningful text and icons next to them) which shows up in the corner next to them for a short time whenever you press one. 
<br><br>I would still advocate for a more comprehensive plan, like the one I began to sketch out in the original message included above. It puts the load on Sugar itself, instead of on the programmer of each individual acivity - an obvious advantage.
<br></div></div><br>Jameson<br>