Eben, I'd like your comments on the discoverable/floaty-letters idea too.<br><br><div class="gmail_quote">2009/5/1 Eben Eliason <span dir="ltr"><<a href="mailto:eben.eliason@gmail.com">eben.eliason@gmail.com</a>></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div><div class="h5"><br> > I'd vote for caps lock. This is, of course, somewhat more radical than most<br> > of my other suggestions, so needs discussion.<br> <br> </div></div>Hmmm, not sure. It seems to me that if the zoom-level buttons live in<br> the F-keys, then the Frame button should as well. This keeps it at the<br> top of the keyboard, as on the XO, and keeps a consistent single-key<br> path to a very important element of the UI.<br> <br> And, for what it's worth, I don't think that activities should need to<br> mess around with the F keys. I'd just as soon have banished them<br> entirely, as the caps lock key, were they not required for<br> compatibility. I think that activities should be using, for the most<br> part, the ctrl shortcuts. Perhaps F5 - F8 should be reserved so that<br> they can serve for the middle slider on the XO, and we can make one of<br> F9 - F12 the Frame key?</blockquote><div><br>OK, but what do we do with the volume/brightness controls that are currently in F9-12? The other issue is that keyboards are inconsistent with the high F keys - for instance, the classmate has F11/F12 on the same key (ie, F12 is fn-F11).<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> <br> I find the alt-shift-n suggestion to be highly confusing myself. It<br> sounds like a good way to accidentally close things, and I'm not sure<br> I see the need in the end. Just press alt-n to switch to the activity,<br> followed by alt-esc...</blockquote><div><br>OK, that was just an offhand idea.<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;"> <div class="im"><br> >>> # the following are intended for emulator users<br> >>> # '<alt><shift>f' : 'frame', #removed<br> >>> # '<alt><shift>o' : 'open_search', #removed<br> >>> # '<alt><shift>r' : 'rotate', #removed<br> >><br> >> Why the removals?? Now I would have no working keys at all for accessing<br> >> the frame!<br> ><br> > Because they're inconsistent with the master plan, and<br> > highly-non-discoverable too.<br> <br> </div>Could we map any of those that would be dropped in the F9 - F12 range?<br> For consistency, I guess we should have an "overlay" key there next to<br> the frame key. Could rotate and/or search live there as well?</blockquote><div><br>OK, the grand unified proposal for these, after discussion on IRC and the above is:<br>f,j,r,s,v,p,o -> frame, journal, rotate, say, view source, screenshot ("print"), overlay (unimplemented)<br> <alt><shift>[fjrsvp] = deprecated, but kept for emulator users on MacOS. <br><alt>[fjrsvp] = preferred method for above, discoverable through holding alt and reading the "cheat sheet".<br>F9-F12 = frame, journal, overlay, view source <br> <div style="margin-left: 80px;">This order is changed from the XO, because of netbook keyboards missing dedicated F11/F12 keys. I'm agnostic about view source needing a dedicated key.<br></div>Insert = frame (redundant)<br> xo keymaps revised so that the volume and brightness controls are NOT F9-F12, but XF86AudioLowerVolume etc. F9-F12 would not be available from the XO keyboard.<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="im"><br> >><br> >> --- snip ---<br> >><br> >>> ...<br> >>> Also, ctrl-numeral would choose toolbars, and toolbar tabs would get<br> >>> little translucent numbers when you held control.<br> >><br> >> So what happens to an activity that uses some ctrl-numerals already<br> >> (labyrinth does)?<br> ><br> > could it use F5-F8? I don't know what it does with these. In practice, the<br> > activity could get them by assigning them before creating that toolbar;<br> > ideally, I'd like this to be a consistent standard.<br> <br> </div>Hmm, I can see ctrl-n being useful to many activities....but tab<br> switching would be advantageous as well. Could we use relative<br> navigation for tabs, in the form of alt-right and alt-left, or<br> similar? This might be more intuitive for kids than counting, and<br> would't eat up as much of the shortcut space.</blockquote><div><br>I'd prefer ctrl-something, as it would make it easier to find shortcuts while holding ctrl. I think arrow keys is dangerous, plenty of editors want ctrl-arrow to mean something. The options then are "[" and "]"; "," and "."; ";" and "'"; or "-" and "+". Of these, I think that "," and "." are the best combination of logical (think < and >), non-obscure, and uncommon-as-existing-shortcuts (ctrl-bracket and ctrl-plus are too common). The floaty discoverable letters could show < and > on the next and previous tabs. This is a bit more work to code than just the numbers, but it's doable. The downside is keyboard layouts which move these keys around, but I don't see an easy solution for that (except to redundantly map ctr-< and ctrl->).<br> <br>Jameson<br></div></div><br>