Re: [Sugar-devel] How to get sugar config values without a console?

[pgf]

martin wrote:
 > I'm working on olpc-update-query, a script that runs without a tty
 > (from NM hooks and cron) and needs to query Sugar configuration stuff.
 > To make things more complicated, it runs as root :-/
 > 
 > It's a good thing that we have sugar-control-panel, but at least on
 > 0.82 it doesn't work unless you're in Terminal. Strangely enough, it
 > tries to load gtk.

if you're root, use the force:

 #!/bin/sh

 get_x_credentials()
 {
 # fetch the local X server's XAUTHORITY variable
 eval "$( xargs -n 1 -0 < /proc/$(pidof X)/environ | grep '^XAUTHORITY=')"
 export XAUTHORITY
 export DISPLAY=:0
 }

 test "$XAUTHORITY" || get_x_credentials

 sugar-control-panel -blah



=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sound levels and pulseaudio fallout

[pgf]

martin wrote:
 > (written as part of the brussels test session)
 > 
 > One thing consistent across the machines we're testing with Soas is
 > that many (most?) of them get very low sound levels. This is an issue
 > with Fedora and Pulseaudio.
 > 
 > The fedora devel list is aflame with discussion about this, and it
 > appears that -- beyond the flaming -- the problem is real, and not
 > easy to solve (meaning it won't be solved in F11). There's an
 > excellent article on the topic @ http://lwn.net/Articles/330684/
 > 
 > It looks like Fedora (for this release) will recommend people to use
 > alsamixer (and a revived oldstyle gnome-mixer) as a workaround. I'm
 > not sure if there's a scripted way to get the "other" channels pumped
 > up to their max levels properly -- and if you do it blindly, it seems
 > that you might overshoot the mark and saturate.
 > 
 > Thought I'd flag it as it's quite likely to hit many Soas users. (On
 > known hw such as the XO it's easier to rig it).

low-end hardware like the XO has no business running pulse.  last
i looked, simply playing an uncompressed audio stream
(admittedly, it was probably sourced remotely, but that's not
uncommon) caused pulse to consume about 10% of a 1.6Ghz atom. 

now, it's somewhat possible that my system was misconfigured --
perhaps someone should double check me on this.

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] disabling "tap to click"

[pgf]

roshan wrote:
 > yes I have those current XOs with standard touchpad and I'm using os767.

in that case you're in somewhat uncharted territory.  the
tap_time parameter mentioned in in the link you gave below is
documented to only work with absolute touchpads, so i doubt it
applies.

there may be some special synaptics support you can try (bobby
mentioned gsynaptics, for instance, which i've never used). 
please let us know what you discover.

paul

 > 
 > On Sun, May 17, 2009 at 8:42 PM, Bobby Powers  wrote:
 > 
 > > On Sun, May 17, 2009 at 9:04 AM, Tomeu Vizoso  wrote:
 > > > On Sun, May 17, 2009 at 10:01, roshan karki  wrote:
 > > >> Hello,
 > > >>
 > > >> How can I disable "tap to click". I tried this
 > > >> http://lists.laptop.org/pipermail/bugs/2008-June/079845.html but it
 > > doesn't
 > > >> work.
 > > >
 > > > Hi Roshan,
 > > >
 > > > can you be more specific about which hardware and version of sugar are
 > > > you using? As far as I know, OLPC has never released a version with
 > > > tap-to-click enabled.
 > >
 > > I think the current XOs coming off the line have a standard touchpad
 > > (as opposed to the dual-use touchpad/tablet), which has tap for click
 > > capabilities.  You might be able to install gsynaptics.
 > >
 > > Bobby
 > >
 > part 2 text/plain 153
 > ___
 > Sugar-devel mailing list
 > Sugar-devel@lists.sugarlabs.org
 > http://lists.sugarlabs.org/listinfo/sugar-devel

=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] [PATCH] add clock frame device

[pgf]

is the choice of an analog clockface feasible?  it's not like
analog watches have gone away, and i'd think that on a learning
platform, especially, that it would be a good option.

paul

p.s.  translation:  "are we sure it's a bikeshed we should be
building?"  :-)

eben wrote:
 > 
 > 1. I think that we need to show the leading 0 when the hour is a one
 > digit number, eg. 08:07. Otherwise everything in the Frame is going to
 > shift depending on the time.
 > 
 > 2. I find the radio buttons a little odd. I wonder if we could have a
 > single menu item that either a) reads "Use 24 hour clock" and uses a
 > checkmark to show its state or b) toggles between "Use 24 hour clock"
 > and "Use 12 hour clock" when clicked.
 > 
 > 3. We could expose some more useful info in the palette, both primary
 > and secondary. The primary palette, for instance, could read:
 > 
 > My Clock
 > Friday, May 8, 2009
 > 
 > I'd put the date label in the secondary string, so we can retain the
 > standard practice of listing the device name in the primary. Including
 > the day of the week would be nice, and displaying the date in a human
 > friendly manner will make it feel less cold & "computery". I also
 > think (this is a future feature suggestion, and needn't be there in a
 > first pass) that the secondary palette should have a nice little
 > inline calendar as well.
 > 
 > 4. This is another future suggestion: we've talked in the past about
 > having an option on various devices which jumps directly to the
 > corresponding section of settings. This device should have a "Show
 > Date & TIme Settings" option when we add that capability.
 > 
 > 5. Finally, I'd like to see if it's at all readable if we limit the
 > clock to a single unit like the rest of the devices icons.
 > 
 > I'll try to make some mockups of all of these thoughts before
 > tomorrow's design meeting. Let me know your thoughts on the
 > suggestions.
 > 
 > Eben
 > 
 > 
 > 
 > On Fri, May 8, 2009 at 7:51 PM, Martin Dengler  
 > wrote:
 > > [ccing sugar-devel as well]
 > >
 > > On Sat, May 09, 2009 at 09:18:02AM +1000, fors...@ozonline.com.au wrote:
 > >> > The below patch adds a clock device to the frame:
 > >> Thanks Martin, I have wanted a clock for a long time.
 > >>
 > >> Can we please have an idiots guide for installation?
 > >
 > > Unfortunately, you can't yet in any released version of Sugar.  The
 > > purpose of my mail was not to give anyone besides a developer code
 > > they could actually use (sorry for the disapointment - I should have
 > > pointed this out very clearly).  The purpose was both to solicit
 > > another round of feedback on the design/behavior, and also to
 > > demonstrate that I had actually written some code that did it (note I
 > > do not say "the best code" nor "the code anyone believes should be
 > > released").
 > >
 > > If you have a moment to suggest any improvements you can think of that
 > > would be most helpful.  I can't guarantee to implement them all but I
 > > (and the Sugar world) am listening seriously.  The links again are:
 > >
 > > 
 > http://www.martindengler.com/tmp/screenshot_clock_device_frame-06_a6_a689bf1e-3f
 > 34-4da3-afed-aa910ab4f677.png
 > > 
 > http://www.martindengler.com/tmp/screenshot_clock_device_frame-07_84_841da15d-9b
 > d7-4fe4-aada-8e8ab723f806.png
 > > 
 > http://www.martindengler.com/tmp/screenshot_clock_device_frame-08_4b_4ba1059e-4d
 > b9-4f22-8661-7916f6a167f8.png
 > >
 > > However, if you happen to be running SoaS, you can run the clock
 > > "as-is".  Start the Terminal activity and execute (cut & paste) these
 > > commands:
 > >
 > > su -
 > > cd /usr/share/sugar/extensions/deviceicon
 > > wget http://www.martindengler.com/tmp/clock.py
 > >
 > > ...and then restart Sugar by pressing Control-Alt-Erase at the same
 > > time.
 > >
 > > If there's enough interest someone (maybe I) may backport the clock to
 > > the currently-released-but-very-old-in-developer-terms Sugar software.
 > >
 > > You may also be interested in my prior clock design, which I did
 > > backport to the latest released OLPC build:
 > > 
 > http://wiki.laptop.org/go/User:MartinDengler#Build_767_.2F_801_.28current_stable
 > .29
 > >
 > > Martin
 > >
 > > ___
 > > IAEP -- It's An Education Project (not a laptop project!)
 > > i...@lists.sugarlabs.org
 > > http://lists.sugarlabs.org/listinfo/iaep
 > >
 > ___
 > Sugar-devel mailing list
 > Sugar-devel@lists.sugarlabs.org
 > http://lists.sugarlabs.org/listinfo/sugar-devel

=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar 0.84-on-a-XO

[pgf]

tomeu wrote:
 > On Fri, May 8, 2009 at 14:03, Martin Dengler  
 > wrote:
 > >
 > >> I was very heartened to hear on IRC two days ago that OLPC have a
 > >> kernel hacker (dsaxena) starting in June (to work on Gen 1.5), and
 > >> that one of the first thing on the todo list was to get the OLPC
 > >> patches applying to the linus kernel.
 > 
 > This has just made me happy today. How much can we rely on this
 > happening? Any plans regarding mesh support in NM?

i've not heard of any NM plans from OLPC.  as for "relying" on
the kernel patches getting upstream, i can't speak for deepak, or
OLPC, or cjb, but as usual, i'd say that being ready and eager to
test, package, etc in a very timely fashion would help a lot.  i
don't believe that getting these patches upstream is a primary
goal (for OLPC) -- my feeling is that it's just a necessary step
that's been nagging at the project, and the more quickly we can
get past it, the better.

(btw, i'll be back at olpc, too, for a couple of months, helping
out with various pieces of 1.5 work:  principally with the EC,
but hopefully with other work as well.)

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] add clock to frame

