UDE - environment Alpha.
I've been working on this a while. I've got something for people to look at. It's Alpha with many broken parts, but there's enough to get the idea and, cross fingers, encourage others to contribute. http://screamingduck.com/ude/ It's an environment aiming to provide an alternative to Sugar or Gnome, It installs into the user's home directory so an XO user can install it without changing anything at the system level. You can however do a few system level changes in order to have most of the environment based on SD-card. To install to a permanently mounted SD card see http://screamingduck.com/ude/?Article=56&Show=ABCE I have worked hard to keep things lightweight enough to run on an XO-1. I have a nice four workspace environment, with desklets, ROX-Filer, and a number of other goodies running while being comparatively lightweight. Here's a ScreenShot showing the just booted memory state. http://screamingduck.fileburst.com/screenshots/ude/justbooted.png (If you run this, Click on the doodle icon centre-bottom it's cool :-) also note the launch time, That's what the XO can do ) While the system is a windowed environment, pressing the frame key toggles the current window to full-screen undecorated. The workareas are related to modes of thought rather than Sugar's zoom levels. An explanation and pretty pictures can be seen at http://screamingduck.com/ude/?ScreenShots [extra bits to look at, not all currently working in this release] Much of this is based upon things collected from the Free software cornucopia. Some parts I had to make myself, I failed to find a desktop widget system light enough for the XO, so wrote my own. Here's a clip showing some of the Unix philosophy behind the widgets http://www.youtube.com/watch?v=0QJ9fTYZuwk&fmt=22 Because the XO screen has such a high resolution, moving fullscreen graphics around can be quite slow. To mitigate this for programs needing animation more than resolution I have utilised an rgb565 video overlay. The Doodle program uses this technique. Here is a clip showing an animation demo on the XO using this method http://www.youtube.com/watch?v=KD95e9G1SiQ In addition to this I have created a simple little graphics library (called Whio) to enable full-screen animated applications to be put together with very little effort. This was inspired by the LÖVE project, I might have just used LÖVE, but for it's requirement of OpenGL. Instead this uses the Overlay technique mentioned above, this allows the programmer to ask for whatever resolution they want (up to 1024x768) and it will run fullscreen or scaled to a window of any size. Working in conjunction with the library is a easy project creation system so that users can create project bundles easily and consider them to be a single working unit until they are ready to look inside the bundle to deal with the finer details. This is a core principle, of UDE, easy to get started, but the finer control is there for those who go looking for it. This clip shows several components mentioned above. In it, I create two new projects by drag and drop. One is a Standard GUI style app, the other is a fullscreen animated app. http://www.youtube.com/watch?v=AMtleAzJ3AE&fmt=22 The IDE is a bit too complex for a beginner programmer, mostly because it looks intimidating. I hope to make something simpler for people to begin with, and give them the choice to switch to MSEIDE (the one shown in the video) later. (Actually, now that I've had to type it all up, it seems like quite a bit, maybe don't spend all my time playing QuakeLive) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar window managing UI
Indeed, it would probably also be a good addition! Best regards, Tiago On Wed, Jan 6, 2010 at 6:12 PM, Sascha Silbe wrote: > On Wed, Jan 06, 2010 at 06:07:56PM +, Tiago Marques wrote: > >> The very long time is hard to get rid of, at least on the XO 1. As far >> as I can tell, the biggest problem is that ALT-TAB cycles through the >> apps by the order they were open and not in the order by which they >> were last accessed(which is non standard behaviour nowadays) and which >> causes problems especially if you're swapping, as it will frequently >> cycle through an unused, disk swapped app. > > Which gets us back to the keyboard shortcuts for individual windows > (activity instances). :) > > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQEcBAEBAgAGBQJLRNKTAAoJELpz82VMF3DaN2IH/2nieTsPSl2LteWQIjiBY5JH > tvqnzFj0F9uuwZPtb9YKYInpkjdIUCzWzxUWrMwRp/UZu9pebTUEsP5X8I7YtELN > PYnKIqtpTShbwWQuepjbD0oBwtX7a0JuYAx26/VBminyfPrsBcmYL9knO+mGyB07 > PPwDXiSXQceiG1GNaxCNk8zCL6o1cu9Ugr6/dqml0efQNt9t4qQxE5eEsi7rbTBO > JI2ISbdC5HYBPMM21hAviAVhLbPgwyA3u5m4pRFBnGH0TqfaUZOS29Kx9X3o/zk/ > bJHicebeqX+VxCP/Q9DBRb35PAN97EzexG7TZZAJyT8NBevIpP8YKWrjGu4aR7Q= > =QdGG > -END PGP SIGNATURE- > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New XO-1.5 10.2.0 build 105
http://wiki.laptop.org/go/F11_for_1.5 http://build.laptop.org/10.2.0/os105 Compressed image size: 702.50mb (+0.25mb since build 104) Description of changes in this build: * workaround for wireless resume crash from dsd (#9836) Package changes since build 104: -gnome-keyring-2.26.3-1.fc11.i586 +gnome-keyring-2.26.3-2.fc11.i586 -kernel-2.6.31_xo1.5-20100104.2310.1.olpc.c0eb4f9.i586 +kernel-2.6.31_xo1.5-20100106.1110.1.olpc.76c32d5.i586 -kernel-firmware-2.6.31_xo1.5-20100104.2310.1.olpc.c0eb4f9.i586 +kernel-firmware-2.6.31_xo1.5-20100106.1110.1.olpc.76c32d5.i586 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar window managing UI
On Wed, Jan 06, 2010 at 06:07:56PM +, Tiago Marques wrote: The very long time is hard to get rid of, at least on the XO 1. As far as I can tell, the biggest problem is that ALT-TAB cycles through the apps by the order they were open and not in the order by which they were last accessed(which is non standard behaviour nowadays) and which causes problems especially if you're swapping, as it will frequently cycle through an unused, disk swapped app. Which gets us back to the keyboard shortcuts for individual windows (activity instances). :) CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar window managing UI
On Wed, Jan 06, 2010 at 10:12:44AM -0600, Mikus Grinbergs wrote: For me, the Alt+Tab switch time on the XO is around one second (or less) to the next window. It takes several seconds for me, especially if Browse is involved. I'm running sugar-jhbuild (=> debug logging) on an abysmally slow SD card (or almost-as-slow NFS-root-over-USB-ethernet-adapter), though. Becomes burdensome only when there are *many* windows to cycle through - and it is rare that I have many open. On my desktop I often have some 50 windows spread over several workspaces each containing about a dozen of those windows inside a frame (where I can switch between them using keyboard or mouse). On the XO-1, I wouldn't even think of that, of course. With the memory usage of most activities more than a handful of them is simply impossible. The developers suggested, when there are many windows open, not using Alt+Tab but instead clicking __in the Frame__ on the icon of the specific window to be switched to. I'm sometimes doing that, but since I loathe pointer devices and the first-generation XO-1 touchpad is more often misbehaving than not, this is only a last resort. With the availability nowadays of 'Tabs' in Terminal (and in browsers), I'm switching much more often *within* an application than *between* applications. In Terminal, Ctl+Shift+Horizontal_Arrow switches quickly. Good to know about that shortcut (can we expose it somewhere, please?). Unfortunately Terminal is broken for me (it crashes somewhere inside vte as soon as it's asked to save its state). CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar window managing UI
The very long time is hard to get rid of, at least on the XO 1. As far as I can tell, the biggest problem is that ALT-TAB cycles through the apps by the order they were open and not in the order by which they were last accessed(which is non standard behaviour nowadays) and which causes problems especially if you're swapping, as it will frequently cycle through an unused, disk swapped app. Best regards, Tiago On Wed, Jan 6, 2010 at 4:12 PM, Mikus Grinbergs wrote: >> What I hate about the Sugar window managing UI is: >> a) _very_ long switching time >> b) there's no way to switch to a specific window (=activity instance), >> I need to cycle through all of them with Alt+Tab > > For me, the Alt+Tab switch time on the XO is around one second (or less) > to the next window. Becomes burdensome only when there are *many* > windows to cycle through - and it is rare that I have many open. > > There was a long discussion about this way back when (I don't have a > cite). [For each switch, the OLPC developers wanted indication in the > Neighborhood View of the *other* users as to the window (i.e., Activity) > in which *this* user now participated.] The developers suggested, when > there are many windows open, not using Alt+Tab but instead clicking __in > the Frame__ on the icon of the specific window to be switched to. > > With the availability nowadays of 'Tabs' in Terminal (and in browsers), > I'm switching much more often *within* an application than *between* > applications. In Terminal, Ctl+Shift+Horizontal_Arrow switches quickly. > > mikus > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar window managing UI
> What I hate about the Sugar window managing UI is: > a) _very_ long switching time > b) there's no way to switch to a specific window (=activity instance), > I need to cycle through all of them with Alt+Tab For me, the Alt+Tab switch time on the XO is around one second (or less) to the next window. Becomes burdensome only when there are *many* windows to cycle through - and it is rare that I have many open. There was a long discussion about this way back when (I don't have a cite). [For each switch, the OLPC developers wanted indication in the Neighborhood View of the *other* users as to the window (i.e., Activity) in which *this* user now participated.] The developers suggested, when there are many windows open, not using Alt+Tab but instead clicking __in the Frame__ on the icon of the specific window to be switched to. With the availability nowadays of 'Tabs' in Terminal (and in browsers), I'm switching much more often *within* an application than *between* applications. In Terminal, Ctl+Shift+Horizontal_Arrow switches quickly. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New release of F11 for the XO-1 - Build11
john wrote: > > Keyboard and mouse will not wakeup from sleep. Can be fixed by disabling > > power management in Sugar. > > Is there any reason for cutting release after release that don't work > unless end users disable power management (sometimes twice!)? to be clear, the releases in question are being built by a volunteer, using source bits available at the time. these are not OLPC releases, and we're _very_ happy someone is doing this to keep the ball rolling. i'm sure steve had reasons to put out this build 11. unfortunately it came on the same day that i (hopefully) fixed the bug referred to above, and so apparently doesn't include the fix. paul > > Surely if you can't fix the bugs, you could at least ship the release > with power management disabled by default, so it works out of the box. > Or, one step up from that, have it figure out which hardware it can > reliably suspend on, and only have it enable suspend by default on > that hardware. > > John > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New release of F11 for the XO-1 - Build11
On Tue, 2010-01-05 at 22:43 -0800, John Gilmore wrote: > > Keyboard and mouse will not wakeup from sleep. Can be fixed by disabling > > power management in Sugar. > > Is there any reason for cutting release after release that don't work > unless end users disable power management (sometimes twice!)? > > Surely if you can't fix the bugs, you could at least ship the release > with power management disabled by default, so it works out of the box. > Or, one step up from that, have it figure out which hardware it can > reliably suspend on, and only have it enable suspend by default on > that hardware. According to trac this (regression) has been fixed: http://dev.laptop.org/ticket/9779 Raúl ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New release of F11 for the XO-1 - Build11
On Wed, Jan 6, 2010 at 7:43 AM, John Gilmore wrote: >> Keyboard and mouse will not wakeup from sleep. Can be fixed by disabling >> power management in Sugar. > > Is there any reason for cutting release after release that don't work > unless end users disable power management (sometimes twice!)? Call them development snapshots rather than releases ;-) 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar window managing UI (was: Re: Android, OLPC, and native hosting)
On Wed, 2010-01-06 at 11:49 +0100, Sascha Silbe wrote: > a) is harder as every window switch currently involves saving current > state to the DS (which resides on an abysmally slow SD card in my case), > usually done synchronously. It also generates log messages, right? In which case, a fix for http://dev.laptop.org/ticket/9924 would help significantly. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Sugar window managing UI (was: Re: Android, OLPC, and native hosting)
On Tue, Jan 05, 2010 at 06:18:47PM -0500, C. Scott Ananian wrote: I think there's room for solid innovation here, especially since the window manager of sugar was *my* personal roadblock to productive on-XO activity development. Interesting. What exactly about the window manager crippled your productivity? I myself am using full-screen workspaces (using ion3) on my desktop (with 24" TFT attached to it) most of the time. What I hate about the Sugar window managing UI is: a) _very_ long switching time b) there's no way to switch to a specific window (=activity instance), I need to cycle through all of them with Alt+Tab/Alt+Shift+Tab (the latter being somewhat difficult to type on the XO-1). b) is probably easy enough to fix (just add some key bindings to metacity). a) is harder as every window switch currently involves saving current state to the DS (which resides on an abysmally slow SD card in my case), usually done synchronously. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
