[Sugar-devel] Monthly SOM for sugar-devel
Hi all, here's the monthly SOM for April's sugar-devel traffic (~700 emails): http://wiki.sugarlabs.org/go/Image:2009-April-Sugar_devel_som.jpg Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RELEASE] Browse-108
On Fri, May 1, 2009 at 6:46 PM, Martin Langhoff wrote: > Hi Simon, Sugaristas, > > Dave Bauer was asking where could he find recent Browse.xo releases, > and I did a bit of browsing and googling, and couldn't find it. > Searching my gmail inbox worked, but this isn't very generalisable. > Specifically I am looking for Browse.xo that includes Martin's patch for the Moodle cookie that will run on Sugar 0.82 on an XO running OS767. Does such a thing exist? I tried Browse-101.xo that I found from searching google and that didn't work. And Browse-103 from activities.sugarlabs.org doesn't contain the cookie code. Thanks Dave > > - sugarlabs' list archive is not indexed by google? > - activities download page is wildly out of date...? (lists Browse 103!) > - finding the git repo of Browse is rather hard :-( > > Please don't take this as a criticism -- just a note that it's > currently rather hard to find things. Maybe sugarlabs.org is new and > un-crawled by the big google crawler in the sky. Maybe there's > something relatively easy you guys can do to keep the info > up-to-date... dunno. > > (I try to keep the XS info up to date, and fail at it as well... so I > know... ) > > cheers, > > > martin > > On Mon, Apr 6, 2009 at 7:37 PM, Simon Schampijer > wrote: > > == Source == > > > > > http://download.sugarlabs.org/sources/sucrose/fructose/Browse/Browse-108.tar.bz2 > > > > == Fixed tickets == > > > > * Browse hangs when trying to open file:/// #456 > > ___ > > Sugar-devel mailing list > > Sugar-devel@lists.sugarlabs.org > > http://lists.sugarlabs.org/listinfo/sugar-devel > > > > > > -- > martin.langh...@gmail.com > mar...@laptop.org -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RELEASE] Browse-108
On Sat, May 2, 2009 at 1:00 AM, Frederick Grose wrote: > http://wiki.sugarlabs.org/go/Activities/Browse would be the place to add > improvements. If you go to sugarlabs.org -> activities, search for 'browse', you land in http://activities.sugarlabs.org/en-US/sugar/addon/4024 which shows Browse 103. AIUI, that's the canonical place... m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RELEASE] Browse-108
On Fri, May 1, 2009 at 5:46 PM, Martin Langhoff wrote: > Hi Simon, Sugaristas, > > Dave Bauer was asking where could he find recent Browse.xo releases, > and I did a bit of browsing and googling, and couldn't find it. > Searching my gmail inbox worked, but this isn't very generalisable. > > - sugarlabs' list archive is not indexed by google? > - activities download page is wildly out of date...? (lists Browse 103!) > - finding the git repo of Browse is rather hard :-( > > Please don't take this as a criticism -- just a note that it's > currently rather hard to find things. Maybe sugarlabs.org is new and > un-crawled by the big google crawler in the sky. Maybe there's > something relatively easy you guys can do to keep the info > up-to-date... dunno. > > (I try to keep the XS info up to date, and fail at it as well... so I know... > ) The conical source of information on activities _should_ be activities.download.org. What activities download page were you looking at? They should all be pointing to activities.sugarlabs.org. But a point well taken we should work to improve activities.sugarlabs.org ranking on search engines. david > cheers, > > > martin > > On Mon, Apr 6, 2009 at 7:37 PM, Simon Schampijer wrote: >> == Source == >> >> http://download.sugarlabs.org/sources/sucrose/fructose/Browse/Browse-108.tar.bz2 >> >> == Fixed tickets == >> >> * Browse hangs when trying to open file:/// #456 >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> > > > > -- > martin.langh...@gmail.com > mar...@laptop.org -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RELEASE] Browse-108
http://wiki.sugarlabs.org/go/Activities/Browse would be the place to add improvements. On Fri, May 1, 2009 at 6:46 PM, Martin Langhoff wrote: > Hi Simon, Sugaristas, > > Dave Bauer was asking where could he find recent Browse.xo releases, > and I did a bit of browsing and googling, and couldn't find it. > Searching my gmail inbox worked, but this isn't very generalisable. > > - sugarlabs' list archive is not indexed by google? > - activities download page is wildly out of date...? (lists Browse 103!) > - finding the git repo of Browse is rather hard :-( > > Please don't take this as a criticism -- just a note that it's > currently rather hard to find things. Maybe sugarlabs.org is new and > un-crawled by the big google crawler in the sky. Maybe there's > something relatively easy you guys can do to keep the info > up-to-date... dunno. > > (I try to keep the XS info up to date, and fail at it as well... so I > know... ) > > cheers, > > > martin > > On Mon, Apr 6, 2009 at 7:37 PM, Simon Schampijer > wrote: > > == Source == > > > > > http://download.sugarlabs.org/sources/sucrose/fructose/Browse/Browse-108.tar.bz2 > > > > == Fixed tickets == > > > > * Browse hangs when trying to open file:/// #456 > > ___ > > Sugar-devel mailing list > > Sugar-devel@lists.sugarlabs.org > > http://lists.sugarlabs.org/listinfo/sugar-devel > > > > > > -- > martin.langh...@gmail.com > mar...@laptop.org -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RELEASE] Browse-108
Hi Simon, Sugaristas, Dave Bauer was asking where could he find recent Browse.xo releases, and I did a bit of browsing and googling, and couldn't find it. Searching my gmail inbox worked, but this isn't very generalisable. - sugarlabs' list archive is not indexed by google? - activities download page is wildly out of date...? (lists Browse 103!) - finding the git repo of Browse is rather hard :-( Please don't take this as a criticism -- just a note that it's currently rather hard to find things. Maybe sugarlabs.org is new and un-crawled by the big google crawler in the sky. Maybe there's something relatively easy you guys can do to keep the info up-to-date... dunno. (I try to keep the XS info up to date, and fail at it as well... so I know... ) cheers, martin On Mon, Apr 6, 2009 at 7:37 PM, Simon Schampijer wrote: > == Source == > > http://download.sugarlabs.org/sources/sucrose/fructose/Browse/Browse-108.tar.bz2 > > == Fixed tickets == > > * Browse hangs when trying to open file:/// #456 > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard shortcuts
Martin: > 1. What I think we're talking about: You're right. While I actually think that, with a cheatsheet, alt-f is slightly *more* discoverable (though less convenient/accessible) than F9, your point is good. Let's stop fighting for now and see what others say. I do have a question about implementation, though: I can use a custom gtk signal from the top level window to send "show-shortcuts" and "hide-shortcuts" signals. But I don't know if this is the right design. Is there a way to register a custom signal for all top-level windows, even non-pygdk ones? Is there a way for non-pygdk ones to ever hear it? [13:13] Or do I have to take a detour through DBUS and then back to gdk? (it would just be a detour I think; I'd still alert individual controls through the same signalling mechanism) [13:15] * homunq would welcome even non-expert opinions on this question, because I have little idea. Jameson ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard shortcuts
On Fri, May 01, 2009 at 12:59:52PM -0500, Jameson Quinn wrote: > > > > I don't see how the keys are more consistent - I'll have to > > re-read the proposal and the definition of "consistency". > > > ctrl (and all modifier combos including it): application shortcuts > alt: global sugar shortcuts > > > > > > > > I don't see why they're more discoverable, either - and my point you > > quoted was trying to point out why they didn't have to be: you have a > > whole other set of keys that are *meant* to be the ones discovered and > > used. > > > The idea is that holding alt shows a cheat sheet of global shortcuts. Also, > even without implementing that, it is easier to find single-mod shortcuts by > trial and error than it is to find multiple-mod ones. Wait, I've said the same thing twice[1] and I don't think it's coming across here: we don't need it to be more discoverable because we _already have a discoverable, *preferred* set_: F9-F11. Let's call this the "primary" set. We both agree the primary set is a) easy to use; b) most discoverable. So why steal another set of commonly used key combos? We don't *want* them to be the primary ones, so I don't see the consistent argument as very persuasive. Martin 1. What I think we're talking about: 1) your proposal has *three* ways to invoke Frame/Journal/View Source, and... 2) we both agree we want the minimum: two[2] 3) Now we're talking about *which* set to lose. I'm arguing we keep the existing, non-discoverable set because it: a) is available everywhere b) is very unlikely to conflict with existing usages c) exists already ...you're arguing we switch because i) it's more consistent with just alt- being the modifier ii) it's more discoverable 2. one set for discoverability and one-click, one because the discoverable ones will be different per keyboard and we need some fallback ones in case Sugar gets used on pgptDzIlvRw96.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard shortcuts
> Sorry, seemed to have missed a conversation here, what's with idea that > keys are not getting through to Sugar for emulators/Macs? I run > sugar-jhbuild here in F10 under VirtualBox on a Mac, and Soas images as > well. No problem with keys that I'm aware of. I have no experience in this regard. If this is true, all the more reason IMO to move from alt-shift- to just alt- Jameson ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard shortcuts
> > I don't see how the keys are more consistent - I'll have to > re-read the proposal and the definition of "consistency". ctrl (and all modifier combos including it): application shortcuts alt: global sugar shortcuts > > > I don't see why they're more discoverable, either - and my point you > quoted was trying to point out why they didn't have to be: you have a > whole other set of keys that are *meant* to be the ones discovered and > used. The idea is that holding alt shows a cheat sheet of global shortcuts. Also, even without implementing that, it is easier to find single-mod shortcuts by trial and error than it is to find multiple-mod ones. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard shortcuts
On 1 May 2009, at 18:21, Jameson Quinn wrote:
> 2009/5/1 Martin Dengler
> On Fri, May 01, 2009 at 10:48:08AM -0600, Jameson Quinn wrote:
> > OK, the grand unified proposal for these, after discussion on IRC
> and the
> > above is:
> > f,j,r,s,v,p,o -> frame, journal, rotate, say, view source,
> screenshot
> > ("print"), overlay (unimplemented)
>
> > [fjrsvp] = deprecated, but kept for emulator users on
> > MacOS.
>
> I'd say just "emulator users".
>
> > [fjrsvp] = preferred method for above, discoverable through
> holding alt
> > and reading the "cheat sheet".
> > F9-F12 = frame, journal, overlay, view source
> > 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.
>
> I don't see the need for [fjrsvp]: we have frame, journal, and
> view source available in one click via F9-F11 (IIUC your
> some-netbooks-share-F11-and-F12 comment), and we have the existing,
> ubiquitous fallbacks of [...]. Why deprecate the existing
> combinations in favor of combinations that are more likely to clash
> with existing applications?
>
> Because the keys are more consistent and discoverable. That's
> also why I don't just say "emulator users" above; the new keys would
> be available to non-mac emulator users. Finally, note that if the
> keys never get to sugar in macOS emulation, then activities
> already should be avoiding them.
Sorry, seemed to have missed a conversation here, what's with idea
that keys are not getting through to Sugar for emulators/Macs? I
run sugar-jhbuild here in F10 under VirtualBox on a Mac, and Soas
images as well. No problem with keys that I'm aware of.
--Gary
> > Insert = frame (redundant)
>
> What about CapsLock for Macs (non-emulation)?
>
> Honestly, if we want a consistent and more-useful remapping of
> CapsLock, we should consider making it control_R. But I'm ready to
> let others decide this, it's not a big deal for me.
>
>
>
> Martin
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard shortcuts
On Fri, May 01, 2009 at 11:21:45AM -0600, Jameson Quinn wrote: > 2009/5/1 Martin Dengler > > On Fri, May 01, 2009 at 10:48:08AM -0600, Jameson Quinn wrote: > > > [fjrsvp] = preferred method for above, discoverable through holding > > alt > > > and reading the "cheat sheet". > > > F9-F12 = frame, journal, overlay, view source > > > 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. > > > > I don't see the need for [fjrsvp]: we have frame, journal, and > > view source available in one click via F9-F11 (IIUC your > > some-netbooks-share-F11-and-F12 comment), and we have the existing, > > ubiquitous fallbacks of [...]. Why deprecate the existing > > combinations in favor of combinations that are more likely to clash > > with existing applications? > > > Because the keys are more consistent and discoverable. That's also why > I don't just say "emulator users" above; the new keys would be available to > non-mac emulator users. Finally, note that if the keys never get to > sugar in macOS emulation, then activities already should be avoiding them. I don't see how the keys are more consistent - I'll have to re-read the proposal and the definition of "consistency". I don't see why they're more discoverable, either - and my point you quoted was trying to point out why they didn't have to be: you have a whole other set of keys that are *meant* to be the ones discovered and used. Martin pgpWw5PG0wxch.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard shortcuts
2009/5/1 Martin Dengler
> On Fri, May 01, 2009 at 10:48:08AM -0600, Jameson Quinn wrote:
> > OK, the grand unified proposal for these, after discussion on IRC and the
> > above is:
> > f,j,r,s,v,p,o -> frame, journal, rotate, say, view source, screenshot
> > ("print"), overlay (unimplemented)
>
> > [fjrsvp] = deprecated, but kept for emulator users on
> > MacOS.
>
> I'd say just "emulator users".
>
> > [fjrsvp] = preferred method for above, discoverable through holding
> alt
> > and reading the "cheat sheet".
> > F9-F12 = frame, journal, overlay, view source
> > 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.
>
> I don't see the need for [fjrsvp]: we have frame, journal, and
> view source available in one click via F9-F11 (IIUC your
> some-netbooks-share-F11-and-F12 comment), and we have the existing,
> ubiquitous fallbacks of [...]. Why deprecate the existing
> combinations in favor of combinations that are more likely to clash
> with existing applications?
Because the keys are more consistent and discoverable. That's also why
I don't just say "emulator users" above; the new keys would be available to
non-mac emulator users. Finally, note that if the keys never get to
sugar in macOS emulation, then activities already should be avoiding them.
>
>
> > Insert = frame (redundant)
>
> What about CapsLock for Macs (non-emulation)?
Honestly, if we want a consistent and more-useful remapping of CapsLock, we
should consider making it control_R. But I'm ready to let others decide
this, it's not a big deal for me.
>
>
> Martin
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard shortcuts
On Fri, May 01, 2009 at 10:48:08AM -0600, Jameson Quinn wrote:
> OK, the grand unified proposal for these, after discussion on IRC and the
> above is:
> f,j,r,s,v,p,o -> frame, journal, rotate, say, view source, screenshot
> ("print"), overlay (unimplemented)
> [fjrsvp] = deprecated, but kept for emulator users on
> MacOS.
I'd say just "emulator users".
> [fjrsvp] = preferred method for above, discoverable through holding alt
> and reading the "cheat sheet".
> F9-F12 = frame, journal, overlay, view source
> 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.
I don't see the need for [fjrsvp]: we have frame, journal, and
view source available in one click via F9-F11 (IIUC your
some-netbooks-share-F11-and-F12 comment), and we have the existing,
ubiquitous fallbacks of [...]. Why deprecate the existing
combinations in favor of combinations that are more likely to clash
with existing applications?
> Insert = frame (redundant)
What about CapsLock for Macs (non-emulation)?
Martin
pgpXlfoK8uLIJ.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard shortcuts
Eben, I'd like your comments on the discoverable/floaty-letters idea too.
2009/5/1 Eben Eliason
>
>
> > I'd vote for caps lock. This is, of course, somewhat more radical than
> most
> > of my other suggestions, so needs discussion.
>
> Hmmm, not sure. It seems to me that if the zoom-level buttons live in
> the F-keys, then the Frame button should as well. This keeps it at the
> top of the keyboard, as on the XO, and keeps a consistent single-key
> path to a very important element of the UI.
>
> And, for what it's worth, I don't think that activities should need to
> mess around with the F keys. I'd just as soon have banished them
> entirely, as the caps lock key, were they not required for
> compatibility. I think that activities should be using, for the most
> part, the ctrl shortcuts. Perhaps F5 - F8 should be reserved so that
> they can serve for the middle slider on the XO, and we can make one of
> F9 - F12 the Frame key?
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).
>
> I find the alt-shift-n suggestion to be highly confusing myself. It
> sounds like a good way to accidentally close things, and I'm not sure
> I see the need in the end. Just press alt-n to switch to the activity,
> followed by alt-esc...
OK, that was just an offhand idea.
> >>> # the following are intended for emulator users
> >>> #'f': 'frame', #removed
> >>> #'o': 'open_search', #removed
> >>> #'r': 'rotate', #removed
> >>
> >> Why the removals?? Now I would have no working keys at all for accessing
> >> the frame!
> >
> > Because they're inconsistent with the master plan, and
> > highly-non-discoverable too.
>
> Could we map any of those that would be dropped in the F9 - F12 range?
> For consistency, I guess we should have an "overlay" key there next to
> the frame key. Could rotate and/or search live there as well?
OK, the grand unified proposal for these, after discussion on IRC and the
above is:
f,j,r,s,v,p,o -> frame, journal, rotate, say, view source, screenshot
("print"), overlay (unimplemented)
[fjrsvp] = deprecated, but kept for emulator users on MacOS.
[fjrsvp] = preferred method for above, discoverable through holding alt
and reading the "cheat sheet".
F9-F12 = frame, journal, overlay, view source
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.
Insert = frame (redundant)
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.
>
> >>
> >> --- snip ---
> >>
> >>> ...
> >>> Also, ctrl-numeral would choose toolbars, and toolbar tabs would get
> >>> little translucent numbers when you held control.
> >>
> >> So what happens to an activity that uses some ctrl-numerals already
> >> (labyrinth does)?
> >
> > could it use F5-F8? I don't know what it does with these. In practice,
> the
> > activity could get them by assigning them before creating that toolbar;
> > ideally, I'd like this to be a consistent standard.
>
> Hmm, I can see ctrl-n being useful to many activitiesbut tab
> switching would be advantageous as well. Could we use relative
> navigation for tabs, in the form of alt-right and alt-left, or
> similar? This might be more intuitive for kids than counting, and
> would't eat up as much of the shortcut space.
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->).
Jameson
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SD card / USB stick support
Sascha, In regard to my comment: > [...] it would store meta info for the books, as well as the content > type of the book (which the MIME type by itself would not be enough to > do). what I meant was that there are some MIME types mapped to more than one Activity. For instance, the MIME type text/plain is used by Read Etexts but also by the Write activity. application/zip is used by Etoys, View Slides, and Read Etexts. Because of this you cannot simply click on an entry in the Journal that has one of these MIME types to resume it. You need to specify which Activity you want to open it with. You need to do this every single time, and it's annoying. The real answer to this is not what I talked about in that email. The real answer is to implement "Unified Bundles" which package books up like Activities and have a configuration file that says how they should be opened: as a bunch of images in a Zip file, as a plain text file, etc. That way when I try to read a Gutenberg text file I don't have to deal with opening Write by mistake, and when I'm viewing a comic book I don't have to deal with opening Etoys by mistake. Journal entries created by an Activity are always resumed by that Activity. It's the Activities that DON'T create their own Journal entries that have this issue. This problem makes Sugar less usable as a platform for reading ebooks, which is a shame because ebook reading could be a killer app for Sugar and the XO otherwise. Unified Bundles were proposed a couple of weeks ago as a way of dealing with these problems and others. I regards to your point on the SD card, I would love for it to act as a second Journal. Failing that, it should have a view in the Journal that communicates to the user that it is NOT a second Journal. Maybe a Windows Explorer kind of view that shows subdirectories, etc. The current situation where it LOOKS like a Journal but doesn't ACT like one (no metadata saved, etc.) is annoying. And whatever you do with the SD card the USB thumb drive should definitely have an Explorer look and feel. It is something foreign to Sugar and it should look that way. James Simmons Sascha Silbe wrote: > > Following up on a discussion on iaep... > > On Wed, Apr 29, 2009 at 04:10:59PM -0500, James Simmons wrote: > >> The SD card cannot do everything the Journal can do, [...] > This is something that we should fix. The way the SD card / USB stick > support works (in Sugar 0.82.1 on the XO) has bugged me for the past > few days (e.g. only FAT filesystems will be usable from inside the > Journal). > Maybe it could work roughly like the following (just a brain dump): > - automount everything, with UUID-based access (/media/by-uuid/) > in addition to the current name-based access > (/media/[_]) > - use "flag files" (empty file with well-known name, e.g. > ".sugar_datastore_ignore") on the filesystem to filter it out from the > Journal (so it doesn't index/show the wwwoffle cache) > - let the user unmount Journal-monitored filesystems from the command > line (regular umount doesn't work because the fs is busy) > > This way SD cards and USB sticks can be used as both a Journal > expansion and low-level storage expansion (using symlinks to > /media/by-uuid/...), even in parallel (on the same device). > > [book reading activity] >> [...] it would store meta info for the books, as well as the content >> type of the book (which the MIME type by itself would not be enough >> to do). > What do you mean with "content type" if the MIME type is not enough > (but apparently closely related)? > > CU Sascha > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard shortcuts
On Fri, May 1, 2009 at 9:04 AM, Jameson Quinn wrote: > (note: I suggest below that we use caps-lock as the frame key) > > 2009/4/30 Gary C Martin >> >> Still think this is a tough, disruptive sell for very small gains. We >> should focus on getting activity authors (and sugar) using the now fully >> functioning accelerator feature to self document shortcuts. > > Which part? This is actually three separate proposals: "discoverable" > (translucent letters), "ubiquitous" (auto-assignment), and "consistent" > (rearranging). Your comments about "consistent" are below, but I don't know > if the above refers to "discoverable" or "ubiquitous". If you mean that > ubiquity is a small gain, noted; if you mean discoverability, I disagree and > would like to hear you elaborate your argument. > > Also, since I'm coding, "tough" is a weak criticism. > > >> >> Anyway, just some quick comments: > > and responses > >> >> >> On 1 May 2009, at 03:28, Jameson Quinn wrote: >> >>> I am interested in making our keyboard shortcuts discoverable, >>> ubiquitous, and consistent. >> >> --- snip --- >> >>> '0x93' : 'frame', >>> 'Insert' : 'frame', #for SoaS >>> '0x00' : 'frame', #for SoaS on Xephyr, see below. >> >> None of my 3 Mac laptops has an Insert key, and the standard keyboard that >> ships with iMac desktops also has no insert. Think all Macs currently ship >> with such keyboards, sans numeric pad, though you can make a custom order >> for "Apple Keyboard with Numeric Keypad"... actually, just checked that key >> layout as well and no insert key either – but hey, you get 19 function keys >> for your money ;-) >> >> --- snip --- > > I hadn't seen this, I only knew from wikipedia that if your keyboard does > have insert Apple sees it as "help". Looking at a few pictures of Macbook > keyboards, I have to say I like the minimalism, but it leaves few options. > F5-F8 should ideally IMO be available to individual activities. That leaves > caps lock, or key combos (I'd favor close-up combos such as > alt-right_arrow.) > > I'd vote for caps lock. This is, of course, somewhat more radical than most > of my other suggestions, so needs discussion. Hmmm, not sure. It seems to me that if the zoom-level buttons live in the F-keys, then the Frame button should as well. This keeps it at the top of the keyboard, as on the XO, and keeps a consistent single-key path to a very important element of the UI. And, for what it's worth, I don't think that activities should need to mess around with the F keys. I'd just as soon have banished them entirely, as the caps lock key, were they not required for compatibility. I think that activities should be using, for the most part, the ctrl shortcuts. Perhaps F5 - F8 should be reserved so that they can serve for the middle slider on the XO, and we can make one of F9 - F12 the Frame key? > >> >>> 'Escape' : 'close_window_discard_from_journal', >> >> >> Not sure what this one is. > > Close the activity but don't show the naming dialog. Delete the resulting > journal entry. Makes sense. A nice use of alt in the desired manner. >> >> --- snip --- >> >>> #... alt-numeral should be like the top row of the frame, so alt-5 would >>> be journal >>> #and alt-6 first running activity >> >> >> So is the reason behind this idea to help keyboards without any F keys? >> Should this not also include the F5 key being made to show the Journal >> (equiv. to open_search I think). > > This is for keyboards without F keys, but it also gives a natural way to get > the journal and individual activities. alt-shift-N with N>5 could be "close > activity N-5". I think that F5 should be available to individual activities, > so I'd vote against F5/Journal. I'd accept the majority decision, though. Yeah, I think using the alt- shortcuts for the Journal is logical. It would be more logical if we didn't have to duplicate F1 - F4 with alt-1 through alt-4, since then the Journal could just be alt-1, but for keyboards without F keys I guess we need the duplication. I agree, as mentioned above, that F5 - F8 should be left open, to mirror the middle slider on the XO. I find the alt-shift-n suggestion to be highly confusing myself. It sounds like a good way to accidentally close things, and I'm not sure I see the need in the end. Just press alt-n to switch to the activity, followed by alt-esc... >> >> --- snip --- >> >>> # the following are intended for emulator users >>> # 'f' : 'frame', #removed >>> # 'o' : 'open_search', #removed >>> # 'r' : 'rotate', #removed >> >> Why the removals?? Now I would have no working keys at all for accessing >> the frame! > > Because they're inconsistent with the master plan, and > highly-non-discoverable too. Could we map any of those that would be dropped in the F9 - F12 range? For consistency, I guess we should have an "overlay" key there next to the frame key. Could rotate and/or search live there as well?
Re: [Sugar-devel] Keyboard shortcuts
(note: I suggest below that we use caps-lock as the frame key) 2009/4/30 Gary C Martin > Still think this is a tough, disruptive sell for very small gains. We > should focus on getting activity authors (and sugar) using the now fully > functioning accelerator feature to self document shortcuts. Which part? This is actually three separate proposals: "discoverable" (translucent letters), "ubiquitous" (auto-assignment), and "consistent" (rearranging). Your comments about "consistent" are below, but I don't know if the above refers to "discoverable" or "ubiquitous". If you mean that ubiquity is a small gain, noted; if you mean discoverability, I disagree and would like to hear you elaborate your argument. Also, since I'm coding, "tough" is a weak criticism. > > > Anyway, just some quick comments: and responses > > > On 1 May 2009, at 03:28, Jameson Quinn wrote: > > I am interested in making our keyboard shortcuts discoverable, ubiquitous, >> and consistent. >> > > --- snip --- > > '0x93' : 'frame', >>'Insert' : 'frame', #for SoaS >>'0x00' : 'frame', #for SoaS on Xephyr, see below. >> > > None of my 3 Mac laptops has an Insert key, and the standard keyboard that > ships with iMac desktops also has no insert. Think all Macs currently ship > with such keyboards, sans numeric pad, though you can make a custom order > for "Apple Keyboard with Numeric Keypad"... actually, just checked that key > layout as well and no insert key either – but hey, you get 19 function keys > for your money ;-) > > --- snip --- > I hadn't seen this, I only knew from wikipedia that if your keyboard does have insert Apple sees it as "help". Looking at a few pictures of Macbook keyboards, I have to say I like the minimalism, but it leaves few options. F5-F8 should ideally IMO be available to individual activities. That leaves caps lock, or key combos (I'd favor close-up combos such as alt-right_arrow.) I'd vote for caps lock. This is, of course, somewhat more radical than most of my other suggestions, so needs discussion. > > > 'Escape': 'close_window_discard_from_journal', >> > > > Not sure what this one is. > Close the activity but don't show the naming dialog. Delete the resulting journal entry. > > --- snip --- > > #... alt-numeral should be like the top row of the frame, so alt-5 would >> be journal >> #and alt-6 first running activity >> > > > So is the reason behind this idea to help keyboards without any F keys? > Should this not also include the F5 key being made to show the Journal > (equiv. to open_search I think). > This is for keyboards without F keys, but it also gives a natural way to get the journal and individual activities. alt-shift-N with N>5 could be "close activity N-5". I think that F5 should be available to individual activities, so I'd vote against F5/Journal. I'd accept the majority decision, though. > > --- snip --- > > # the following are intended for emulator users >> #'f': 'frame', #removed >> #'o': 'open_search', #removed >> #'r': 'rotate', #removed >> > > Why the removals?? Now I would have no working keys at all for accessing > the frame! > Because they're inconsistent with the master plan, and highly-non-discoverable too. > > --- snip --- > > ... >> Also, ctrl-numeral would choose toolbars, and toolbar tabs would get >> little translucent numbers when you held control. >> > > So what happens to an activity that uses some ctrl-numerals already > (labyrinth does)? > could it use F5-F8? I don't know what it does with these. In practice, the activity could get them by assigning them before creating that toolbar; ideally, I'd like this to be a consistent standard. > > For my bike-shed, I'd be happy with F1-F4 as is, F5 can be Journal, F6 > could be frame, then we could make little bits of printed card with icons > on, and kids could sticky-tape them just above their F keys ;-) > OK, that's a vote. I vote against you. May the best bike-shed win! (And since I don't understand what your position on discoverable and ubiquitous is, I can't count your vote there). Jameson ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