[pgf]

jameson wrote:
 > Well, if the frame always auto-hid after 10 seconds, and the delay for
 > idle-suspend was 15 seconds, then it would work. I personally believe that
 > the frame should be hidden more agressively - whenever there's a user action
 > that doesn't address it, and after a longish timeout around 10 seconds. In
 > my experience with kids, hitting the frame key and then trying to interact
 > with the activity and being unable to is one of the more common hangups.
 > 
 > (I'm afraid I don't understand the latest on suspend, but it's my
 > understanding that there are some kind of "micro-suspend" periods which are
 > separate from longer-term "idle suspend".)

that's the plan of record, but there's no current implementation.

(and currently the idle suspend timeout is much longer than 15 seconds --
more like 1 or 2 minutes.)

paul

 > 
 > Jameson
 > 
 > 2009/5/3 
 > 
 > > sascha wrote:
 > >  > On Sat, May 02, 2009 at 05:39:21PM +0100, Martin Dengler wrote:
 > >  >
 > >  > [Clock behaviour in suspend]
 > >  > > But I take your point...the answer is: no, it's not easy (with my
 > >  > > simple patch).  I'm not sure what the behavior should be (hide on
 > >  > > idle?!, come out of suspend once a minute?!), really.
 > >  > With the XO going into suspend automatically, it should at least
 > >  > indicate that the clock has stopped as well (and no, the pulsing power
 > >  > LED is not enough). Showing an old time is _much_ worse than not showing
 > >  > it at all.
 > >
 > > given martin's point about the battery level, wireless strength,
 > > etc, all becoming stale as well, perhaps the best fix would be to
 > > always hide the frame during idle suspend.  as far as i know,
 > > however, there's currently no mechanism for apps to learn that
 > > idle suspend is imminent.
 > >
 > > paul
 > > =-
 > >  paul fox, p...@laptop.org
 > > ___
 > > Sugar-devel mailing list
 > > Sugar-devel@lists.sugarlabs.org
 > > http://lists.sugarlabs.org/listinfo/sugar-devel
 > >

=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] add clock to frame

[pgf]

sascha wrote:
 > On Sat, May 02, 2009 at 05:39:21PM +0100, Martin Dengler wrote:
 > 
 > [Clock behaviour in suspend]
 > > But I take your point...the answer is: no, it's not easy (with my
 > > simple patch).  I'm not sure what the behavior should be (hide on
 > > idle?!, come out of suspend once a minute?!), really.
 > With the XO going into suspend automatically, it should at least 
 > indicate that the clock has stopped as well (and no, the pulsing power 
 > LED is not enough). Showing an old time is _much_ worse than not showing 
 > it at all.

given martin's point about the battery level, wireless strength,
etc, all becoming stale as well, perhaps the best fix would be to
always hide the frame during idle suspend.  as far as i know,
however, there's currently no mechanism for apps to learn that
idle suspend is imminent.

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] add clock to frame

[pgf]

martin wrote:
 > On Sat, May 02, 2009 at 10:28:06AM +0200, Tomeu Vizoso wrote:
 > > Hi Martin,
 > > 
 > > I was hoping the frame clock could be implemented as a device icon
 > > extension, so people could add it, remove it and customize it more
 > > easily. Why is it inside the shell instead?
 > 
 > The code (clock.py) is in fact a device icon, and if you drop it in
 > /usr/share/sugar/extensions/deviceicon it'll Just Work.
 > 
 > It's in the shell because it's in the upper-right corner of the frame,
 > where I found it looks a lot better:
 > 
 > http://www.xades.com/proj/clock_frame_767_screenshot.png

sounds like there is, but to be sure:  it's easy for people to
remove or disable if they don't like having a stopped clock on
their screen during idle suspend on an XO?

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Notes on service discovery XS/XO

[pgf]

martin wrote:
 > On Tue, Apr 21, 2009 at 2:05 AM,   wrote:
 > 
 > > also note that this will require that you run some sort of
 > > DNS cache on the
 > 
 > The standard dns resolver libs on linux (part of glibc?) caches
 > alright. All platforms I know cache things alright, and it's fairly
 > serious bug if your OS doesn't.

really?  while that was the original design intent of the
resolver library, i didn't think it was ever implemented that way
in practice (on unix, at any rate) -- user programs tend to only
look up a name once, so caching in the resolver library wouldn't
do much good.  i believe caching is usually only done by servers.

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Notes on service discovery XS/XO

[pgf]

jonas wrote:
 > -BEGIN PGP SIGNED MESSAGE-
 > Hash: SHA1
 > 
 > On Mon, Apr 20, 2009 at 09:45:28AM -0400, p...@laptop.org wrote:
 > >benjamin m. schwartz wrote:
 > > > Martin Langhoff wrote:
 > > > > The short of it is that mdns/dns-sd make sense for a small, 
 > > > > underutilised network of peers. They assume that the network is a 
 > > > > cheap resource, that broadcast messages are cheap, and that there 
 > > > > is no coordinating server.
 > > > 
 > > > mDNS assumes all of the above things.  DNS-SD does not.  DNS-SD is 
 > > > perfectly happy to work on a standard DNS server.  From the spec
 > > > 
 > > > """
 > > >This document proposes no change to the structure of DNS 
 > > >messages, and no new operation codes, response codes, resource 
 > > >record types, or any other new DNS protocol values. This document 
 > > >simply specifies a convention for how existing resource record 
 > > >types can be named and structured to facilitate service 
 > > >discovery.
 > > > """
 > > > (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt)
 > >
 > >the last i looked at (and actually used) dns-sd to solve the
 > >discovery problem, it seemed that dns-sd development had stalled. 
 > >(and i haven't had a reason to look since.)  i believe we used
 > >code from Sun, which was all i could find at the time, and it
 > >wasn't what you'd call production ready.  on the other hand, we
 > >were using it in a somewhat non-standard way -- in fact, we
 > >switched to mdns soon after because it fit our deployment model
 > >better, since we didn't really have a central server.  the XS
 > >model may be a better fit.
 > >
 > >(this was all 3 or 4 years ago, btw.)
 > 
 > Here's my understanding:
 > 
 >   * DNS-SD is a formalized use of DNS records to store services
 > (rather than hosts, the most popular use of DNS records).
 > 
 >   * mDNS is DNS over multicast (using DNS-SD to resolve services).

sigh.

please disregard everything i wrote in the paragraph above.
i was mistakenly referring to DNS-SD when i should have been
referring to SLP ("service location protocol").  we migrated from
SLP to mDNS.  this has nothing to do with anything martin has
proposed for the XS.  sorry!  :-)

paul

 > 
 > So it seems to me that if you've switched from DNS-SD to mDNS, then in 
 > fact you are still relying on DNS-SD, just using an additional layer on 
 > top of it.
 > 
 > A good introduction (assumably more reliable than Wikipedia) is 
 > http://www.dns-sd.org/
 > 
 > 
 >   - Jonas
 > 
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Notes on service discovery XS/XO

[pgf]

martin wrote:
 > On Mon, Apr 20, 2009 at 3:53 PM, Jonas Smedegaard  wrote:
 > > DNS-SD using unicast DNS seems reasonable to me too.
 > 
 > If we can do without the avahi gunk, and use it in a way that is not
 > optimised for user driven browsing but for automated selection of
 > services, then it might work.
 > 
 > > Looking closer at the RFC, the initial service queries do have an added
 > > overhead in that a layer of indirection is used (not SRV -> A, but
 > > instead PTR -> SRV + TXT -> A).  But standard DNS optimizations apply,
 > > so SOA record should allow clients to preserve bandwidth through
 > > caching.
 > 
 > Can we teach dnsmasq to push all the relevant records with the SOA record?
 > 
 > > In other words: Install dnsmasq on the XOs, use plain standard DNS
 > > internally and on the wire, setup DNS-SD entries in a standard
 > > nameserver on the XS, and extend Sugar to support DNS-SD.
 > >
 > > I'd be happy to help compose standard BIND9 files, if that is what will
 > > be used on the XS.
 > 
 > If we have a dnsmasq resident expert, I rather use your help
 > transitioning to dnsmasq (note - with several bits of weird dhcp
 > rules). There is no upside to BIND and plenty of downsides, starting
 > with the >25MB memory footprint.

i'm a big fan of dnsmasq, but be sure it will fulfill all your
needs before doing too much work on it -- it's not quite a
full-fledged DNS server -- as an example, dnsmasq doesn't support CNAME:
   http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2006q1/000583.html

 >  - ask interesting questions

simon kelley (dnsmasq author) is extremely helpful on the dnsmasq
list, btw, so it shouldn't be too hard to get interesting
answers, as well.  :-)

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Notes on service discovery XS/XO

