Re: [Sugar-devel] how to use custom gstreamer elements bundled in activities?
On Sat, Dec 11, 2010 at 01:30:22AM -0500, Erik Blankinship wrote: > Some more research suggests I need to specify a GST_PLUGIN_PATH for my > activity. > http://stackoverflow.com/questions/2120444/gstreamer-plugin-search-path > > I am having a hard time figuring out how to do this in pygst. The bindings > are great, but sometimes obscure. Any pygst experts out there? I guess just setting envar before including any gst related imports should work: import os from sugar.activity.activity import get_bundle_path os.environ['GST_PLUGIN_PATH'] = get_bundle_path() > > Thanks, > Erik > > Additional resources: > http://www.gstreamer.net/data/doc/gstreamer/head/gstreamer/html/GstRegistry.html > http://www.gstreamer.net/data/doc/gstreamer/head/pwg/html/chapter-building-testapp.html > > On Sat, Dec 11, 2010 at 1:05 AM, Erik Blankinship wrote: > > > I have created a gstreamer plugin I want to bundle with an activity. > > > > I looked at one way mp3 support is handled, and it requires a permanent > > addition to /usr/lib/gstreamer > > http://wiki.laptop.org/go/Fluendo_mp3_decoder > > > > I would like to avoid that extra step. > > > > Any suggestions how to reference a bundled gstreamer plugin so it can be > > used in sugar activity gstreamer pipelines? Thanks! > > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] how to use custom gstreamer elements bundled in activities?
Some more research suggests I need to specify a GST_PLUGIN_PATH for my activity. http://stackoverflow.com/questions/2120444/gstreamer-plugin-search-path I am having a hard time figuring out how to do this in pygst. The bindings are great, but sometimes obscure. Any pygst experts out there? Thanks, Erik Additional resources: http://www.gstreamer.net/data/doc/gstreamer/head/gstreamer/html/GstRegistry.html http://www.gstreamer.net/data/doc/gstreamer/head/pwg/html/chapter-building-testapp.html On Sat, Dec 11, 2010 at 1:05 AM, Erik Blankinship wrote: > I have created a gstreamer plugin I want to bundle with an activity. > > I looked at one way mp3 support is handled, and it requires a permanent > addition to /usr/lib/gstreamer > http://wiki.laptop.org/go/Fluendo_mp3_decoder > > I would like to avoid that extra step. > > Any suggestions how to reference a bundled gstreamer plugin so it can be > used in sugar activity gstreamer pipelines? Thanks! > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] how to use custom gstreamer elements bundled in activities?
I have created a gstreamer plugin I want to bundle with an activity. I looked at one way mp3 support is handled, and it requires a permanent addition to /usr/lib/gstreamer http://wiki.laptop.org/go/Fluendo_mp3_decoder I would like to avoid that extra step. Any suggestions how to reference a bundled gstreamer plugin so it can be used in sugar activity gstreamer pipelines? Thanks! ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Messages notification
Hi Frederick,
On 11 Dec 2010, at 04:24, Frederick Grose wrote:
> On Fri, Dec 10, 2010 at 8:39 PM, Gary Martin
> wrote:
> Hi Martin,
>
> On 8 Dec 2010, at 05:11, Martin Abente wrote:
>
> > The design looks great, and I like the fact that it attaches each
> > notification to its real context when there is a visible one (i,e an
> > activity, journal, battery device icon, etc).
> >
> > How would it work with notifications that are not related to an activity or
> > with a visible context?
>
> Notifications not related to an activity or existing visible context would
> pulse and add new icons in the same way that transfer to/from notifications
> are designed. Here's an example showing your schoolserver institutional
> broadcast message example:
>
>
> http://wiki.sugarlabs.org/go/Design_Team/Proposals/Notifications#School_server_messages
>
> Thanks for these mock-ups!
>
> As an aside, but relevant to implementation design, the schoolserver icon
> colors should probably be determined by a characteristic of the schoolserver
> (for consistency among learners or on instances with different learner
> names), much like the access point colors are derived from the SSID.
Absolutely +1 from me:) However, I conciously used the owners colour in this
mockup as it is how the schoolserver icon is currently being coloured (in
Dextrose, for the backup/restore to schoolserver Journal feature; no one else
is using it to my knowledge). The schoolserver icon (with it's unique colours
based on its own identity key) should also appear in the neighbourhood view
allowing registration (rather than the current hack of having register via the
users XO icon palette), and would help provide some visual cue as a
child/teacher moves from one school or network to another, as they would see
the different colour icon and be able to re-register to that new server.
Regards,
--Gary
> --Fred
>
> I am rather worried at the amount of use cases being raised, constant outside
> distractions and notifications are a productivity and deep thought killer.
> Hopefully you're just trying to make sure a design can cover all your
> possible base cases ;-)
>
> {...}
>
> --Gary
>
> > Possible use cases (examples):
> >
> > * XS registration messages.
> > * Automatic updater messages.
> > * Sugar critical errors report.
> > * Institutional broadcast messages.
> > * Anything that simply requires displaying a message.
>
> {...}
>
> ___
> 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] prevent screen rotation in a sugar activity?
On Fri, Dec 10, 2010 at 3:50 PM, Bakhtiar Mikhak wrote: > > On Dec 10, 2010, at 5:14 PM, James Cameron wrote: > > On Fri, Dec 10, 2010 at 04:29:31PM -0500, Erik Blankinship wrote: > > It is sometimes a designer's prerogative to present their work in one > format. > > Numerous examples are available on the iPhone and android markets. > > > It is sometimes a platform designer's perogative to enforce human > interface guidelines and require applications to support certain > behaviours. > > Is it possible to override or be notified of a rotation signal? > > > No, not without taking control of components outside the scope of a > Sugar activity. You're welcome to try that, but the problems that occur > are: > > 0. installation will require root access, which is not available to > some users due to deployment team policy, > > 1. the API will keep changing, instead of remaining relatively static > in the case of the Sugar Activity API, > > 2. there are multiple build versions to test against, > > 3. there is a higher risk of breaking something later. > > > If I am reading the current version of HIG, > http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Sugar_Interface/Input_Systems#Screen_Rotation, > correctly, > it is not a *requirement* for developers to implement a portrait layout > for their activity: > > Screen Rotation > While in Hand-held mode, the laptops support screen rotation; by pressing a > small button on the bezel of the display, the interface will rotate 90 > degrees to provide a portrait layout of the currently active activity. Just > as any activity can implement Hand-held mode, those which can benefit from a > vertical aspect ratio may also implement this feature, and we encourage > developers to take advantage of this functionality. The Read activity serves > as a prime example of the usefulness of such a feature, since a vertical > layout is well suited to displaying a single page from a book. This is just > the type of activity one might want to do in Hand-held mode, and by > providing two orientations a greater number of use cases can be covered. > In the current revisions of the laptops, its important to note that the > buttons for interacting with Hand-held mode are slightly less accessible > when the laptops are held vertically. For this reason, activities that > require heavy or frequent use might not be best suited for this mode. > However, OLPC is working hard on introducing touch-screen technology in the > near future, which will nearly eliminate the dependency on the physical > buttons, expanding the possibilities as every activity can take advantage of > screen rotation. Therefore, even if screen rotation doesn't make sense for > the first version of your activity, please construct your interface in such > a way as to allow future adaptation to this new and potentially useful > functionality. > > I therefore think it is worth considering if the control over if/how one's > activity takes advantage of screen rotation should be exposed through the > Sugar API. > > ___ > Devel mailing list > de...@lists.laptop.org > http://lists.laptop.org/listinfo/devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Messages notification
On Fri, Dec 10, 2010 at 8:39 PM, Gary Martin wrote:
> Hi Martin,
>
> On 8 Dec 2010, at 05:11, Martin Abente wrote:
>
> > The design looks great, and I like the fact that it attaches each
> notification to its real context when there is a visible one (i,e an
> activity, journal, battery device icon, etc).
> >
> > How would it work with notifications that are not related to an activity
> or with a visible context?
>
> Notifications not related to an activity or existing visible context would
> pulse and add new icons in the same way that transfer to/from notifications
> are designed. Here's an example showing your schoolserver institutional
> broadcast message example:
>
>
> http://wiki.sugarlabs.org/go/Design_Team/Proposals/Notifications#School_server_messages
Thanks for these mock-ups!
As an aside, but relevant to implementation design, the schoolserver icon
colors should probably be determined by a characteristic of the schoolserver
(for consistency among learners or on instances with different learner
names), much like the access point colors are derived from the SSID.
--Fred
I am rather worried at the amount of use cases being raised, constant
> outside distractions and notifications are a productivity and deep thought
> killer. Hopefully you're just trying to make sure a design can cover all
> your possible base cases ;-)
{...}
>
> --Gary
>
> > Possible use cases (examples):
> >
> > * XS registration messages.
> > * Automatic updater messages.
> > * Sugar critical errors report.
> > * Institutional broadcast messages.
> > * Anything that simply requires displaying a message.
>
{...}
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Messages notification
Hi Walter, On 7 Dec 2010, at 10:40, Walter Bender wrote: > On Mon, Dec 6, 2010 at 10:45 PM, Gary Martin > wrote: >> Hi Martin, >> >> On 23 Nov 2010, at 17:23, Martin Abente wrote: >> >>> Awesome, let me know whenever you got something to share :) >> >> Just wanted to pass on the wiki page I've been working on. I'd like to >> generate more example mockups covering the devices frame edge (easy), and >> the buddy frame edge (more complicated, though we could use this edge just >> for arrival/departure/buddy-event, but it might be possible to have it cover >> 'bubble chat' as per Eben's previous hopes): >> >>http://wiki.sugarlabs.org/go/Design_Team/Proposals/Notifications >> >> Feedback/thoughts appreciated. >> >> Regards, >> --Gary >> > > I like both approaches, actually. Arrrgh, nooo. I wasn't suggesting both! ;-) > The first, with the badges, closely > associates the notification with its context and the corner history > let's you get an overview. Yes I think keeping the notification close to its actual context is pretty critical. > What if the corner history were instead > added to the bottom of the frame as another system status tool and the > badges were used as per the example. Here's a mockup: http://wiki.sugarlabs.org/go/Design_Team/Proposals/Notifications#Notification_history_as_a_device_icon I guess a deployment that thinks this an important way to view a consolidated list of notifications could include such a device icon in their distro (much like the cpu load happy/sad face), but for me it looses the spacial context with the object that is actual trying to notify you of some event. > (and perhaps we could add a 'send > a notification' submenu to the friends icons on the Frame as well). I'm still thinking on that one... Chat type notifications from friends would seem like the ideal case for a consolidated, time ordered list of chat messages (not mixed in with other notification types), so you could actually have a valid conversation flow with collaborating buddies. If new messages were shown attached to the given buddy icon context, you'd be hard pressed to follow the sequence of a conversation (that UI would only really work for one on one private conversation flow). Regards, --Gary > -walter > >>> On Mon, Nov 22, 2010 at 5:36 PM, Gary C Martin >>> wrote: >>> Hi Martin, >>> >>> Just wanted to give you a heads up that I have a slightly different design >>> coming together for notifications. >>> >>> After further, more detailed, work the frame corner notification history >>> palette idea is not coming together so well. I've switched to mockups that >>> actually badge the existing icons in the frame, and add the notification >>> messages to the end of their existing pop-up palettes. It holds truer (I >>> think) to the original HIG and previous mockups of Eben's intent for >>> notifications. I'll try and get the set of new images uploaded to the wiki >>> later this week for folks to review. >>> >>> Regards, >>> --Gary >>> >>> On 17 Nov 2010, at 19:17, Martin Abente wrote: >>> Change the "want" for "need" and we have: "When there is something they _need_ to know" And that is exactly the same reason why we are already using the Icon notifications and the same reason why we are already using Alert widgets all over sugar (outside activities), and there are still more cases that we don't do because we simply don't have this feature fully implemented yet. That's all i got. Abrazos, :) On Wed, Nov 17, 2010 at 3:27 PM, Martin Langhoff wrote: On Wed, Nov 17, 2010 at 1:10 PM, David Farning wrote: > This patch has a place in Dextrose. Dextrose is looking at the > question, "How can we provide support staff the necessary information > to effectively fix and/or report problems to a higher level of service > and support?" Let's not jump to conclusions. Can this be limited to... when the user _wants_ it? 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 >>> >>> >> >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> > > > > -- > Walter Bender > Sugar Labs > http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Messages notification
Hi Martin, On 8 Dec 2010, at 05:11, Martin Abente wrote: > The design looks great, and I like the fact that it attaches each > notification to its real context when there is a visible one (i,e an > activity, journal, battery device icon, etc). > > How would it work with notifications that are not related to an activity or > with a visible context? Notifications not related to an activity or existing visible context would pulse and add new icons in the same way that transfer to/from notifications are designed. Here's an example showing your schoolserver institutional broadcast message example: http://wiki.sugarlabs.org/go/Design_Team/Proposals/Notifications#School_server_messages I am rather worried at the amount of use cases being raised, constant outside distractions and notifications are a productivity and deep thought killer. Hopefully you're just trying to make sure a design can cover all your possible base cases ;-) I'd actually like to raise a possible 'simple' stepping stone approach: - code is implemented to allow badging of frame icons - existing activity alert code is updated so that when an activity alert strip is raised, it triggers the corner pulse and badges the activities icon (if the given activity is not currently front most). This would allow existing activity alerts to be noticed at any time, switching to the activity with the badge would allow you read the actual text in the already implemented alert strip, and take any action necessary. Additional alerts (say for the Journal) could be used to notify of low storage space, backup failures. Institutional broadcast messages (or any message from your schoolserver), is really a separate feature, much like the transfer to/from work, so could be added at any time. Regards, --Gary > Possible use cases (examples): > > * XS registration messages. > * Automatic updater messages. > * Sugar critical errors report. > * Institutional broadcast messages. > * Anything that simply requires displaying a message. > > > On Tue, Dec 7, 2010 at 12:45 AM, Gary Martin > wrote: > Hi Martin, > > On 23 Nov 2010, at 17:23, Martin Abente wrote: > > > Awesome, let me know whenever you got something to share :) > > Just wanted to pass on the wiki page I've been working on. I'd like to > generate more example mockups covering the devices frame edge (easy), and the > buddy frame edge (more complicated, though we could use this edge just for > arrival/departure/buddy-event, but it might be possible to have it cover > 'bubble chat' as per Eben's previous hopes): > >http://wiki.sugarlabs.org/go/Design_Team/Proposals/Notifications > > Feedback/thoughts appreciated. > > Regards, > --Gary > > > On Mon, Nov 22, 2010 at 5:36 PM, Gary C Martin > > wrote: > > Hi Martin, > > > > Just wanted to give you a heads up that I have a slightly different design > > coming together for notifications. > > > > After further, more detailed, work the frame corner notification history > > palette idea is not coming together so well. I've switched to mockups that > > actually badge the existing icons in the frame, and add the notification > > messages to the end of their existing pop-up palettes. It holds truer (I > > think) to the original HIG and previous mockups of Eben's intent for > > notifications. I'll try and get the set of new images uploaded to the wiki > > later this week for folks to review. > > > > Regards, > > --Gary > > > > On 17 Nov 2010, at 19:17, Martin Abente wrote: > > > > > Change the "want" for "need" and we have: > > > > > > "When there is something they _need_ to know" > > > > > > And that is exactly the same reason why we are already using the Icon > > > notifications and the same reason why we are already using Alert widgets > > > all over sugar (outside activities), and there are still more cases that > > > we don't do because we simply don't have this feature fully implemented > > > yet. > > > > > > That's all i got. > > > > > > Abrazos, :) > > > > > > On Wed, Nov 17, 2010 at 3:27 PM, Martin Langhoff > > > wrote: > > > On Wed, Nov 17, 2010 at 1:10 PM, David Farning wrote: > > > > This patch has a place in Dextrose. Dextrose is looking at the > > > > question, "How can we provide support staff the necessary information > > > > to effectively fix and/or report problems to a higher level of service > > > > and support?" > > > > > > Let's not jump to conclusions. > > > > > > Can this be limited to... when the user _wants_ it? > > > > > > > > > > > > > > > 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] prevent screen rotation in a sugar activity?
Erik,
Here is how you can be notified when the screen is rotated:
First, listen for the "expose" event in PyGTK:
self.connect("expose_event", self.area_expose_cb)
Here is the method that gets invoked:
def area_expose_cb(self, area, event):
screen_width = gtk.gdk.screen_width()
screen_height = gtk.gdk.screen_height()
if self.saved_screen_width != screen_width and
self.saved_screen_width != 0:
self.show_page(self.page)
self.saved_screen_width = screen_width
return False
Now if you write a PyGTK Activity the layouts usually make this
unnecessary. In this case I was displaying an image which needed to
be resized to make the best use of the new screen dimensions, so I
invoke the method that shows the image when the dimensions change.
Every new Activity developer seems to want to do something that Sugar
won't allow. In time you'll come to terms with what Sugar is and make
your Activities accordingly.
Your iPhone and Android examples are not good. If I had paid money
for an app for either platform and it refused to rotate when I rotated
my phone I would not think highly of that app. Supporting screen
rotation in a PyGTK Activity is trivial. With PyGame it's more work,
but it's work you should be doing anyway. With Sugar on a Stick your
Activity will need to support a variety of screen dimensions. A good
example of the wrong thing to do is the commercial game "Super Vampire
Ninja Zero". It ONLY works on the XO screen dimensions, without
rotation. Don't be that guy!
James Simmons
On Fri, Dec 10, 2010 at 4:14 PM, James Cameron wrote:
> On Fri, Dec 10, 2010 at 04:29:31PM -0500, Erik Blankinship wrote:
>> It is sometimes a designer's prerogative to present their work in one format.
>> Numerous examples are available on the iPhone and android markets.
>
> It is sometimes a platform designer's perogative to enforce human
> interface guidelines and require applications to support certain
> behaviours.
>
>> Is it possible to override or be notified of a rotation signal?
>
> No, not without taking control of components outside the scope of a
> Sugar activity. You're welcome to try that, but the problems that occur
> are:
>
> 0. installation will require root access, which is not available to
> some users due to deployment team policy,
>
> 1. the API will keep changing, instead of remaining relatively static
> in the case of the Sugar Activity API,
>
> 2. there are multiple build versions to test against,
>
> 3. there is a higher risk of breaking something later.
>
> --
> James Cameron
> http://quozl.linux.org.au/
> ___
> 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
[Sugar-devel] DebXO 0.6 release
Hi, After waay to long of a delay, I just tagged and built DebXO 0.6. In some ways, it's very polished (I've actually tested all of the desktops myself), in other ways it has a number of regressions (due to Debian updates breaking things, switching to an almost-stock Linus kernel, etc). Either way, I wanted to get it out because people keep asking about it, and dropping jffs2 leads to such a massive improvement. DebXO is a version of Debian (testing) that is customized for the XO-1 hardware. The 0.6 release adds initial support for the XO-1.5 hardware; however, XO-1.5 is not officially supported. I'll update the wiki with instructions for XO-1.5, for the early adopters. The release can be found here: http://lunge.mit.edu/~dilinger/debxo-0.6/images/ The official wiki is: http://wiki.laptop.org/go/DebXO CHANGES: - Update distribution to Debian Squeeze. All packages and desktops have been upgraded. This is pretty major; for example, Sugar is now at 0.88, and Gnome at 2.30(ish). - Kernel update. Switch from the olpc-2.6 tree to Linus's linux-2.6 tree (based upon 2.6.37-rc4+). A few pending patches from -next and -mm have been included, but other than that... it's stock. The config closely matches the Debian stock kernel config; at a future date, we'll just switch to a standard Debian 686 kernel. - Switch the nand images from using JFFS2 to UBIFS. This makes an amazing difference in terms of usability. Over time, JFFS2 filesystems get slower as they fragment, while UBIFS doesn't appear to. - Initial XO-1.5 support. It's still rough around the edges, but it's functional (currently xorg.conf and /boot/olpc.fth must be edited). - Switch from autox to nodm for LXDE and XFCE desktops. LXDE usability has been vastly improved (for example, wicd is installed and configured automatically; LXDE can now get online). Webkit-based browsers are used - less ram thrashing throughout. - KDE image has been dropped (at least for now). KDE4 took at least 10 minutes to start up and then crashed, so.. I'll deal with it another time. Patches to make it work accepted! - Awesome image has been dropped. I'd intended to replace this with XMonad (as that's what I actually use), but currently that requires some tweaking and needs to drop about 300MB of devel libs. So for now, it's just dropped. - Base images have been dropped. The 0.5 base image was broken, and, well... I don't see much demand for it. - Hal is no longer used (except for some legacy stuff in the XFCE images). Key bindings are pulled from DMI and loaded by udev (note: upgrade your version of OFW if hitting the 'fn' key results in lots of '='s. Alternatively, add "/lib/udev/keymap /dev/input/event0 olpc-xo" to your /etc/rc.local to auto-load the proper keymap). Lots of misc other changes can be seen at: http://lunge.mit.edu/cgi-bin/gitweb.cgi?p=xodist;a=summary KNOWN BUGS: - Power management is currently not enabled. It's on the roadmap. - KDE and Awesome images are disabled (for DebXO 0.6). - The camera driver is disabled due to a crash in the kernel. - Upon first bootup, the LXDE and XFCE desktops display a wicd error. It only happens on the first boot, so I think it's related to copying files around. Just restart and it'll go away. - Also upon first bootup, if you reboot XFCE via the menu (logout->reboot), it appears to kill the panel prior to saving the startup applications. This means that when XFCE boots up the second time, there's no panel or desktop. I believe that this is an XFCE bug; after the first boot, using the menu to reboot doesn't break anything. So, just open up a terminal and "sudo reboot" the first time, if using XFCE. - Nodm doesn't currently set ~/.Xauthority; see http://bugs.debian.org/605633 . This means gksu (and gksudo) are broken. For now, just open up a terminal and call (for example) "sudo synaptic". - The volume/brightness keys are mapped to function keys. It's unclear how best to handle this, as it is useful to have f11, for example. Will figure something out later. - Due to a switch from Hal to udev and upower, battery status reporting is broken. This is fixed with a pending kernel update, but it's in the process of being pushed upstream (and therefore will be fixed in 0.7). INSTALLATION ONTO NAND FLASH: To install onto the XO's NAND flash, download the jffs2/$DESKTOP.dat and jffs2/$DESKTOP.img to a USB or SD stick (where $DESKTOP is one of the various desktops - gnome, lxde, xfce, or sugar). Boot into OFW (make sure your XO is unlocked!), and run update-nand disk:\$DESKTOP.img or update-nand sd:\$DESKTOP.img (depending upon whether you downloaded to an SD or USB disk). If update-nand spits out any errors, make sure you're running an appropriately up-to-date version of OFW. The q2d* series do not support update-nand, and versions q2e18 and q2e19 are k
Re: [Sugar-devel] prevent screen rotation in a sugar activity?
On Fri, Dec 10, 2010 at 05:50:54PM -0500, Bakhtiar Mikhak wrote: > If I am reading the current version of HIG correctly, it is not a > requirement for developers to implement a portrait layout for their > activity: > > Screen Rotation > > While in Hand-held mode, the laptops support screen rotation; by > pressing a small button on the bezel of the display, the interface > will rotate 90 degrees to provide a portrait layout of the > currently active activity. Just as any activity can implement > Hand-held mode, those which can benefit from a vertical aspect > ratio may also implement this feature, and we encourage developers > to take advantage of this functionality. Agreed, it is not a requirement for the activity to implement portrait layout. When it is not implemented, part of the activity would be invisible after rotation. The learner will rapidly find the activity does not work well when rotated, and will avoid rotating. > I therefore think it is worth considering if the control over if/how > one's activity takes advantage of screen rotation should be exposed > through the Sugar API. Sounds good, please propose a design and patch. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] prevent screen rotation in a sugar activity?
On Fri, Dec 10, 2010 at 04:29:31PM -0500, Erik Blankinship wrote: > It is sometimes a designer's prerogative to present their work in one format. > > Numerous examples are available on the iPhone and android markets. It is sometimes a platform designer's perogative to enforce human interface guidelines and require applications to support certain behaviours. > Is it possible to override or be notified of a rotation signal? No, not without taking control of components outside the scope of a Sugar activity. You're welcome to try that, but the problems that occur are: 0. installation will require root access, which is not available to some users due to deployment team policy, 1. the API will keep changing, instead of remaining relatively static in the case of the Sugar Activity API, 2. there are multiple build versions to test against, 3. there is a higher risk of breaking something later. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] prevent screen rotation in a sugar activity?
Thank you for these suggestions. It is sometimes a designer's prerogative to present their work in one format. Numerous examples are available on the iPhone and android markets. Is it possible to override or be notified of a rotation signal? Or is the answer to really remap the display and input into my software, which seems unfortunately complex. "*The following software has been modified from its original version. It has been formatted to fit this screen."* On Thu, Dec 9, 2010 at 7:45 PM, James Simmons wrote: > Erik, > > If you use PyGTK to develop your Activity there are Layouts which will > arrange your controls on the screen to make the best use of the > available space. In this way the app is still usable with the screen > rotated. In View Slides I detect when the screen dimensions change > and resize the image I'm displaying. You might look at the code for > View Slides to see how I do that (or look at Read SD Comics which does > the same thing but is simpler). > > Screen rotation is a useful feature of the XO. Your Activity should > be able to deal with it gracefully. > > James Simmons > > > On Thu, Dec 9, 2010 at 8:51 AM, Erik Blankinship > wrote: > > Is there a way to prevent a sugar activity from being rotated when there > is > > a screen rotation event on an olpc-xo or other hardware which support > screen > > rotation? > > ___ > > 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
[Sugar-devel] 10.1.3 Testing page available
Hi, we have a page [1] available where you are invited to gather your 10.1.3 testing results. We hope to find out more quickly possibly introduced regressions and get a sense of what works well. There are some tests where details about the hardware you used are of interest to us (e.g. Internet connection, USB2VGA). And of course, we hope it is fun for you to see a page like this grow! Each 10.1.3 Feature has a section where you can comment. There are as well some more generic tests like connecting to the Internet and backwards compatibility tests. The last section has a list of bugs that we think are important to test. The current build available as of today is os358. All of the tests in the page works as well with os357 if you have already downloaded that one. The difference between os357 and os358 is *only* a new WikipediaEN, WikipediaES and a new Write and Paint activity. Looking forward to the results, Simon [1] http://wiki.laptop.org/go/10.1.3/Testing [2] http://build.laptop.org/10.1.3/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
