Re: eBook Reader user interface
I have been collecting a few (more than a few) usability bugs and UI suggestions, which will hopefully be compiled to a list next month. In the meanwhile, I would like to share a couple of ideas regarding the mapping of the gamepad keys [which I hope won't state the obvious too much]. Currently, the UP/DOWN/LEFT/RIGHT keys have a fixed functionality regardless of the screen orientation. This isn't a correct logic, as the expected functionality changes according to the current orientation. I guess the easiest way to implement this kind of behavior would be using a smart key mapping mechanism in X. Another thought -- the current input method treats those keys as direction keys. However, a better input method may be emulating the functionality of the mouse (touch pad) using the gamepad keys. In tablet mode this can really improve the user experience. Just my $0.04. Zvi Don Hopkins wrote: Goal for improving the eBook reader user interface: I've been doing some exploratory programming with GTK and Sugar, trying to improve the user interface of the eBook reader, and make it useable in book mode with the gamepad. + Support the game keypads in eBook mode. + Low level game keypad support Need to remap low level keyboard scan codes to Linux keyboard codes. The setolpckeys.c program remaps the keys and gamepad buttons. Currently it maps both gamepads to the numeric keypad keys (KEY_KP8, etc), which the X server and GDK translates to directional keys (GDK_Up, etc). I tried to map them to buttons (BTN_A, etc), but the X server seems to ignore keycodes in that range. The xorg.conf file has a keycode mask that looked like it might help, but I couldn't get it to work. Need to have unique keycodes reported for each of the two gamepads, which are not the same as any keyboard keys, without any predefined meanings like arrow keys have. Need to define special purpose keycodes just for the OLPC gamepad, instead of trying to reuse existing but not appropriate keycodes. What is the process for defining new keycodes in linux/input.h? Here's my strawman proposal for some new keycodes. Use keys (KEY_*) instead of buttons (BTN_*), since they seem to work better. The 0x1b* range seems to be unused in linux/input.h, and it's between other groups of keycodes, so I'll propose using that range for the OLPC. The UP/DOWN/LEFT/RIGHT keys correspond to the directional keypad. #define KEY_XO_GAMEPAD_UP 0x1b0 #define KEY_XO_GAMEPAD_DOWN0x1b1 #define KEY_XO_GAMEPAD_LEFT0x1b2 #define KEY_XO_GAMEPAD_RIGHT 0x1b3 The NORTH/SOUTH/EAST/WEST keys correspond to the other buttons. Those names are agnostic to the button labels, which may change from the current Playstation buttons (X/O/Triangle/Square). Can anyone suggest better names for the four buttons on the right? #define KEY_XO_GAMEPAD_NORTH 0x1b4 #define KEY_XO_GAMEPAD_SOUTH 0x1b5 #define KEY_XO_GAMEPAD_EAST0x1b6 #define KEY_XO_GAMEPAD_WEST0x1b7 While we're at it, we could define keycodes for the other OLPC buttons and switches on the screen. I think there are some other sensor switches that could generate keycodes, like opening the screen, rotating it around, and putting it into book mode, so I will make some guesses at names for them, just to get the discussion rolling. #define KEY_XO_SCREEN_ROTATE 0x1b8 #define KEY_XO_SCREEN_POWER0x1b9 #define KEY_XO_SCREEN_OPEN 0x1ba #define KEY_XO_SCREEN_CLOSE0x1bb #define KEY_XO_SCREEN_IN 0x1bc #define KEY_XO_SCREEN_OUT 0x1bd Is there an exhaustive list of all buttons and switches and events on the OLPC? Are any more planned? Which ones should be assigned keycodes? Rewrote setolpckeys.c code in Python (just uses ioctl, but needs to know keycodes). Writing utilities like that in Python instead of C makes it easier to reconfigure the keys on the OLPC without a C compiler. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Spreadsheets/ Slideshows
You might want to check out what Etoys actually does and is. (Hint: it covers your desiderata beIow pretty well.) I suggest perusing the document that I made up for the OLPC countries meeting a few weeks ago. Nia Lewis will probably have a copy. Cheers, Alan At 07:50 AM 6/2/2007, Eben Eliason wrote: Ever since this project began, I've had this idea in my head regarding what a slideshow might mean on the OLPC machine. I'd really like to see an activity called Collage which is something like a modern descendent of Hypercard. It should take the idea of embedding media further, of course allowing images, sounds, video and text, but perhaps also supporting live logo turtles, live editable text boxes and other interactive forms. Ideally, there would be an interface which made it pluggable so that any activity could embed its formats and provide hooks for interacting with it. Bringing it all together, it should support a basic logo-like scripting language. This could allow simple actions like next page, but could also be allowed to pull text from the live text boxes via some identifiers, animate the embedded objects, track some basic mouse and keyboard events, and interact with hooks provided by the plugins. A child could create a single page, or a simple slideshow, but by taking full advantage of the nature of the scripting which pulls things together, they can create non-linear books, interactive animations, science reports with embedded interactive experiments, games, and more. As fun as this would be for kids, I also see this as being a fantastic format for teachers to create lesson plans in: provide some instructions with text and images, embed a video about the topic, script up a little physics simulation that the kids can experiment with, embed an abiword table widget which automatically records the results of the experiment, and place some questions with textboxes at the end so the kids can answer them and then turn in their lab. Heck, you could even automatically check the answers when they are done, or interactively assist them when they answer incorrectly, nudging them along or referencing the results table again. - Eben On 6/2/07, Rebecca Gettys [EMAIL PROTECTED] wrote: Hi All, I think that sideshows CAN be very sueful in the class room, and they have actually taught be to pay attention to detail. You need notes to do anything really, and they do have their applications with other students. Just a thought. ~Rebecca ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Doc now posted (was Re: [sugar] Spreadsheets/ Slideshows)
Hi SJ -- Yes, you may certainly make the document public. I will try to add the remaining 50 pages sometime in late June and early July, but I tried to make the existing 50 pages stand on its own. The document is now linked from the etoys page in the wiki (Thanks to Walter for doing this): See http://wiki.laptop.org/go/Etoys and http://www.laptop.org/OLPCEtoys.pdf P.S. I still think that what I've been advocating since early last year -- an OLPC version of something like Etoys/Scratch/Logo that is deeply integrated with OLPC media -- is a really good idea. There is nothing sacred about Etoys. It only has two main things going for it (a) it has been tested with many thousands of children around the world over the last 10 years, and (b) its range of applications for children's authoring using math and media. The weakness of Etoys is that it is primarily aimed at 4-5-6 graders (and does well with this age group). It has been used successfully in Japan with 6 and 7 year olds despite the UI not being the best fit for them. And it has been used with older children as well (they need a few more features from the underlying Squeak and a somewhat different UI -- some of which we are doing this summer). OTOH, the presentation facilities are pretty useful -- especially for dynamic presentations of actual work. I've been using them exclusively for all my talks since about 1998. But quite a bit could be done better on all fronts. For the OLPC XO, especially wrt to integration both across and down (so that there is a Model T version of all the media in children's script, and all media objects can be mixed). Since Python was chosen as the underlying programmatic representation for the XO, I tried to convince the Python community last year to take a shot at making an Etoys-like environment, but as far as I can tell there have been no takers. I think Ivan has some interest in this as well. So I agree with the nature of Eben's desires. The key word is integration, and, as you well know, this is a lot harder - both in design and integration - to pull off gracefully than it it seems at first glance. I would be very happy to see an environment that is as comprehensive as (or more ideally, much better than) Etoys -- especially if it can be placed at a more fundamental level than as a separate Activity. (That was actually my original hope for Sugar.) Cheers, Alan At 12:24 PM 6/2/2007, Samuel Klein wrote: Eben, this might be a great opportunity to spend some time with the etoys team working out how you could realize what you have in mind with existing tools. As Alan notes, it is designed to do very much what you are writing about -- as well as doing some excellent sugar 1200x900 emulation ;-) I'd like to spend a day this coming week working through Alan's 50-of-100 notes, and the use cases you have in mind. (Alan, can we make the document public?) As for presentations and slides, Etoys remains for the time being our supported method for importing .ppt -- Rebecca, have you tried this? Were you asking for something more specific? SJ ps - That might also be a good opportunity to think about what a generic bundle looks like. On 6/2/07, Alan Kay [EMAIL PROTECTED] wrote: You might want to check out what Etoys actually does and is. (Hint: it covers your desiderata beIow pretty well.) I suggest perusing the document that I made up for the OLPC countries meeting a few weeks ago. Nia Lewis will probably have a copy. Cheers, Alan At 07:50 AM 6/2/2007, Eben Eliason wrote: Ever since this project began, I've had this idea in my head regarding what a slideshow might mean on the OLPC machine. I'd really like to see an activity called Collage which is something like a modern descendent of Hypercard. It should take the idea of embedding media further, of course allowing images, sounds, video and text, but perhaps also supporting live logo turtles, live editable text boxes and other interactive forms. Ideally, there would be an interface which made it pluggable so that any activity could embed its formats and provide hooks for interacting with it. Bringing it all together, it should support a basic logo-like scripting language. This could allow simple actions like next page, but could also be allowed to pull text from the live text boxes via some identifiers, animate the embedded objects, track some basic mouse and keyboard events, and interact with hooks provided by the plugins. A child could create a single page, or a simple slideshow, but by taking full advantage of the nature of the scripting which pulls things together, they can create non-linear books, interactive animations, science reports with embedded interactive experiments, games, and more. As fun as this would be for kids, I also see this as being a fantastic format for teachers to create lesson plans in: provide some instructions with text and images, embed a video about the topic, script up a little physics
Re: Using --excludedocs and --excludepath with yum
On Sun, 2007-06-03 at 23:37 -0400, Bernardo Innocenti wrote: Is it possible? This would reduce the amount of postprocessing we need to do when building OLPC images. excludedocs can be done using the ability to set macros which are available within the rpm-python api, so you could easily write a plugin to handle this, or use a macro file in /etc/rpm/macros.nodocs or something. Excludepath is essentially a special case (NULL) relocation, and relocations currently aren't supported within rpm-python. Paul ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Unwanted RPM dependencies
David Zeuthen wrote: - hal depends on cryptsetup-luks (containing bulky 1.2MB static binary in /sbin) Probably cryptsetup doesn't need to be linked statically anymore; Peter Jones would know. Yeah, I don't think it needs to be. I guess I should just remove the static build in the package itself. -- Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: White background with OLPC logo
On 05/06/07 11:28 -0400, Bernardo Innocenti wrote: David Woodhouse wrote: This hasn't a whelk's chance in a supernova of going upstream, Why? The bright color theme patch is nicely configurable and generally useful on any platform. But its not - your patch just adds our specific scheme which is just as arbitrary and inflexible as the original scheme. Unfortunately, this is not a solution that scales very well for every Tom, Dick and Harry that want the console colors to be their corporate color scheme (Of course, I vote for AMD Green #007A51). And that doesn't even get into the whole logo discussion - but needless to say, if you were unwilling to post the logo here for fear of size, then thats probably not something that Linus will willingly take into the kernel for us. It's not as if these machines should actually be rebooting very often during normal operation anyway. Hopefully, yes. However, the boot sequence is the very first thing the user sees when they turn on the laptop for the first time. And nearly everybody I have talked to agrees that they will see some sort of splash screen all the way until Sugar loads. How or why this will actually get done is a matter of some discussion, but I think everybody can agree that in normal operation that nobody will see the kernel boot process, nor the logo. Oh - wait, you argue, what about the developers that want to see debug messages? I ask you - do we really need to carry around many K of bytes so they can see a stylized logo and a white on black screen during boot? I vote not. And if you have shown the laptop to some muggles, you'll surely noticed their expressions change when they see our 80's fashioned text console in an otherwise cute green laptop. I always need to justify it with some excuse such as err... this is to help us debugging the system, it's not really meant for the end user. Exactly - so why is any of this even useful to the end user? Jordan -- Jordan Crouse Senior Linux Engineer Advanced Micro Devices, Inc. www.amd.com/embeddedprocessors ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] eBook Reader user interface
On Tue, 2007-06-05 at 12:38 -0700, Don Hopkins wrote: print Hello world! I have made a version of the Read activity that supports navigation and control with the gamepad, and has a few new features and improvements. The main problem is getting the two gamepads to send unique keycodes that are not the numeric keypad arrow keys it currently sends (because those are already bound to functions that don't do the appropriate thing). The problem right now is that somebody needs to run the command chmod a+rwx /dev/input/event1 to give Python the permission to perform the ioctl that remaps the keys. The solution to that problem is to decide on a standard set of keycodes and have the operating system set them when it boots. I have tried several sets of keycodes, unsuccessfully. The higher keycodes with numbers 512 never seem to make it to the X server. I tried using the keycodes for the higher numbered function keys (KEY_F13 [183] - KEY_F20 [190]), which made it to the X server, but all report X keycodes 0. There may be some magic that needs to be done in the /etc/X11/xorg.conf file to admit those keycodes, or maybe some other arcane X server configuration. So for now I am mapping to the letters esdx and ijkm to test out the gamepad code until the OLPC has a fixed set of distinguishable keypad keycodes. It will be very nice to have a gamepad text input method like triggerfinger or dasher, to input real text in book mode! The next issue is rotation. I have made the activity respond to top level window resize events by running xrandr to figure out which direction the screen is rotated. I think the plan here is to have Sugar or the hardware manager send out events so that activities know when the screen is rotated. Then it remaps the behaviors it assigns to the gamepads according to the screen rotation. I think screen rotation should be handled by the application, not the operating system, because in some cases the application might want to associate commands with the LABELS of the gamepad keys instead of the DIRECTIONS of the keys, so it would not want to rotate their meaning. So basically, you mean not _rotation_ handled by the activity, but allowing the game button meanings to be specified by the activity depending on variables like rotation, right? For example, a tic-tac-toe game that wanted to use X for X and O for O would not want to remap the keys on screen rotation! (Admittedly contrived, but hey it's a popular game!) c(-; It would be great if there were a way to find out the screen rotation via dbus. Maybe there is but I just haven't figured it out yet. Could we add that, if it's not yet supported, please? Yes, that's the way it should work. Also, I wrote some stuff in the comments of the bug about the screen rotation button: it's way too easy to rotate the screen accidentally (not to mention turn the machine off accidentally, ESPECIALLY when the screen is upside down and you reach for what you think is the rotation button!!!)... The power button functionality will be changed to put the machine to sleep rather than power off. We may have a 2-second timeout before it sleeps though, to alleviate this problem further. Note that it's the EC that dictates the 4-second poweroff when holding down the power button, and we can't change that behavior easily. We can make momentary presses of the power button, or holding it down up to 4 seconds, do anything we want fairly easily though. I propose that both the screen rotation button and the power button simply pop up big fat obvious dialogs that pop down and do nothing if Dialogs aren't the right solution here. you press the button again, but require you to either press and hold the button, or press another button (like the arrow keys) to actually rotate the screen or power the system down. That's pretty indirect; I'd argue the more direct the better. The button has a rotation icon, and when you press it, it should rotate the screen. That will let users rotate the screen absolutely in one shot with the arrow keys without going through all the intermediate rotations. Rotating is extremely expensive because it laboriously repaints the entire screen, requiring the application to do all kinds of memory allocation of giant page sized double buffers. So it should be very hard to do it accidentally, while right now it's very hard not to do it accidentally. This is not a problem with the B3 units and the LX processor, because the LX is (a) faster and (b) can accelerate resizes. It's so damn quick on the LX you'll be literally blown away after seeing it on a B1/B2. Obviously the activity has to redraw; but that should already be as fast as possible. Of course the consequences of accidentally shutting the system down with a mere press of the button are much worse, so the same thing goes tenfold for the power button! Again, slated to be fixed. Kids will naturally go straight