[pgf]

benjamin m. schwartz wrote:
 > Martin Langhoff wrote:
 > > The short of it is that mdns/dns-sd make sense for a small,
 > > underutilised network of peers. They assume that the network is a
 > > cheap resource, that broadcast messages are cheap, and that there is
 > > no coordinating server.
 > 
 > mDNS assumes all of the above things.  DNS-SD does not.  DNS-SD is
 > perfectly happy to work on a standard DNS server.  From the spec
 > 
 > """
 >This document proposes no change to the structure of DNS messages,
 >and no new operation codes, response codes, resource record types,
 >or any other new DNS protocol values. This document simply specifies
 >a convention for how existing resource record types can be named and
 >structured to facilitate service discovery.
 > """
 > (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt)

the last i looked at (and actually used) dns-sd to solve the
discovery problem, it seemed that dns-sd development had stalled. 
(and i haven't had a reason to look since.)  i believe we used
code from Sun, which was all i could find at the time, and it
wasn't what you'd call production ready.  on the other hand, we
were using it in a somewhat non-standard way -- in fact, we
switched to mdns soon after because it fit our deployment model
better, since we didn't really have a central server.  the XS
model may be a better fit.

(this was all 3 or 4 years ago, btw.)

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] new releases of powerd and olpc-kbdshim (alt. power mgmnt)

[pgf]

i wrote:
 >   olpc-kbdshim should work on the
 > latest rawhide releases.  (i hope -- feedback please, i haven't
 > had a chance to try rawhide myself.)

i've gotten my feedback:  in a word, don't bother.  :-)  the grab
keys might work, but rotation is broken, not only because the
location of keyhandler.py has changed under rawhide, but dcon
support isn't complete.

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] new releases of powerd and olpc-kbdshim (alt. power mgmnt)

[pgf]

i've released a new version of both olpc-kbdshim and powerd.

olpc-kbshim supports the XO grab keys, rotates the touchpad action
when the screen rotates, and provides user (in)activity status
for powerd.  with this release olpc-kbdshim is now integrated
with HAL in order to allow tracking USB mice and keyboards.

powerd is a more flexible and configurable replacement for ohmd. 
it's not a "drop-in" replacement, but it's getting close -- there
are a few things ohmd provides which are hard for powerd to do
in exactly the same way.

i'm about to start the review process for getting these both into
fedora -- if you've been thinking of trying them, but haven't, i
could use the feedback.  remember that you'll need to install
powerd on a laptop running an OLPC kernel, otherwise suspend and
resume won't do anything anyway.  olpc-kbdshim should work on the
latest rawhide releases.  (i hope -- feedback please, i haven't
had a chance to try rawhide myself.)

powerd disables ohmd when it installs, and reenables it if it's
uninstalled.  so there's no conflict unless you install ohmd
after powerd, which is unlikely.

both packages will apply small patches to sugars keyhandler.py,
in order to take back control of the rotation and brightness
keys.  (i've suggested these patches become permanent, somehow,
in SL #737.) if you later remove either of my packages, the
keyhandler.py patches remain, but are benign.

i could go on about features, etc, here, but since i'd be quoting
or paraphrasing info that comes with the packages, i'll just
refer directly there.

olpc-kbdshim  is described in its README:
http://dev.laptop.org/git/users/pgf/olpc-kbdshim/tree/README

powerd is described by commentary in the core script itself:
http://dev.laptop.org/git/users/pgf/powerd/tree/powerd

the git trees for the two packages are here:
http://dev.laptop.org/git/users/pgf/olpc-kbdshim/
http://dev.laptop.org/git/users/pgf/powerd

RPMs live here:
http://dev.laptop.org/~pgf/rpms

and the initial announcements of powerd is here:
http://lists.laptop.org/pipermail/devel/2009-March/023798.html

olpc-kbdshim wasn't as well announced, but was described here:
http://lists.laptop.org/pipermail/devel/2009-March/023703.html

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Grassroots-l] personal Re: Experience w/ using GPS with XO laptops

[pgf]

edward wrote:
 > On Thu, Apr 2, 2009 at 9:22 AM, Jeff Mascornick  wrote:
 > > Thank you Steve!
 > > I am wondering about the LINUX based XO - I'm part of a team applying to
 > > deploy XOs to Tanzania and we are looking into incorporating GPS for
 > > cultural exchange/learning, environmental education and/or some other
 > > purposes.
 > >
 > > So, if anyone has info on using any GPS on Linux based XOs, please let me
 > > know.
 > 
 > That's a complicated question. There is plenty of GPS and GIS software
 > in the Linux world. Running graphical software under Sugar requires a
 > rewrite.
 > 
 > If you can make use of gpsd, the GPS daemon, within any existing Sugar
 > software, you are good.

you can also simply access the GPS device directly (they almost
all appear as serial ports).  and if the application is a new
one, it's probably worth looking at Gypsy, which might have
interfaces that suit modern programming paradigms better: 
http://gypsy.freedesktop.org/wiki/

my personal experience with GPS on the XO is limited to a single
program, called RoadMap, which is available as an activity on the
OLPC activity pages.  (i.e., it's not migrated to SL yet.) the US
streetmaps which are RoadMap's focus won't be of much use in
tanzania, but it also supports OpenStreetMap data
(www.openstreetmap.org).  to the extent that OpenStreetMap may
have existing coverage of tanzania, and/or to the extent that
street maps are interesting to schoolchildren (perhaps a project
to do mapping?), RoadMap might be interesting.  otherwise,
probably not.

coincidentally i responded to another RoadMap query on the devel
list this morning.  i'll just reference it here:
http://lists.laptop.org/pipermail/devel/2009-April/023991.html

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] announce: alternate power management

[pgf]

 clean shutdown on critically low battery.  (currently set at
 > >    a reported 5%, at which point my laptop would only run for
 > >    another couple of minutes.)
 > >
 > >  - the ability to run arbitrary scripts after a resume.  (perhaps
 > >    to reinit usb devices that don't suspend/resume properly?  haven't
 > >    used this much yet.)
 > >
 > >  - ease of customization, given that it's written in everyone's
 > >    favorite interpreted language.
 > >
 > >  unimplemented:
 > >
 > >  - inhibiting idle suspend based on system or network load.
 > >    i.e., the system will dim or suspend when watching a video.
 > >    (there are hooks in place where these features should be
 > >    implemented -- they're just not coded at all.)  there's
 > >    no /etc/ohmd directory, so it honors /var/run/inhibit-idle-suspend
 > >    instead.
 > >
 > >  - no special support for the wireless mesh, whatsoever.  i
 > >    couldn't remember how it was supposed to work, and i recall
 > >    cjb saying it's hard to figure out whether the mesh is active
 > >    or not.
 > >
 > >  - there's some support for wake-on-wlan, but it's not well tested.
 > >
 > >  finally a big one:
 > >  - proper support for USB keyboards and mice.  i recently
 > >    realized that since olpc-kbdshim only monitors the built-in
 > >    keyboard and touchpad, powerd will think the user is idle
 > >    while they type on a USB keyboard, and cheerfully suspend
 > >    regardless.  (in my case, most of the time i want to
 > >    auto-suspend is when i'm running on battery, and not using
 > >    external devices, so i sort of forgot about this case.)
 > >
 > > anyway, code is available here:
 > >    http://dev.laptop.org/git/users/pgf/powerd/
 > > and rpms are here:
 > >    http://dev.laptop.org/~pgf/rpms/
 > >
 > > you'll need to install both olpc-kbdshim and olpc-powerd (in that
 > > order).  when installed, olpc-powerd disables ohmd, and reenables
 > > it when uninstalled.  (so it's relatively safe to try.)
 > >
 > > there's no gui or other convenience for configuration --
 > > see/etc/powerd/powerd.conf.  the installed defaults should be
 > > reasonable.  and you'll need to run:
 > >    echo reconfig >/var/run/powerevents
 > > after making changes to the config file.
 > >
 > > paul
 > > =-
 > >  paul fox, p...@laptop.org
 > > ___
 > > Devel mailing list
 > > de...@lists.laptop.org
 > > http://lists.laptop.org/listinfo/devel
 > >

=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] instructions for flashing SoaS on a XO

[pgf]

mitch wrote:
 > >
 > > My XO Boots but gets stuck loading the initrd.
 > >
 > > OFW Q2E34
 > >
 > > Here is what I see on the screen
 > >
 > > Boot device: /nandflash:\boot\olpc.fth Arguments:
 > > Boot device: /nandflash:\boot\vmlinuz0 Arguments: root=mtd0 
 > > rootfstype=jffs2
 > > liveimg console=tty0 console=ttyS0,115200 boot_delay=3 fbcon=font:SUN12x22
 > > Loading ramdisk image from nand:\boot\initrd0.img
 > >
 > > It stays there its been about 20 minutes now.
 > >
 > >
 > >   
 > 
 > Try booting with the check button (game key above the power button) held 
 > down.
 > 
 > If that fixes the problem, the issues is that the OS is not switching 
 > from "pretty boot" mode to active screen mode.

i only realized recently that the final unfreeze of the screen
is not done in bootanim, as i expected, but by way of sugar installing
a g_idle callback that sends a message to ohmd to do the unfreeze.  so
if either sugar or ohmd don't start correctly, the screen will stay
frozen.  this doesn't seem optimal to me.  (and it may be that i have
it wrong, and there's another unfreeze mechanism as well.)

(when powerd replaces ohmd, it simply does the unfreeze after 10 seconds
have passed.  also sub-optimal.)

paul

 > 
 > You can disable pretty-boot by adding these lines to /boot/olpc.fth :
 > 
 >unfreeze visible
 > 
 > The second line, just after the comment line, is a good place for them.
 > 
 > ___
 > Sugar-devel mailing list
 > Sugar-devel@lists.sugarlabs.org
 > http://lists.sugarlabs.org/listinfo/sugar-devel

=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] announce: alternate power management

[pgf]

okay, if i don't quit playing with this thing and get the taxes
done, my wife will kill me.

so:  i've packaged a new version of powerd.  the big change
is that it now allows for the two modes of operation i mentioned
last week on the list:
dim
sleep, screen on
sleep, screen off
shutdown
or:
dim
screen off
sleep, screen off
shutdown

(in contrast, the current releases only really support
dim
sleep, screen on
after that you have to do things manually.)

in addition, powerd can use a completely different configuration
profile when running in ebook mode -- in fact, you can have multiple
profiles (you know you've always wanted a different power behavior
when taking your laptop to the beach, right?) and switch between
them pretty easily.

there's also a (very) primitive configuration utility that lets
you select the major configuration parameters.  (it's dialog-based,
so it's curses-based graphics.  you've been warned.)

by default, power management is only active when you're running
on battery.  that's selectable.

the big items listed under "unimplemented" down below are still
unimplemented.  don't know when i'll get to them.

enjoy.  please try it, please let me know what you find.  i've
seen a few anomolies while playing with it -- most of which i
think i've fixed.  but there may well be more, since i think i've
seen at least one i still can't really explain.  (but it was
after a couple of glasses of wine, so who knows.)

code:
      http://dev.laptop.org/git/users/pgf/powerd/
rpms:
  http://dev.laptop.org/~pgf/rpms/

paul



p...@laptop.org wrote:
 > hi --
 > 
 > i had an itch that needed scratching, and the result is a
 > reimplementation of much (but not all) of what ohmd does
 > currently.
 > 
 > i've thought for some time (and i believe cjb agrees) that ohmd
 > is needlessly difficult to maintain and modify for our purposes
 > on the XO.  small improvements are difficult to implement
 > quickly.
 > 
 > since my heart is with more quasi-embedded systems than the XO's
 > current incarnation, part of my goal was to do a rewrite which
 > was not dependent on hald, dbus, or X11 -- power management
 > should work well from a console screen, and be available even if
 > none of those services is running.
 > 
 > i call the service i wrote "powerd".  it gets user idle/active
 > reports from the olpc-kbdshim daemon (which is watching all
 > user keypress and touchpad activity in any case), and it gets
 > reports regarding the hardware inputs (power button, lid and
 > ebook switches, ac adapter status, battery level, etc) either
 > from another small daemon that monitors /dev/input/event{0,1,2},
 > or from /sys nodes directly.
 > 
 > it basically recreates ohmd's "dim after a bit, then sleep"
 > behavior, with some additions:
 > 
 >   - a power button splash screen:  a second press of the power
 >  button invokes shutdown, simply waiting for a brief timeout
 >  invokes suspend, and any user activity cancels.  (i even
 >  managed to kinda sorta convey all that with graphics.  i'm
 >  sure every UI person that sees it will roll their eyes.)
 > 
 >   - configurable timeouts for screen dim and sleep.  the dim
 > level is configurable.
 > 
 >   - different power management behavior when on wall power vs. 
 > battery -- many laptop owners don't need to be miserly with
 > power when running from an external source.  powerd makes
 > this behavior selectable.
 > 
 >   - different power behavior when in ebook mode (though detection
 > may be unreliable -- i think the ebook switch suffers from
 > some issues we previously noticed with the lid switch).  this
 > should let you configure things like a very short timeout until
 > idle-suspend, and/or no screen dimming, when in ebook mode.  (i
 > find the frequent on/off nature of the backlight when reading
 > in ebook mode to be a distraction.)
 > 
 >   - clean shutdown on critically low battery.  (currently set at
 > a reported 5%, at which point my laptop would only run for
 > another couple of minutes.)
 > 
 >   - the ability to run arbitrary scripts after a resume.  (perhaps
 > to reinit usb devices that don't suspend/resume properly?  haven't
 > used this much yet.)
 > 
 >   - ease of customization, given that it's written in everyone's
 > favorite interpreted language.
 > 
 >  unimplemented:
 > 
 >   - inhibiting idle suspend based on system or network load. 
 > i.e., the system will dim or sus

Re: [Sugar-devel] Print Support proposal (need input) Beta

[pgf]

vamsi krishna davuluri wrote:
 > I see your point, I agree. I will do the elimination as is required, and
 > this time include a milestones/deadlines in my hopefully final draft
 > proposal.
 > My main objective will be to send the file from the laptop through the
 > network to the server, have the necessary code for it both sides.(and
 > ofcourse write UIs). (I'm actually having good experience with client-server
 > projects)

i've only started reading this thread in the middle, so forgive me
if i have this wrong:  are you planning on installing all of CUPS on
every laptop?  if so, that seems very expensive from a disk space
standpoint.  (every megabyte counts on the XO.)  the client code
should be as lightweight as possible, even if it limits flexibility.
(if someone, or some school, needs much greater flexibility, then
perhaps an alternate printing client can be installed -- there's no
need for one printing client to serve all needs.

paul

 > 
 > But if I should finish this earlier than the GSoC time span, and have
 > sufficient time I will work on print-to-pdf, or since I intend to become a
 > contributor, I will  focus on it as an interest. I'd very well like to see
 > myself implement this, so I will do this!
 > 
 > 
 > So Ben, do I write print-to-pdf in my proposal or not?  and if I do, what
 > would be the best way to do it?
 > 
 > 
 > 
 > 
 > On Fri, Mar 20, 2009 at 12:05 AM, Benjamin M. Schwartz
 > 
 > >
 > >
 > >
 > > Yes.  There are lots of potential use cases that you might support, but
 > > you will not be able to support them all.  I am suggesting that you
 > > approach this as a "critical path" problem.  Do the absolute minimum
 > > amount of work necessary to achieve useful functionality in some
 > > situations, and then grow it from there.
 > >
 > >
 > > I agree the ability to convert things to PDF would be nice to have.  I
 > > even proposed it as a feature of the Journal in June:
 > > http://lists.sugarlabs.org/archive/sugar-devel/2008-June/006598.html
 > >
 > > What I am saying here is: conversion to PDF within Sugar is not on the
 > > critical path to working print support.
 > >
 > >
 > >
 > > Well, that's fine.  I just want to warn you against putting too many
 > > things into one Summer of Code proposal.  Remember: most Summer of Code
 > > projects fail, because the project is too big and the code never reaches
 > > sufficient quality to be merged into the main codebase.
 > >
 > > - --Ben
 > > -BEGIN PGP SIGNATURE-
 > > Version: GnuPG v2.0.9 (GNU/Linux)
 > >
 > > iEYEARECAAYFAknCkFoACgkQUJT6e6HFtqQQEACcCmit2diezRw7Jsa3KW9UVuGo
 > > /msAniY1boOs/7GaXuDBnoZdjQ+7QKGQ
 > > =4kja
 > > -END PGP SIGNATURE-
 > >
 > part 2 text/plain 153
 > ___
 > Sugar-devel mailing list
 > Sugar-devel@lists.sugarlabs.org
 > http://lists.sugarlabs.org/listinfo/sugar-devel

=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] announce: alternate power management

[pgf]

scott wrote:
 > 
 > >  > 3. with the OLPC kernel and this olpc-kbdshim and olpc-powerd (which by
 > >  > the way are really realy nice, thanks a million pgf!) the XO suspends
 > >  > when via "lid" switch and the power button. 
 > > 
 > > great!  did you try the grab keys and rotation?  (those are just
 > > olpc-kbdshim.)  "olpc-rotate" should spin the display, even if the
 > > buttons don't work.
 > 
 > Pressing the rotation button does nothing in GNOME or Sugar. Should this
 > be a general X rotation that should work in any X session?

hmm.  i wouldn't expect the button to work in gnome, but i'd
expect the sugar bindings to continue working.  the first check,
though, it to see if the olpc-rotate command works from terminal. 
when olpc-kbdshim installs, it patches sugar to run that command
rather than do its normal internal calls to xrandr.  so if the
command works, but the key doesn't, the debug path is pretty
short, at least, i think.  (is is possible that sugar installed
after olpc-kbdshim?  that would explain it.)

 > What are grab keys? I am not seeing any functionality for the gamepad
 > keys. In the OLPC Fedora/Sugar these enable me to get around the "scroll
 > bar is not draw even though content is larger than frame" fun.

the grab keys are the two with the little hands, at either side
of the space bar.  on an "industry standard" keyboard, they would
be the bear the "industry monopolist" logo. :-)  when you hold
either down, a using the touchpad should cause whatever you're
looking at to scroll.  (if it's capable, of course -- i.e., wide
or tall web pages, or terminal sessions with any amount of
scrollback.)

 > 
 > >  > 
 > >  > 4. In a GNOME session, this behaves oddly, as gnome-power-manager also
 > >  > intercepts the power button press and pops up a
 > >  > "hibernate/suspend/yadayada/" dialog, and then your XO suspends
 > >  > anyway :-)
 > > 
 > > yeah, i kind of expected that.  similar issues happen if you run
 > > ohmd alongside powerd as well.  is g-p-m (easily) uninstallable?
 > 
 > Yes. Very easy to remove.
 > 
 > One additional point related to power management, the control panel in
 > the current Sugar RPMs (for rawhide/F11) doesn't have the power settings
 > ("extreme power management" etc.) icon. Perhaps there is a gconf key to
 > enable that? I asked in #sugar but got no reply. Or, is this
 > functionality removed on purpose?

don't know.

i have several questions about how XO-specific hardware will be
supported going forward.  i assume the sugar folks would rather
not continue carrying hardware specific key-bindings for rotation
and brightness for instance, but i don't know what their current
thoughts are.

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] announce: alternate power management

[pgf]

port for wake-on-wlan, but it's not well tested.
 > >
 > >  finally a big one:
 > >  - proper support for USB keyboards and mice.  i recently
 > >    realized that since olpc-kbdshim only monitors the built-in
 > >    keyboard and touchpad, powerd will think the user is idle
 > >    while they type on a USB keyboard, and cheerfully suspend
 > >    regardless.  (in my case, most of the time i want to
 > >    auto-suspend is when i'm running on battery, and not using
 > >    external devices, so i sort of forgot about this case.)
 > >
 > > anyway, code is available here:
 > >    http://dev.laptop.org/git/users/pgf/powerd/
 > > and rpms are here:
 > >    http://dev.laptop.org/~pgf/rpms/
 > >
 > > you'll need to install both olpc-kbdshim and olpc-powerd (in that
 > > order).  when installed, olpc-powerd disables ohmd, and reenables
 > > it when uninstalled.  (so it's relatively safe to try.)
 > >
 > > there's no gui or other convenience for configuration --
 > > see/etc/powerd/powerd.conf.  the installed defaults should be
 > > reasonable.  and you'll need to run:
 > >    echo reconfig >/var/run/powerevents
 > > after making changes to the config file.
 > >
 > > paul
 > > =-
 > >  paul fox, p...@laptop.org
 > > ___
 > > Sugar-devel mailing list
 > > Sugar-devel@lists.sugarlabs.org
 > > http://lists.sugarlabs.org/listinfo/sugar-devel
 > >

=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] announce: alternate power management

[pgf]

hi --

i had an itch that needed scratching, and the result is a
reimplementation of much (but not all) of what ohmd does
currently.

i've thought for some time (and i believe cjb agrees) that ohmd
is needlessly difficult to maintain and modify for our purposes
on the XO.  small improvements are difficult to implement
quickly.

since my heart is with more quasi-embedded systems than the XO's
current incarnation, part of my goal was to do a rewrite which
was not dependent on hald, dbus, or X11 -- power management
should work well from a console screen, and be available even if
none of those services is running.

i call the service i wrote "powerd".  it gets user idle/active
reports from the olpc-kbdshim daemon (which is watching all
user keypress and touchpad activity in any case), and it gets
reports regarding the hardware inputs (power button, lid and
ebook switches, ac adapter status, battery level, etc) either
from another small daemon that monitors /dev/input/event{0,1,2},
or from /sys nodes directly.

it basically recreates ohmd's "dim after a bit, then sleep"
behavior, with some additions:

  - a power button splash screen:  a second press of the power
 button invokes shutdown, simply waiting for a brief timeout
 invokes suspend, and any user activity cancels.  (i even
 managed to kinda sorta convey all that with graphics.  i'm
 sure every UI person that sees it will roll their eyes.)

  - configurable timeouts for screen dim and sleep.  the dim
level is configurable.

  - different power management behavior when on wall power vs. 
battery -- many laptop owners don't need to be miserly with
power when running from an external source.  powerd makes
this behavior selectable.

  - different power behavior when in ebook mode (though detection
may be unreliable -- i think the ebook switch suffers from
some issues we previously noticed with the lid switch).  this
should let you configure things like a very short timeout until
idle-suspend, and/or no screen dimming, when in ebook mode.  (i
find the frequent on/off nature of the backlight when reading
in ebook mode to be a distraction.)

  - clean shutdown on critically low battery.  (currently set at
a reported 5%, at which point my laptop would only run for
another couple of minutes.)

  - the ability to run arbitrary scripts after a resume.  (perhaps
to reinit usb devices that don't suspend/resume properly?  haven't
used this much yet.)

  - ease of customization, given that it's written in everyone's
favorite interpreted language.

 unimplemented:

  - inhibiting idle suspend based on system or network load. 
i.e., the system will dim or suspend when watching a video. 
(there are hooks in place where these features should be
implemented -- they're just not coded at all.)  there's
no /etc/ohmd directory, so it honors /var/run/inhibit-idle-suspend
instead.

  - no special support for the wireless mesh, whatsoever.  i
couldn't remember how it was supposed to work, and i recall
cjb saying it's hard to figure out whether the mesh is active
or not.

  - there's some support for wake-on-wlan, but it's not well tested.

  finally a big one:
  - proper support for USB keyboards and mice.  i recently
realized that since olpc-kbdshim only monitors the built-in
keyboard and touchpad, powerd will think the user is idle
while they type on a USB keyboard, and cheerfully suspend
regardless.  (in my case, most of the time i want to
auto-suspend is when i'm running on battery, and not using
external devices, so i sort of forgot about this case.)

anyway, code is available here:
http://dev.laptop.org/git/users/pgf/powerd/
and rpms are here:
http://dev.laptop.org/~pgf/rpms/

you'll need to install both olpc-kbdshim and olpc-powerd (in that
order).  when installed, olpc-powerd disables ohmd, and reenables
it when uninstalled.  (so it's relatively safe to try.)

there's no gui or other convenience for configuration --
see/etc/powerd/powerd.conf.  the installed defaults should be
reasonable.  and you'll need to run:
echo reconfig >/var/run/powerevents
after making changes to the config file.

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] fixing broken wiki-to-git links

[pgf]

with the recent switchover from, uh, whatever we were using
before, to cgit on dev.laptop.org, there are now many stale links
on wiki.laptop.org (and possibly some at sugarlabs as well, i
suppose).

if you do a google search on wiki.laptop.org for
"url:dev.laptop.org/git" you'll get almost 200 hits for such
links.  many of these are in the "Activity summary" section of
pages like this: http://wiki.laptop.org/go/Log_Viewer#Feature_requests

i assume a mechanical translation is possible, but i don't know. 

any volunteers to take this on, and make all those links work again?

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Fwd: Activity startup idea

[pgf]

tomeu wrote:
 > On Tue, Feb 24, 2009 at 03:38, Wade Brainerd  wrote:
 > > On Mon, Feb 23, 2009 at 5:57 PM, Luke Faraone  wrote:
 > >>
 > >> On Mon, Feb 23, 2009 at 5:46 PM, Carol Farlow Lerche 
 > >> wrote:
 > >>>
 > >>> Spend a few hours in a kindergarten classroom.  It doesn't work to
 > >>> prevent repeated launching of activities and ultimately a need to reboot.
 > >>
 > >> Is there anything sugar can do in this regard?
 > >>
 > >> Would this activity starting logic work:
 > >> * If no activity instances are running, start it.
 > >> * If an instance has been "started" already but the process has not yet
 > >> signaled on the dbus that it is "running", ie drawing windows etc. for the
 > >> user, switch to that instance
 > >> * If an instance has been started and is running, start a new instance.
 > >> (*or* send a "start new instance" request to the existing instance, which
 > >> allows us to save the overhead of loading up another "python" process)
 > >> * Reap all instances still in the "starting" state for more than X seconds
 > >> that have not explictly requested this functionality to be disabled nor
 > >> signaled via the dbus that they are still active
 > >
 > > What about watching system resources and refusing to start a new activity
 > > when there isn't enough RAM available to launch it?
 > > It should be pretty straightforward to add a required_memory field to
 > > activity.info - it would be a simple, approximate high water mark memory
 > > usage for a given activity.  The default could be determined by analyzing
 > > the basic activities - maybe 20mb would be good?
 > 
 > Are we sure this is a good experience for our users? I remember that
 > in the old MacOS times, I found a bit tiring to have to go to the
 > applications' info panel to lower the memory limits so the app could
 > launch.
 > 
 > The problem I see is that both the available memory in the system and
 > the consumed memory by a single activity are complex to measure and
 > much more to anticipate, so we probably won't get good enough
 > estimations to put in the activity.info.

for those just joining this 6 month old thread :-), here's a pointer
to at least part of the early history...

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] testers needed: grab keys and touchpad rotation

[pgf]

wade wrote:
 > Cool!  I'm looking forward to trying this when I get back to my XO
 > I wonder though, is there a reason this has to be a separate daemon, and
 > can't just being part of the HPGK driver with a /sys/... interface for
 > control?

it's a daemon very largely because much of the code already
existed in daemon form, from another project of mine.  it also
makes it much more flexible -- adding the rotation support was
trivial, for instance.  and i was able to include primitive (don't
disconnect it!) support for USB keyboards (since my XO has a
hardwired mini-usb keyboard in place of the standard one).  but
your point is a good one.  i just don't know how easy it would be
to to combine state from two drivers -- the mouse and keyboard
data travel pretty different paths, AFAICT.

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] SoaS on XO bootcharts

[pgf]

martin wrote:
 > In fact, this might be something that upstream wants to think about in
 > a generic sense. All the boot-in-5s focus lately is a lot of fun (and
 > great for end-users, I surely want _my_ boxes to boot in 5s), but
 > depends in part on skipping a lot of poking and waiting for hardware.
 > 
 > Anyone building a custom Fedora for a netbook will want the same thing
 > we want: a way to declare a "fast path" for known hw. Specially on the
 > netbook segment this can have a huge payoff. (Wonder if Ubuntu doing
 > something like this?)

i think the real win won't necessarily be declaring a fast path
for known hw, but _remembering_ a fast path for _any_ hardware. 
i.e., if you've booted 10 times and never found ipv6, and always
found the same 3 filesystems in the same partitions, maybe it's
time to stop expecting anything else.  does udev remember anything
from boot to boot?  seems like it should if it doesn't.

but as you say, there are also a lot of simple cases:  most machines
have just one network interface, and it runs dhcp -- so once that
seems to be true, don't check for anything else.  most machines
have one fixed disk, etc.

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] SoaS on XO bootcharts

[pgf]

bobby wrote:
 > On Wed, Mar 4, 2009 at 11:04 AM,   wrote:
 > > the shell is really pretty fast, if you can keep the number for
 > > spawned processes to a minimum.
 > 
 > this sounds like a super headache to get upstream, but with a possibly
 > significant payoff.  are the scripts you're talking about the ones in
 > /etc/init.d/ ?  it could be interesting to 'correct' the scripts and
 > see what the performance difference is.

now that it's been pointed out that most of the cat processes
were from bootchart itself, i highly doubt there will be
significant payoff.  but every little bit counts, and if
other changes were being made, one might as well do those
too.

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] testers wanted: grab keys, and touchpad rotation

[pgf]

bert wrote:
 > 
 > Just tried it on my XO at build 800 - works like a charm, both the  
 > scrolling and rotation. Yay!

great!

 > 
 > The only nit I have to pick is the inverted direction of scrolling.  
 > With both a scroll-wheel and my MacBook's "two-finger" scroll, moving  
 > down does scroll down. I understand about the grab metaphor implied by  
 > the key caps, but since we're not actually grabbing but scrolling,  
 > IMHO it should scroll the other way.

if you edit /etc/events.d/olpc-kbdshim and add a "-r" to the
olpc-kbdshim invocation line, you can try that behavior to see
how you like it.

edit, then:
initctl stop olpc-kbdshim
initctl start olpc-kbdshim

others should weigh in on this.  you'll remember that it was the
big question i raised last week.  i think i agree with you, but i
also think it's hard to put oneself in the shoes of a user who
has never used a scrollbar before.

paul
who is hoping he can send at least one message today without botching
the From line, the Subject line, or the To line.
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] testers needed: grab keys and touchpad rotation

[pgf]

sorry about that.  replying to add a subject...

i wrote:
 > 
 > last week i announced a daemon that would activate the grab keys
 > on the XO keyboard.
 > 
 > a day or two later there was a thread about how it would be nice
 > if the action of the touchpad rotated with the screen (in much the
 > same way that the dpad keys do).
 > 
 > since my daemon was already looking at every input event, it seemed
 > a natural place to implement the rotation feature.
 > 
 > and after doing that, the name seemed like it should change.
 > 
 > so, announcing "olpc-kbdshim".
 > 
 > source:
 > http://dev.laptop.org/git?p=users/pgf/olpc-kbdshim
 > 
 > rpm:
 > http://dev.laptop.org/~pgf/rpms/olpc-kbdshim-1-1.i386.rpm
 > 
 > after installing the rpm you need to fully reboot your laptop to
 > get the plumbing set up properly.
 > 
 > the rpm includes a new command "olpc-rotate" which takes care of
 > all the mechanics of screen and touchpad rotation.  since sugar
 > (currently) handles this key binding, the rpm postinstall script
 > patches /usr/share/sugar/shell/view/keyhandler.py so that it
 > invokes os.system("olpc-rotate") _instead_ of its current builtin
 > behavior.  separating it out like this makes olpc-kbdshim and
 > olpc-rotate more useful for non-sugar UIs.  i wrote the sugar
 > patch so that it won't break if you uninstall the olpc-kbdshim
 > rpm -- sugar will take over the rotate function again.  also,
 > though i haven't tried it on today's brand-new sugar 0.84 (good
 > work everyone!), a look at the current keyhandler.py says the patch
 > should still apply correctly.
 > 
 > the topic of ebook-mode touchpad usage came up the other day too.
 > while i didn't create any visible UI support for it, the daemon
 > will put the touchpad in and out of ebook-mode (which means,
 > reflecting it on both x and y axes) using "olpc-rotate -e/-n"
 > 
 > please let me know what you think...
 > 
 > paul
 > 
 > p.s.  btw, the daemon isn't really very olpc-specific.  i've been
 > running it on my thinkpad all week, in order to get the use of
 > the grab key scrolling.  the thinkpad doesn't have Windows keys
 > (which is what the XO grab keys are), but it turns out the blue
 > Fn key in the corner can be used as a modifier, so that plus my
 > trackstick gives 2D scrolling -- it came in very handy for
 > looking at the bootchart images this morning.
 > 

=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] (no subject)

[pgf]

[resend from subscribed address]

last week i announced a daemon that would activate the grab keys
on the XO keyboard.

a day or two later there was a thread about how it would be nice
if the action of the touchpad rotated with the screen (in much the
same way that the dpad keys do).

since my daemon was already looking at every input event, it seemed
a natural place to implement the rotation feature.

and after doing that, the name seemed like it should change.

so, announcing "olpc-kbdshim".

source:
http://dev.laptop.org/git?p=users/pgf/olpc-kbdshim

rpm:
http://dev.laptop.org/~pgf/rpms/olpc-kbdshim-1-1.i386.rpm

after installing the rpm you need to fully reboot your laptop to
get the plumbing set up properly.

the rpm includes a new command "olpc-rotate" which takes care of
all the mechanics of screen and touchpad rotation.  since sugar
(currently) handles this key binding, the rpm postinstall script
patches /usr/share/sugar/shell/view/keyhandler.py so that it
invokes os.system("olpc-rotate") _instead_ of its current builtin
behavior.  separating it out like this makes olpc-kbdshim and
olpc-rotate more useful for non-sugar UIs.  i wrote the sugar
patch so that it won't break if you uninstall the olpc-kbdshim
rpm -- sugar will take over the rotate function again.  also,
though i haven't tried it on today's brand-new sugar 0.84 (good
work everyone!), a look at the current keyhandler.py says the patch
should still apply correctly.

the topic of ebook-mode touchpad usage came up the other day too.
while i didn't create any visible UI support for it, the daemon
will put the touchpad in and out of ebook-mode (which means,
reflecting it on both x and y axes) using "olpc-rotate -e/-n"

please let me know what you think...

paul

p.s.  btw, the daemon isn't really very olpc-specific.  i've been
running it on my thinkpad all week, in order to get the use of
the grab key scrolling.  the thinkpad doesn't have Windows keys
(which is what the XO grab keys are), but it turns out the blue
Fn key in the corner can be used as a modifier, so that plus my
trackstick gives 2D scrolling -- it came in very handy for
looking at the bootchart images this morning.

=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] SoaS on XO bootcharts

[pgf]

wade wrote:
 > These charts are really interesting (and nice looking!).  The whole thing
 > probably requires a lot of analysis to make real gains though.  I wonder
 > what all those calls to 'cat' are in the first chart.  I also wonder if it

i did some looking, and while i don't think i've found the
real culprit, i have found a _lot_ of usage of this idiom in the
scripts:

[A]
cmdline=$(cat /proc/cmdline)

or

[B]
if [ `cat /proc/sys/net/ipv4/ip_forward` != 0 ]; then
action $"Disabling IPv4 packet forwarding: " sysctl -w >
fi

or

[C]
mfgtag () {
cat $MFG_DATA/$1 | tr -d '\000' 2>/dev/null
}


in every case, the "cat" process is completely unnecessary.

if i thought bash was a good idea, i'd point out:
$(< file)
which returns the contents of "file".  but even without
bash (which is probably appropriate if you're looking for
efficiency), you can do:

[A]
read cmdline < /proc/cmdline

and this, which preserves the look of the code a bit more:

[B]
firstline()
{
read __line < $1;  echo "$__line"
}

if [ `firstline /proc/sys/net/ipv4/ip_forward` != 0 ]; then
action $"Disabling IPv4 packet forwarding: " sysctl -w >
fi

and finally this:

[C]
mfgtag () {
tr -d '\000' < $MFG_DATA/$1  2>/dev/null
}

or even:

[C]
mfgtag () {
tr -d '\000' $MFG_DATA/$1  2>/dev/null
}

the shell is really pretty fast, if you can keep the number for
spawned processes to a minimum.

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] LiveCD with image writing activity (was Re: easier installation of soas)

[pgf]

tomeu wrote:
 > On Sun, Mar 1, 2009 at 21:47, Carol Farlow Lerche  wrote:
 > > Make the LiveCD have a usb maker on the desktop when launched.
 > 
 > That sounds like a really really good idea to me.

since i only discovered this recently, i'll mention that ubuntu
ships with just such a livecd-to-usb converter (usb-creator -- it's
under System->Administration->Create a USB Startup Disk).  i
don't know whether there's a fedoran equivalent.

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] easier installation of soas

[pgf]

eben wrote:
 > On Sun, Mar 1, 2009 at 2:41 PM, Sascha Silbe
 >  wrote:
 > > On Sun, Mar 01, 2009 at 01:58:30PM -0500, Eben Eliason wrote:
 > >
 > >> As I understand it, this cannot be so simple because it needs to be a
 > >> bootable image, and not just a set of files.
 > >
 > > What about raw disk images that could be written with dd? No need for any
 > > fancy GUI stuff, a single command line invocation suffices (dd is included
 > > by default on most distros), no need to install potential harmful
 > > third-party software.
 > 
 > This assumption, however, excludes the Windows-using majority.  Also,
 > single-line or not, many are uncomfortable with the command line in
 > principle (though that's significantly less true, obviously, among
 > Linux users).

commandline discomfort aside, i recall that in the early days of
linux distribution, the problem was exactly analogous to what's
being discussed here, except the target was floppies.  at the
time, there was a dos/windows utility called "rawrite.exe" which
was used to transfer the initial boot image to a floppy.  i have
no idea how that worked, whether it would still work on modern
windows, nor whether it could be made to work with USB or SD.  it
might be worth somebody doing the investigation, however.

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] OS/X11 support for XO-1 hardware?

[pgf]

benjamin m. schwartz wrote:
 > 
 > There are lots of good reasons to play with screen resolution.  My
 > favorite reason is that reducing the resolution to 800x600 would make all
 > graphical operations runs twice as fast, and use half as much memory,
 > while introducing a negligible drop in display quality (the display,
 > remember, is not _really_ 1200x900 in color mode; the total number of
 > color elements is equivalent to 800x450).

not to mention the compatibility improvements with previously tuned
desktop environments:  in a conversation with erig garrison late last
year, he pointed out that the absolutely best way to make XFCE look
good on the XO display was to simply scale the display so that its
dimensions were closer to what the designers used.  no more unclickable
icons, no more unreadable text.

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] future of the grab key?

[pgf]

eben wrote:
 > On Tue, Feb 24, 2009 at 3:31 PM,   wrote:
 > > but what i'd done was different:  when one's finger moved on the
 > > touchpad, the _scrollbars_ moved.  the mouse pointer stayed
 > > stationary with respect to the window edges, and the window
 > > contents moved in the _opposite_ direction from the finger on
 > > the touchpad.
 > >
 > > since i wasn't sure what to make of this frame-of-reference
 > > reversal, i did the obvious thing:  i reversed the behavior, but
 > > added a commandline option to put it back, just in case.  (the
 > > original "backward" behavior still feels more correct on the
 > > joystick pointer of my original project, for instance.)
 > 
 > Yes, I believe that reversing the events as you have is the correct default.

okay -- thanks for the confirmation.

 > > since the mouse cursor remains stationary on the screen, it still
 > > doesn't feel like you're "grabbing" the contents, but it's may be
 > > more intuitive than the way it was.  any thoughts on this?
 > 
 > Right.  This is a subtle problem anyway, since naturally it's
 > undesirable to require one to release the grab key, move the pointer
 > back, press the grab key again, and repeat in order to continue
 > scrolling.  One option is to move the cursor in accordance with the
 > finger on the touchpad, but automatically slide it back to the point
 > of the initial grab when the finger loses contact, as though on a
 > spring.
 > 
 > That solution doesn't seem particularly ideal either, though.  Perhaps
 > a stationary cursor is fine, and certainly any working behavior is
 > better than a useless button.  What would be nice, though, is some
 > feedback in the form of a cursor change.  We have hand cursors (both

ah, good point.

currently the daemon intercepts the grab keys completely (so
there's no indication to X that the cursor shape should change),
but i suppose that's not necessary.  if they were passed through,
then the WM could surely do something clever with the cursor.

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] future of the grab key?

[pgf]

david wrote:
 > Paul,
 > 
 > You are not probably not going to get much feedback from core
 > developers on grab right now.

gee, way to let them all off the hook, david.  :-)

 > 
 > That has nothing to do with the validity of the design or the quality
 > of the implementation.
 > 
 > It is entirely to do with where Sugar is in the release cycle.
 > Testing and debugging.
 > 
 > When the merge window opens in a few weeks you work will receive a
 > much more through review.

no prob.  of course, i'd be really excited in a few weeks if i had
no time of my own to respond to a review.  ;-)

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] future of the grab key?

[pgf]

since we're examining unloved features today, i have something
to show and tell, too.

i'd like to get input on some work i've done to get the grab
key(s) on the XO working.  i don't think what i've done is quite
how they were originally planned to work, but maybe it's close
enough.  i also know erik did a bunch of work on this last fall
(see extensive patches on #447), and i've never been sure why
that hasn't gotten picked up, so i'd like to know more about
that, too.

background:  i've been working on a (non-XO) project recently
that led me to implement a userspace virtual keyboard.  as the last
step of that project, i implemented modifier-based scrolling -- i
can hold a key, use the joystick (on the keyboard device in
question), and instead of getting motion events, scroll-button-press
events are generated and injected into the uinput device.  it
works very nicely.

when i asked a question related to my project a few weeks ago on
IRC, tomeu asked if i was thinking about the grab key.  i wasn't
back then, but the thought stuck with me.

so:  i've now implemented a fairly small daemon that sits between
the XO keyboard/touchpad pair and the evdev kernel driver.  it
opens the keyboard and touchpad /dev/input/eventN nodes (in such
a way that X will skip them when it starts), creates a third
eventN node via uinput, and shuttles events in between.  the only
thing it does with the data is watch for the grab keys -- when it
sees one, it does as described above:  ensuing touchpad events
are translated into a smaller number of scroll-button events, and
as a result the window moves instead of the mouse pointer.

but as i was finishing it up and testing it, i realized that it
doesn't really do what i pictured the grab key as doing.

i had pictured the grab key as causing the mouse cursor to, well,
"grab" the window contents, to allow dragging it around.  (just
like clicking and dragging on google maps.)

but what i'd done was different:  when one's finger moved on the
touchpad, the _scrollbars_ moved.  the mouse pointer stayed
stationary with respect to the window edges, and the window
contents moved in the _opposite_ direction from the finger on
the touchpad.

since i wasn't sure what to make of this frame-of-reference
reversal, i did the obvious thing:  i reversed the behavior, but
added a commandline option to put it back, just in case.  (the
original "backward" behavior still feels more correct on the
joystick pointer of my original project, for instance.)

since the mouse cursor remains stationary on the screen, it still
doesn't feel like you're "grabbing" the contents, but it's may be
more intuitive than the way it was.  any thoughts on this?

you can try it if you'd like:
http://dev.laptop.org/git?p=users/pgf/grabkeyd
it needs to be started before X, and uinput needs to be loaded. 
(happily, uinput is already in the XO releases.) initially the
easiest way to test it is:
# modprobe uinput
# init 3
# ./grabkeyd -l
[ check that grabkeyd is running, check /var/log/messages
for failure ]
# init 5

as i recall, one of the objections to erik's implementation last
year was that it required the XTEST extension, which is considered
a security risk.  as far as i know, there's no risk to my current
implementation.  (other than, if it dies, you lose your mouse and
keyboard.  uh oh -- better run it from init.  :-)

because it's in a fairly critical path, grabkeyd has facility for
running at an elevated scheduling priority.  currently this is a
SCHED_FIFO priority, which is probably safe, but perhaps
overkill.  it's not the default.

comments solicited...


paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Future of Rainbow + Sugar?

[pgf]

bert wrote:
 > On 24.02.2009, at 19:09, Carol Farlow Lerche wrote:
 ...
 > > Asking for better documentation doesn't imply that the facility is  
 > > new.  It recognizes that development has reached a local minimum in  
 > > an important component that is not well understood by many.  My post  
 > > was a request to the most knowledgeable person, Michael to do the  
 > > service of taking the time to write a document that clearly lays out
 > >
 > > .  the purpose (not in security speak but in terms of the benefits  
 > > it brings to end users),

for my part, i've always felt that it's this first point of
carol's that's been missing from the docs.  the functional
overview is very important:  as a developer, you're asking me to
implement a bunch of new API functionality simply to make a
simple program (which may already be working well in most other unix
environments) functional.  i'd like to be sold on the concept
first, before having to do a bunch of work for no (apparent) benefit
to me or my program.

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Activities] using the browser to display help/docs

[pgf]

i promised simon on irc that i'd raise this on the sugar devel
list, so thanks for replying and reminding me.

(to recap:  my "legacy" activity would like to be able to present
help and documentation info to the user via the local browser.)

s page wrote:
 > p...@laptop.org wrote:
 > > can someone remind me if there's any reasonable way for an
 > > activity to display html help or documentation using Browse?
 > > 
 > > normally i'd simply have the app run "firefox file:///path-to-file",
 > > but that won't work. 
 > 
 > In candidate-800, Browse can view
 > file:///home/olpc/Activities/Maze.activity/activity/activity-maze.svg , 
 > so you would think you could tell it to launch and show your HTML help.
 > 
 > I dunno if Rainbow restricts one activity from launching another. 

i believe it does, which has always been the problem for doing what
i would like to do.

i think what might be useful (if rainbow is to be accomodated) is
a minimal-functionality html viewer.  i'd be okay, in my
activity, if the viewer didn't allow any off-page clicks or
scripts -- just html rendering.  doesn't seem like that would
cause a security issue, would it?

paul


 > Ignoring that, you would think you could run one activity from another 
 > using a) Python code, b) exec(), or c) DBus.
 > a) I couldn't figure out Journal's Start/Resume code, it seems to reach 
 > into datastore and activityfactory, which ends up invoking DBus.
 > 
 > b) From Terminal Activity you would think that
 >sugar-activity -u 'file:///{PATH_TO_YOUR_ACTIVITY}/myhtml/help.html'
 > would work, but I can't even get the sugar-activity exec line in 
 > Activities/Browse.activity/activity/activity.info to work.  The 
 > connection between its BUNDLE_ID, ACTIVITY_ID, OBJECT_ID and an 
 > activity's metadata like service_name is a mystery to me.
 > 
 > >  are there any workarounds (like tricking the
 > > file to be in the journal so that browse can see it, or something like
 > > that?
 > 
 > You could write code to display the HTML within your own activity...
 > 
 > >   how does the new pdf-in-browse trick work?
 > 
 >  From 
 > http://sayamindu.randomink.org/ramblings/2008/10/14/14th-october-2008/ ,
 > "Wrote a small PDF viewer tool with support for the Journal which is 
 > then used by mozplugger to show PDF files within Browse. (You can put 
 > the file in your journal if you like it)"
 > 
 > I.e. he's taking code that displays PDFs and running it inside the 
 > browser as a plug-in.  That seems unrelated to what you're trying to do.
 > 
 > Disclaimer: I have written four lines of Python code and zero activities ;-)
 > --
 > =S Page

=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Helping with activity development

[pgf]

wade wrote:
 > Hi Marco, Yifan!
 > 
 > Absolutely, there are a ton of activities which could use help right
 > now.  I'll throw out some options and you can pick the one you think
 > would be best suited to your skills:
 ...
 > 
 > Math - Another request by the Peru deployment is simple math games.  I
 > have started working on some math puzzles with Peter Moxhay, based a
 > suite of Java lessons he wrote in the past.  These are very early in
 > development but there are a lot of games to write.  Also, examples are
 > available, so it's really just porting and the work goes quickly.

at xocamp, bryan berry just described an elementary math activity
they're using in nepal.  (locally developed.) worth asking him
about.


=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Leaving

[pgf]

tomeu wrote:
 > On Fri, Jan 9, 2009 at 09:07, Edward Cherlin  wrote:
 > > On Thu, Jan 8, 2009 at 10:50 PM, C. Scott Ananian  
 > > wrote:
 > >> Like many others, Friday will be my last day employed by OLPC.  I've
 > >> enjoyed working on the project a lot, and hope to find some way to
 > >> continue the work that has been begun.
 > >
 > > I'm very sorry to hear that. Will you be able to attend XOCamp2?
 > >
 > > The next release of Sugar appears to be left hanging, with no comment
 > > from management. I find this appalling.
 > 
 > Did you really meant Sugar? Or OLPC?

the official announcement did a disservice by repeating the 
conflation of the terms "sugar" and "XO release".  they're obviously
quite related, but it's really the latter that i suspect edward was
referring to.

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] SVG performance

[pgf]

walter wrote:
 > And in the case of TA, I currently render about 30 svg files in the
 > initialization phase, hence the long delay. I'll look into how I can
 > background some of this.

there's only so much cpu.  how will that help?

i'd still like to know how fast it would be to render the equivalent
bitmap.

clearly SVG is the wave of the future, but current h/w is the
wave of the past.  if pre-rendering our icons in predictably
needed sizes (at build-time, not run-time) would help a lot, then
it seems like we should do that.

paul

 > 
 > -walter
 > 
 > On Tue, Dec 9, 2008 at 9:11 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:
 > > On Tue, Dec 9, 2008 at 3:04 PM,  <[EMAIL PROTECTED]> wrote:
 > >> bernie wrote:
 > >>  > Jim Gettys wrote:
 > >>  > > IIRC, librsvg is it.
 > >>  > >
 > >>  > > A bit more profiling to get through the tangled web of dependencies 
 > >> is
 > >>  > > probably in order.
 > >>  >
 > >>  > To exclude the noise coming from  Python and GDK, I tried timing again
 > >>  > with the command-line tool rsvg:
 > >>  >
 > >>  >   for i in *.svg; do echo $i; time rsvg $i $i.png; done
 > >>  >
 > >>  > This way I could not find any problematic svg file within the
 > >>  > turtleart repository.  The slowest ones render in <0.1 seconds.
 > >>
 > >> i'm not sure i'd agree that "<0.1 seconds" isn't problematic.  how
 > >> fast would the equivalent bitmap render?
 > >
 > > In order to not give a perception of slugginesh, all UI operations
 > > should take less than 0.2s.
 > >
 > > If one icon takes 0.05s, we can render 4 of them before starting to look 
 > > slow.
 > >
 > > So we need to make those values much lower, or stop rendering icons
 > > during UI operations.
 > >
 > > Regards,
 > >
 > > Tomeu
 > > ___
 > > Sugar-devel mailing list
 > > Sugar-devel@lists.sugarlabs.org
 > > http://lists.sugarlabs.org/listinfo/sugar-devel
 > >
 > 
 > 
 > 
 > -- 
 > Walter Bender
 > Sugar Labs
 > http://www.sugarlabs.org

=-
 paul fox, [EMAIL PROTECTED]
 give one laptop, get one laptop --- http://www.laptop.com/xo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] SVG performance

[pgf]

bernie wrote:
 > Jim Gettys wrote:
 > > IIRC, librsvg is it.
 > >
 > > A bit more profiling to get through the tangled web of dependencies is
 > > probably in order.
 > 
 > To exclude the noise coming from  Python and GDK, I tried timing again
 > with the command-line tool rsvg:
 > 
 >   for i in *.svg; do echo $i; time rsvg $i $i.png; done
 > 
 > This way I could not find any problematic svg file within the
 > turtleart repository.  The slowest ones render in <0.1 seconds.

i'm not sure i'd agree that "<0.1 seconds" isn't problematic.  how
fast would the equivalent bitmap render?

paul
=-
 paul fox, [EMAIL PROTECTED]
 give one laptop, get one laptop --- http://www.laptop.com/xo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Release tool

[pgf]

 > >>> The release tool in sugar-tools is hardcoded for dev.laptop.org
 > >>> tickets. How should we put trac numbers in commits so that we can
 > >>> extend it to handle dev.sugarlabs.org?
 > >>>
 > >>> I'm thinking something like "sl #1234" and we could add "olpc #1234"
 > >>> as well to make the distinction more obvious in future.
 > >>
 > >> What about defaulting to sl?
 > >
 > > Sure, as long as it's well communicated so that everyone using this
 > > tool gets it right... :)

i suppose it's a bit too late, and a bit too cumbersome, but if
sugarlabs started numbering bugs at 5, there would be at
least a year or two where the there would be no ambiguity between
olpc and sugar bug numbers.  (can trac be configured with alpha
prefixes?  e.g. "#S1234")

paul
=-
 paul fox, [EMAIL PROTECTED]
 give one laptop, get one laptop --- http://www.laptop.com/xo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] life w/o NM

[pgf]

aleksey wrote:
 > as far as I can understand, NM is required to monitor/set net
 > devices/self IPs.  Is it necessary to use it in case of common
 > desktop e.g. w/o wireless and with stable ethernet connection? 

no, certainly not.  unix systems with ethernet have existed far
longer than network manager.  (NM isn't _required_ for the
wireless case, either.)  but is it worth _not_ using network
manager for that one, mostly exceptional, case?  probably not. 
the trick is making sure network manager works correctly for that
case.

paul
=-
 paul fox, [EMAIL PROTECTED]
 give one laptop, get one laptop --- http://www.laptop.com/xo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel