Re: [Sugar-devel] seeking help to enable nepali keyboard input for XO-4
On 8 Nov 2013, at 14:24, Chris Leonard wrote: > What about a virtual touch keyboard layout? Just wondering? FWIW: I'm pretty sure (check [1] & [2]) that Nepali layouts were not part of the Maliit set I was asked to work on for the XO-4 touch keyboard layouts. It's been over a year ago, and a lot of things were going on, so my memory is a little rusty. If the XO-4's in question do have the touch screen hardware support, creating a layout file is not too difficult (as long as the required fonts glyphs are already installed). That is a beauty of touch screen keyboards, they may not be as good as tactile keyboards, but you can have almost any language layout you want with no hardware changes. [1] http://wiki.sugarlabs.org/go/User:Garycmartin/Maliit_Layouts [2] http://wiki.sugarlabs.org/go/User_talk:Garycmartin/Maliit#Currently_available_language_layouts Regards, --Gary > On Fri, Nov 8, 2013 at 8:46 AM, Basanta Shrestha > wrote: >> Hi Walter >> We don't have plans to use stickers at the moment. The stickers won't last >> long in the hands of kids. But we need to have some mechanism to input >> Nepali characters. For now we can give them a printout of the keyboard >> layout. >> Regards, >> Basanta >> >> >> >> On Fri, Nov 8, 2013 at 5:58 PM, Walter Bender >> wrote: >>> >>> A bit tricky because we don't have that key anymore (but we could come >>> up with some other key combination to enable it). Also, are you >>> planning to use stickers or some other way to add the proper glyths to >>> the keyboard? >>> >>> Happy to explore this with you further. >>> >>> regards. >>> >>> -walter >>> >>> On Fri, Nov 8, 2013 at 12:23 AM, Basanta Shrestha >>> wrote: Hi, I am writing this mail seeking a clue on where to start looking to enable Nepali input in XO4. For XO-1 we had nepali keyboard and there was a button just below the "enter" button which would switch input between English and Nepali. And that was very convenient. But for XO-4 we will just be getting ones with English layout. I was wondering how we can enable nepali keyboard input on it. I can see that the key maping file for nepali is already there under /usr/share/X11/xkb/symbols/ Thank you . -- Basanta Shrestha OLE Nepal ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel >>> >>> >>> >>> -- >>> Walter Bender >>> Sugar Labs >>> http://www.sugarlabs.org >> >> >> >> >> -- >> Basanta Shrestha >> Network Engineer >> Open Learning Exchange (OLE) Nepal >> Tel: +977.1.551, 5520075 Ext. 303 >> Cell: +977.9818 605110 >> http://www.olenepal.org >> >> ___ >> Sugar-devel mailing list >> sugar-de...@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel signature.asc Description: Message signed with OpenPGP using GPGMail ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-tablet development? [Devel Digest, Vol 90, Issue 8]
On 13 Aug 2013, at 19:41, John Watlington wrote: > > On Aug 13, 2013, at 1:09 PM, Yioryos Asprobounitis wrote: > Paul wrote: If not, which way the tablet/laptop development team is heading? >>> >>> don't know, sorry. >> >> OK, thanks. >> Hopefully someone that does will care to comment. > > It is lack of accurate knowledge of the future, not caring, > that keeps me from commenting. > >> The current laptop and tablet implementations differ significantly and >> would be important to have an indication where the (limited) resources >> should be deployed . > > How would you devote resources to the tablet ? It is closed source. > > There is an attempt within the Sugar (and OLPC) community to move > the educational environment to HTML, where it can be used on both > Android (tablet) and Linux (laptop). That is where I would suggest > deploying resources. Here's a wiki page Lionel Laskè has been keeping ticking over regarding HTML based Sugar efforts, most of the discussions so far have been over on the sugar-de...@lists.sugarlabs.org: http://wiki.sugarlabs.org/go/HTML5_activities Manuq has been working on some early Sugar-web based activity offerings (to help debug and test the new web api's, intended for the as yet unreleased Sugar 0.100): Clock Web: http://activities.sugarlabs.org/sugar/addon/4691/ Get Things Done: http://activities.sugarlabs.org/sugar/addon/4692/ Memorize Web: http://activities.sugarlabs.org/sugar/addon/4693/ Stopwatch Web: http://activities.sugarlabs.org/sugar/addon/4694/ Paint Web: http://activities.sugarlabs.org/sugar/addon/4695/ Gears: http://activities.sugarlabs.org/es-ES/sugar/addon/4696/ I'm not aware of much progress yet providing a path towards lower level Sugar features such as Neighbourhood view, Activity collaboration, the Journal, entry sharing, the Frame, for the Android based XO-Tablet offering. Regards, --Gary > Cheers, > wad > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Auckland Testing Summary 23 March 2013
Hi Tom, On 23 Mar 2013, at 08:43, Tom Parker wrote: > Auckland Testing Summary 23 March 2013 > Who: Fabiana, John, Hans, Oliver, Tabitha, Tom > > Testing 13.2.0 Build 1 on XO-1.75 and XO-4 > > No sound in TamTam or Speak on 3 out 5 XO-1.75s. Speak hung when saying a > sentence, scratch failed to start with an error in it’s log about missing > sound driver. Record hangs when you take a photo on those laptops that have > broken sound. We have discovered that this is related to firmware Q4D27, as > the two laptops that worked were still on Q4D24. Updating them caused the > sound to stop working. > > On Karearea, the UI did not respond to mouse clicks or keyboard input, but > the neighbourhood/friends/activity list keys worked. After 3 reboots this > started working and we discovered the wifi doesn’t work, eth0 exists but is > not configured. This laptop is one of the ones on which sound does not work. > > I have the /var/log/messages from a few laptops including Karearea's bad wifi > boot if anyone is interested. > > Measure seems fine > Physics still has the top of screen problem on XO-1.75 but is working very > well on XO-4. How critical do you think this one is? I have a patch from John that fixes this, it's related to hardware driver frame buffer support issues, but at the cost of some memory & performance cycles. Basically it removes pygame default screen buffering feature and does the buffering manually – no more white flicker at the top of the XO-1.75 redraw cycle, but not for free. Regards, --Gary > The context menu on the activity ring is annoying. It takes a long time to > appear and disappear. > > WikipediaEN works, WikipediaES works > > Browse still hangs on Zimbra. The PDF viewer embedded in browse doesn’t have > a jump to page option, and in touch mode, you can’t use the scroll bar > because you can’t reach it with your finger. If you open a pdf file, save it > to the journal, close browse and re-open then you can’t close the pdf tab, > raised http://bugs.sugarlabs.org/ticket/4471 > > Collaboration doesn’t work in write, does in chat. Access point, no school > server. Nothing interesting in the log. > > Battery life on XO-4 C2 seems significantly improved over previous builds. We > would be interested in a confirmation or otherwise of this in the power log > analysis. > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Is it possible to hack the "rotate" key?
Hi Ajay,
On 18 Feb 2013, at 11:12, Ajay Garg wrote:
> Hi all.
>
> Is it possible to hack the "rotate" key in XO?
>
> I wish to have the following working ::
>
> * Press the "rotate" key. This will rotate the window.
> * Just after that, have a callback function being called in "sugar"
> (this of course being possible only if the "rotate" key could be hacked).
>
>
>
> I will be thankful for any pointers.
This is a little out of my league, but I think you'll need to take a look at
olpc-kbdshim [1] so see how things are currently triggered, in particular the
olpc-rotate script. If you want to pickup aspect ration changes on the Sugar
side, perhaps hook a gtk.gdk.screen_get_default().connect('size-changed', ) callback intp the sugar toolkit. I've implemented
something simple like this in the Moon activity, so that it uses different
layouts for landscape and portrait screen orientations [3].
Regards,
--Gary
[1] http://dev.laptop.org/git/users/pgf/olpc-kbdshim/
[2] http://dev.laptop.org/git/users/pgf/olpc-kbdshim/tree/olpc-rotate
[3] http://git.sugarlabs.org/moon/mainline/blobs/master/moon.py
> Regards,
>
> Ajay Garg
> Dextrose Developer
> Activity Central: http://activitycentral.com
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: 13.1.0 build 29 for XO-4 released
Hi John, On 12 Feb 2013, at 13:58, Jon Nettleton wrote: > > On Feb 12, 2013 2:43 PM, "Walter Bender" wrote: > > > > On Tue, Feb 12, 2013 at 8:41 AM, Simon Schampijer > > wrote: > > > On 02/11/2013 08:59 PM, Daniel Drake wrote: > > >> > > >> Hi, > > >> > > >> Another XO-4 only build for 13.1.0: > > >> http://download.laptop.org/xo-4/os/candidate/13.1.0-29/ > > >> > > >> Changes are: > > >> - Improved power saving in graphics and other areas > > >> - Latest wake-on-WLAN developments > > >> - A potential fix for loss of mouse on boot (#12101) > > >> - Latest EC code > > >> - Wikipedia works when offline (#12479) > > >> > > >> Thanks > > >> Daniel > > > > > > > > > The most obvious issue I saw after booting the machine was that the Sugar > > > cursor was corrupted. At the left side there was some artifact. After > > > reboot > > > the cursor was fine. A known issue? > > > > FWIW, I saw that on os28 as well. > > > > > This is a known issue. Next release will have a better fix. Does this fix also resolve the small random graphic corruptions to the first boot welcome content? Regards, --Gary > > -Jon > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-4 not resuming after suspend
On 3 Feb 2013, at 22:04, Paul Fox wrote: > jerry wrote: >> On Sat, 2013-02-02 at 09:25 +1100, fors...@ozonline.com.au wrote: >>> I have an XO-4 B1, OFW Q7B14, EC Firmware 0.3.10, os28. >>> >>> It won't resume after suspend, but sometimes it does. I couldn't >>> reproduce the bug, but it happens most of the time. >>> ... >>> Anyone else seeing this? >>> >>> >> >> I'm seeing this with my B1, hard lock just after suspending, can't >> awaken the XO via any input method. Sorry no logs for this one. >> >> >>> For me, OS28 XO-4 doesnt seem to be going into suspend, mostly. It did >>> suspend once and when it resumed it did not load the cursor, just a square >>> of noise like a QR code, a bug we had in the early XO-4 builds. It seems >>> suspend has regressed from OS27. >>> >>> Tony >>> >> >> I'm seeing this with the C2 unit I have, enabling powerd's tracing shows >> suspend is being skipped with "cpu busy" once a rtcalarm wakeup event >> occurs during until_dim-soft. I have the logs if needed. > > thanks -- yes, we've observed that something is consuming cpu > on os28, preventing suspend. Testing os28 on a XO-4 B1, and XO-4 C2: Interestingly if automatic power management is disabled in Sugar, My Settings, the backlight does start to correctly auto switch off when idle. With automatic power management on it is even preventing the backlight from powering off. --Gary > paul > =- > paul fox, p...@laptop.org > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Cameras not working on XO-1s
Hi Christoph, On 30 Jan 2013, at 20:02, Christoph Derndorfer wrote: > Hi again, > > another issue we encountered during today's workshop session was that on 3~4 > XO-1s the camera didn't work (all machines are running 12.1.0 with the > associated firmware). Random FWIW, on my XO-1 B4 the camera stopped working (black screen). In this case, it was due to an overly short flat flex cable from the camera to the motherboard, where twisting pressure (opening/closing) on the case could pull the flat flex cable out of the socket enough to loose connection (I think movement of a usb key in one of the two right sockets could also trigger it). In my case sometimes slightly squeezing the case by the camera triggered the camera back into life for a short while. In the end I opened the unit up and firmly reseated the cable. It's been fine since then. This issue was subsequently fixed, but I'm not sure when. Regards, --Gary > The effect in Record is always the same: a grey still image. However when > running the hardware self-test 2 of the machines passed the test even though > the camera output on the display was total noise. With the other machine or > two the self-test failed. > > Since I've never seen issues with the camera before I was wondering whether > there was anything we could try beyond verifying that the camera connector is > in place (as described at > http://wiki.laptop.org/go/XO_Troubleshooting_AV#Errors_communicating_with_the_camera)? > > Thanks, > Christoph > > -- > Christoph Derndorfer > > volunteer, OLPC (Austria) [www.olpc.at] > editor, OLPC News [www.olpcnews.com] > contributor, TechnikBasteln [www.technikbasteln.net] > > e-mail: christ...@derndorfer.eu > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK
Hi Ajay, On 29 Jan 2013, at 05:17, Ajay Garg wrote: > I agree with Gonzalo and Gary; this is just a makeshift solution for the > time-being, so that activities like Speak, Chat, Terminal are not rendered > completely unusable in ebook-mode. > > Ideally, the best solution would be to have the OSK-appearance-and > window-shrinkage on "automatic" and "tied-together" basis (without needing > any manual intervention). FWIW, I'm still -1 on the window-shrinkage approach. Most activities will handle this badly, some not at all. Solutions: Allowing the view to auto scroll to the input area (mainly a GTK3 and Sugar task, significant amount of work already completed in 13.1.0); making sure the OSK is hidden when not needed (e.g. Activity should make sure to defocus input widgets when not essential, with auto refocus if physical keyboard is used and only one text input widget target as in Speak/Chat); Some Activity layout re-designs to optimise canvas for when OSK is visible (Speak/Chat are a good specific Activity cases for this). Regards, --Gary > On Tue, Jan 29, 2013 at 9:17 AM, Gary Martin > wrote: > On 28 Jan 2013, at 18:33, Gonzalo Odiard wrote: > > > > > > > On Mon, Jan 28, 2013 at 2:50 PM, Ajay Garg wrote: > > > > > > On Mon, Jan 28, 2013 at 11:01 PM, Paul Fox wrote: > > ajay wrote: > > > Hi all. > > > > > > A simple solution was found :) > > > > > > I hacked the "KP_Prior" and "KP_Next" keys, and now they are used for > > > making-window-smaller and restoring-original-window-size respectively :) > > > > so sugar takes over those keys? aren't those keys used by activities? > > they're certainly useful in a terminal -- page up and page down. > > > > Hmm.. Well a simple "grepping" showed that the "Read" activity is the only > > activity that explicitly makes use of the "KP_Home" and "KP_End" keys; but > > none seemed to make use of "KP_Prior" and "KP_Next". > > > > > > A simple grep is not good enough. Gtk already uses these keys, for example > > in a textview. > > > > I can't understand what you are trying to do. The user should press the key > > to enlarge/shrink the activity window? Does not look like a good solution. > > +1 > > OSK behaviour should be automatic, no user intervention (other than perhaps > some manual view scrolling when there is no active focus to get into view). > If we are missing cases (and we are currently), then these are bugs to be > fixed and/or features to be landed (often GTK3 related upstream targets, but > occasionally Sugar/Activity related patches). We made great progress in > 13.1.0, hopefully we can finish off this effort ready for 13.2.0. > > Regards, > --Gary > > > Gonzalo > > > > > > > > > > paul > > > > > > > > All thanks to > > >* /usr/share/X11/xkb/keycodes/evdev > > >* sugar/src/jarabe/view/keyhandler.py > > > > > > > > > > > > Just one thing I noticed when I tried to have the above keys take effect > > > ONLY in ebook-mode (via the "evtest --query" test), that when I ran this > > > again and again via the "suprocess" module, the XO-4 behaved very > > > erratically. However, when I made the keys take effect irrespective of > > the > > > test of ebook-mode, things worked cool. However, I will keep on looking > > > into the reason. > > > > > > > > > Thanks a ton to all :) > > > > > > > > > On Thu, Jan 24, 2013 at 10:45 PM, Paul Fox wrote: > > > > > > > gonzalo wrote: > > > > > Write does not know what is the ebook switch state, that logic is > > in the > > > > > osk. > > > > > > > > > > Looking in the wiki and sugar code, I could not find information > > about > > > > how > > > > > read the switch, > > > > > but in ticket http://dev.laptop.org/ticket/12326 found this: > > > > > > > > > > If you do: > > > > > > > > > > evtest --query /dev/input/event4 EV_SW SW_TABLET_MODE; echo $? > > > > > > > > > > > > > > > If the xo is in ebook mode returns 10, if not, returns 0. > > > > > > > > > > There are any official doc about the switches I am missing? There > > are a > > > > wa
Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK
On 28 Jan 2013, at 18:33, Gonzalo Odiard wrote:
>
>
> On Mon, Jan 28, 2013 at 2:50 PM, Ajay Garg wrote:
>
>
> On Mon, Jan 28, 2013 at 11:01 PM, Paul Fox wrote:
> ajay wrote:
> > Hi all.
> >
> > A simple solution was found :)
> >
> > I hacked the "KP_Prior" and "KP_Next" keys, and now they are used for
> > making-window-smaller and restoring-original-window-size respectively :)
>
> so sugar takes over those keys? aren't those keys used by activities?
> they're certainly useful in a terminal -- page up and page down.
>
> Hmm.. Well a simple "grepping" showed that the "Read" activity is the only
> activity that explicitly makes use of the "KP_Home" and "KP_End" keys; but
> none seemed to make use of "KP_Prior" and "KP_Next".
>
>
> A simple grep is not good enough. Gtk already uses these keys, for example in
> a textview.
>
> I can't understand what you are trying to do. The user should press the key
> to enlarge/shrink the activity window? Does not look like a good solution.
+1
OSK behaviour should be automatic, no user intervention (other than perhaps
some manual view scrolling when there is no active focus to get into view). If
we are missing cases (and we are currently), then these are bugs to be fixed
and/or features to be landed (often GTK3 related upstream targets, but
occasionally Sugar/Activity related patches). We made great progress in 13.1.0,
hopefully we can finish off this effort ready for 13.2.0.
Regards,
--Gary
> Gonzalo
>
>
>
>
> paul
>
> >
> > All thanks to
> >* /usr/share/X11/xkb/keycodes/evdev
> >* sugar/src/jarabe/view/keyhandler.py
> >
> >
> >
> > Just one thing I noticed when I tried to have the above keys take effect
> > ONLY in ebook-mode (via the "evtest --query" test), that when I ran this
> > again and again via the "suprocess" module, the XO-4 behaved very
> > erratically. However, when I made the keys take effect irrespective of the
> > test of ebook-mode, things worked cool. However, I will keep on looking
> > into the reason.
> >
> >
> > Thanks a ton to all :)
> >
> >
> > On Thu, Jan 24, 2013 at 10:45 PM, Paul Fox wrote:
> >
> > > gonzalo wrote:
> > > > Write does not know what is the ebook switch state, that logic is in
> the
> > > > osk.
> > > >
> > > > Looking in the wiki and sugar code, I could not find information about
> > > how
> > > > read the switch,
> > > > but in ticket http://dev.laptop.org/ticket/12326 found this:
> > > >
> > > > If you do:
> > > >
> > > > evtest --query /dev/input/event4 EV_SW SW_TABLET_MODE; echo $?
> > > >
> > > >
> > > > If the xo is in ebook mode returns 10, if not, returns 0.
> > > >
> > > > There are any official doc about the switches I am missing? There are
> a
> > > way
> > > > to catch a event when the switch is activated, using dbus or something
> > > > similar?
> > >
> > > if you open the device and read it, you'll get a stream of "struct
> > > input_event" structures (/usr/include/linux/input.h) representing
> > > opening and closing of the SW_TABLET_MODE switch. here's a C code
> > > snippet from olpc-switchd (part of powerd):
> > >
> > > void ebook_event()
> > > {
> > > struct input_event ev[1];
> > >
> > > if (read(ebk_fd, ev, sizeof(ev)) != sizeof(ev))
> > > die("bad read from ebook switch");
> > >
> > > dbg(3, "ebk: ev sec %d usec %d type %d code %d value %d",
> > > ev->time.tv_sec, ev->time.tv_usec,
> > > ev->type, ev->code, ev->value);
> > >
> > > if (ev->type == EV_SW && ev->code == SW_TABLET_MODE) {
> > > if (ev->value)
> > > send_event("ebookclose", round_secs(ev), ebk_device);
> > > else
> > > send_event("ebookopen", round_secs(ev), ebk_device);
> > > }
> > > }
> > >
> > >
> > > perhaps there's an evdev to dbus gateway of some sort, but i don't know
> > > about it, if so.
> > >
> > > the "evtest" commandline example, above, uses an ioctl on the input
> > > device to determine current state. here's snippet from the evtest
> source:
> > > (full source: git://anongit.freedesktop.org/evtest)
> > >
> > > static int query_device(const char *device, const struct query_mode
> > > *query_mode>
> > > {
> > > int fd;
> > > int r;
> > > unsigned long state[NBITS(query_mode->max)];
> > >
> > > fd = open(device, O_RDONLY);
> > > if (fd < 0) {
> > > perror("open");
> > > return EXIT_FAILURE;
> > > }
> > > memset(state, 0, sizeof(state));
> > > r = ioctl(fd, query_mode->rq, state);
> > > close(fd);
> > >
> > > if (r == -1) {
> > > perror("ioctl");
> > > return EXIT_FAILURE;
> > > }
> > >
> > > if (te
Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK
On 23 Jan 2013, at 15:29, Walter Bender wrote: > On Wed, Jan 23, 2013 at 1:20 AM, Ajay Garg wrote: >> Hi all. >> >> I wish to fix the bug, where some activities (Chat, Terminal, Speak for >> instance) are rendered unusable in the ebook-mode, due to the OSK covering >> the area of text-input. >> I have figured out a generic working solution for this - the idea is to >> minimize the activity windows when the OSK appears, and move back to the >> normal size when the OSK disappears. > > I thought we had a different approach under development: to scroll the > window up in the case of the text view being occluded by the OSK? Yes, there are patches in GTK3 and Sugar for this, though with some issues still needing worked through. One activity that we managed to push hard to get polished was Write, it needed to be a special case as it doesn't use normal gtk widgets. My (rough) understanding of the implementation is that GTK first looks for a scrolled view and tries to scroll it so that the cursor/focus rect is kept in view [1], if no scrolled view is found it scrolls the canvas [2]. [1] the Write behaviour here is not ideal as the abiword widget implementation for the text area didn't allow for extra padding at the bottom of the view, so the text being edited is hard up next to the OSK rather than with some extra space so the text selection handles stay visible. [2] I think there were patches in GTK3 Sugar so that the activity canvas area was automatically placed in a scroll view, so the toolbars are guaranteed to stay in view, but not sure if this landed. > This > should be doable for activities that have scrolling windows, such as > terminal and chat. Speak, which doesn't scroll could be refactored to > put the textview on the top instead of the bottom of the screen. (I > suspect that whatever solution we have will involve some intervention > in some activities.) Yes some intervention in activities will still be needed, and the first thing to do if you want any of this auto scrolling support is make sure your activity is ported to GTK3! ;) FOr activities like Speak I'd posted mockup images to a previous mail list thread showing how moving the text input area to the top of the UI would work well (the eyes will just peek over the top of the keyboard and the OSK can be hidden when the text is submitted for speaking). >> >> I have tested the re-sizing the windows; however, to make the fix work >> everywhere, I was thinking of the following algorithm :: > > What does resizing the window do? What other activities have you tested it on? Some activities will become quite unusable if auto shrunk, scrolling I think is better, we're lucky if the original developer planned for landscape and portrait aspect ratios... Regards, --Gary > >> >> a) >> Just before/after the OSK appears, make the current window smaller. >> >> b) >> Just after/before the OSK disappears, revert the current window to its >> original size (if not already). >> >> >> This requires a way to know when and how the appeareance/disappearance of >> the OSK is triggered. >> >> How can this be done? I am sure there must be some gobject-signal for this - >> I just can't seem to figure it out by manually browsing the code, since I >> don't personally have a XO4-Touch with me :-( >> >> >> >> Regards, >> >> Ajay Garg >> Dextrose Developer >> Activity Central: http://activitycentral.com >> ___ >> Sugar-devel mailing list >> sugar-de...@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> > > regards. > > -walter > -- > Walter Bender > Sugar Labs > http://www.sugarlabs.org > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Policy for non-responsive maintainers
On 10 Jan 2013, at 19:27, Walter Bender wrote: > On Thu, Jan 10, 2013 at 2:04 PM, Anish Mangal wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On Thursday 10 January 2013 01:52 PM, Walter Bender wrote: >>> On Thu, Jan 10, 2013 at 1:39 PM, Bernie Innocenti >>> wrote: Is this a good time to re-spin the discussion? Considering that it keeps coming up: >>> >>> +1 >>> >>> Let's get a policy defined and a means of execution. (On the ASLO >>> front, there are many of us who can help with the transfer of >>> management. Gitorious is another story... >>> >>> -walter bernie: Could you help me takeover maintainership >> of an inactive activity? lionaneesh-andro: ask alsroot, he maintains aslo * alsroot only maintains aslo, dirakx was taking care about aslo content lionaneesh-andro: gonzalo_odiard and garycmartin are the >> activity team coordinators. lionaneesh-andro: there's currently no written process for >> taking over an unmaintained activity. maybe ask them for permission first? >> >> Unless the original maintainer wants out, I'd call it co-maintainership >> rather than takeover-of-maintainership. >> >> I guess one version could be: >> * Request the original maintainer for co-maintainership >> >> * Wait for X amount of time >> >> * If he responds, great! - follow that >> ** If you don't agree with his response, you are free to branch off your >> own spin of the activity >> >> * If he doesn't respond, add the Requester as a co-maintainer. >> ** ASLO: add as author >> ** GIT: tag the current snapshot of the code (maybe clone or create a >> branch), and give commit access on mainline. > > That is pretty much what we had been discussing. The sticky bit is > that AFAIK, there is no easy way to transfer (or unilaterally add) > ownership to mainline on g.sl.o other than by running some scripts on > the server. Ah yes, I ran into this the other day... I'm in the process of making lionaneesh (Aneesh Dogra) a co-maintainer for Calculate (after all his great patching efforts). ALSO was a quick and easy addition (lionaneesh you have developer access to Calculate now if you want to make edits). Git.sl.org was not so fun... Apart from rather too well hidden UI for adding collaborators, I've only just realised that I only picked up commit rights from Reinier Heeres (Calculates original author) so don't have admin ability to give lionaneesh commit access. I've pinged Reinier off-list in the hopes that he'll either grant me admin permissions, or add lionaneesh himself, but it's been a while since I last worked with him. Regards, --Gary > I'm in favor of a short window, a few weeks. Others argue for a longer > window. Re git, it is not a big deal, because of the ability to clone. > Bit more of an issue for ASLO, since those are the bits consumed by > our user community. > > regards. > > -walter >> lionaneesh-andro: please, write to sugar-devel@ and cc me, >> alsroot, gonzalo and gary. bernie: okay. Thanks. On Wed, 2012-10-31 at 19:04 -0400, Bernie Innocenti wrote: > On Wed, 2012-10-31 at 14:27 -0300, Gonzalo Odiard wrote: >> If you are not in a hurry to get this discussed, >> I propose wait until we finish we 0.98 (one month aprox) >> Right now, all the people we want be involved in this discussion, >> are too busy (me too). > > There's no particular hurry. > > Actually, I brought up this particular issue just to make a more general > point: we should codify our existing practices in the wiki for the > benefit of new and existing contributors. Being swamped by an unclear > process can be quite frustrating for a volunteer who just wants to get > things done. > > >> About the summer young hackaton in Uruguay, I take your word. > > Glad to help, although it's unlikely that I'll be able to join in. > -- _ // Bernie Innocenti \X/ http://codewiz.org >>> >>> >>> >>> -- >>> Walter Bender >>> Sugar Labs >>> http://www.sugarlabs.org >>> ___ >>> Devel mailing list >>> Devel@lists.laptop.org >>> http://lists.laptop.org/listinfo/devel >> >> >> - -- >> Anish Mangal >> Sugar Labs >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.13 (GNU/Linux) >> Comment: Using GnuPG with undefined - http://www.enigmail.net/ >> >> iQEcBAEBAgAGBQJQ7xDBAAoJEBoxUdDHDZVpDKIIAIZyUbd6l8HiRofnk3W23azg >> NzJ08zBU+E+KnjgB3mw2jGcwqL8M+T1wXGTF5bvAqsFwwkcaxYShMGiMeBID7PvI >> 0jlpfERzMlzg4kLyo6K2yIuguvMfYUh7PI7yhfs4Z0+Ip3yBGzsnzdazsU7Hmobb >> uJreL+TMa81hw0wMdYRaFmYqjDXwy4osnfkXxompIb7Hk48wWGZ/S9+qfUmCInEt >> 200UEjPjCMPIFn2QSFVmKZ6/HRGIMNBKNEiHvO/TnZ43H9Cfv0k9dRxA90Obf3tF >> 2ucx4gEGB1cWro3TOJSAoDomqG03cHf+9AphLv6k1P/3XbMKvGJjYfp7LeprCMU= >> =BS48 >> -END PGP SIGNATURE- >> > > > > -- > Walter Bender > Sugar Labs > http://www.sugarlabs.org __
Re: 13.1.0 development build 19 released
Hi Daniel, On 16 Dec 2012, at 22:41, Daniel Drake wrote: > On Sun, Dec 16, 2012 at 8:58 PM, Gary Martin > wrote: >> Hi Daniel, >> >> On 16 Dec 2012, at 20:49, Anna wrote: >> >>> I verified the md5sum and tried a couple of different USB drives, but after >>> it finishes writing 31019o4.zd, the XO4 throws this out: >>> >>> Blocks/square: 2 Total blocks: 15911 0 36 34 >>> WARNING: The file said highest block 15911 but wrote only as high as block >>> 15903 >> >> Same here, I've tried to download it twice and flash 31019o4.zd on to two >> different XO-4 each time with the same error. > > But apart from this message the new installation works as normal, right? Yes it does boot, though the WARNING message doesn't instil much confidence that everything that should be there, is. I'm away from a high bandwidth connection for the rest of the week (traveling tomorrow), so I hope this os19 install holds up enough for me to continue testing, I'm taking a fallback copy of os18 just in case ;) Regards, --Gary > Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 13.1.0 development build 19 released
Hi Daniel, On 16 Dec 2012, at 20:49, Anna wrote: > I verified the md5sum and tried a couple of different USB drives, but after > it finishes writing 31019o4.zd, the XO4 throws this out: > > Blocks/square: 2 Total blocks: 15911 0 36 34 > WARNING: The file said highest block 15911 but wrote only as high as block > 15903 Same here, I've tried to download it twice and flash 31019o4.zd on to two different XO-4 each time with the same error. Regards, --Gary > Anna Schoolfield > Birmingham > > On Sun, Dec 16, 2012 at 10:40 AM, Daniel Drake wrote: > Hi, > > A new 13.1.0 development build is available. > > http://wiki.laptop.org/go/13.1.0 > http://build.laptop.org/13.1.0/os19 > > Changes: > > Measure v44 (#12398) > - Mic boost fixes on XO-1.75 (SL#4288) > - Sine wave mode fixed (SL#4254) > > XO-4 now has HDMI support in Linux (#12350). Other kernel fixes: > - Various wakeup sources work better (keyboard, mouse) > - Fixed 8787 wifi suspend/resume > > XO-4 firmware Q7B09 fixes enable-security (#12392) > > 1.8v UHS-I SD cards now work on XO-4 (#12385) > > Thanks for any testing and feedback. > > Daniel > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Renaming the Telescope activity to Scope
Hi Jv, On 23 Nov 2012, at 11:57, RJV wrote: > Hi, > > This looks like a great activity to me. I am unable to find what kind of > telescopes (in India) can be used and help to this effect on the downloads > page as a Readme would be very helpful. > > Has anybody used a physical telescope with this activity and what type? > Thanks for any response. Have a look at the learning resources pdf at: http://wiki.sugarlabs.org/go/Activities/Moon#Learning_Resources This covers research into a low cost monocular project that Telescope activity was originally aimed at. For Moon observing I have had fair success using a Brunton 10-30x21 monocular. It can be carefully held against the XO bezel over the camera, but that's quite hard work to keep everything still and pointed at the correct location ;) The above project uses a mounting bracket that attaches the monocular firmly to the XO so it is easier to aim. For imaging planets (e.g Jupiter/Saturn with moons) that monocular does not quite get enough light into the camera to show the moons, though I do have a light polluted sky here so you might manage better. You might also like this shot Sameer Verma tweeted recently: https://twitter.com/sameerverma/status/271428793476980736/photo/1 Regards, --Gary P.S. I have a collection of Moon test images I should really go upload to the wiki soon... > Jv > > > On Tue, Nov 20, 2012 at 12:08 PM, Simon Schampijer > wrote: > > > Am 20.11.2012 um 06:23 schrieb Martin Langhoff : > > > On Mon, Nov 19, 2012 at 11:58 PM, Chris Leonard > > wrote: > >> As I recall, this activity was already renamed once from xoscope after > >> it became clear it was colliding in name space with an oscilloscpe > >> activity. > > > > Renames are a pain in infrastructure, and in upgrade handling for users. > > > > I would say prefer to retain the current name until there's an > > overwhelming case for change. > > > > Agreed. A rename should be well thought through. If you do it, agreed with > what Chris said, please use a cerb. > > Thanks, >Simon > > > > cheers, > > > > > > > > m > > -- > > martin.langh...@gmail.com > > mar...@laptop.org -- Software Architect - OLPC > > - ask interesting questions > > - don't get distracted with shiny stuff - working code first > > - http://wiki.laptop.org/go/User:Martinlanghoff > > ___ > > Devel mailing list > > Devel@lists.laptop.org > > http://lists.laptop.org/listinfo/devel > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > > > > -- > Regards, > > Ravichandran Jv > http://ravichandranjv.blogspot.com > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Neonode low-level access
Hi Bert, On 8 Nov 2012, at 14:38, Bert Freudenberg wrote: > How can I get at low-level data from the XO-4's touch screen in Linux? I'm > thinking of the actual light levels of all the sensors around the edges. Unfortunately not at the moment, as far as I'm aware of (happy to be proven wrong). It was on the feature design list at an early stage of the dev cycle (so that we could implement things like a multi-touch piano) but time went to the primary use case and no driver work was done exposing this data, as far as I can tell. There are some parameters exposed under /sys/module/zforce/parameters, but nothing like the light level data. Perhaps something to push for in the next cycle? Regards, --Gary > Certain apps could benefit from this - e.g. many of Neonode's own impressive > demos could not be implemented using only the X11 events I get in Sugar. > > - Bert - > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Maliit ticket location
Hi Daniel, On 5 Nov 2012, at 19:29, Daniel Drake wrote: > Hi, > > We are currently a little disorganised in our maliit ticket filing - > we have some tickets on SL trac, and some on OLPC trac. > > This isn't really a problem for us, but it is for outsiders; and > Michael (mikhas) from maliit upstream is interested in keeping an eye > on things. (We should definitely take him up on that offer, since he's > so helpful.) > > So, I propose that we use the dev.laptop.org trac for all maliit > tickets from this point. There is a "keyboards - on screen" component > already. > > This would affect tickets that relate to our work and troubles with > Maliit directly (e.g. SL#4051), but not those that relate to > challenges with Sugar-specific integration items (e.g. SL#4150, > SL#3887, SL#4106) > > Any objections? If not I will move the 3-4 maliit tickets from SL to > OLPC and we'll go from there. Good with me, though note I'm the default owner of that dev.lt.org component, so if it is more system related issue than user interaction related, you should assign the tickets someone with system skills. Regards, --Gary > Thanks > Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 13.1.0 development build 9 released
On 4 Nov 2012, at 11:08, Peter Robinson wrote: > A new 13.1.0 development build is available: > > http://build.laptop.org/13.1.0/os9 > http://wiki.laptop.org/go/13.1.0 Thanks Peter. > - The some activity updates > - XO-4 kernel work for 8787/mwifiex wireless, touchscreen improvement, and I > believe some suspend/resume work > > Thanks for any testing and feedback! For those wanting to test the available OSK language layouts and the new language cycle key (the map key, bottom left), this build is still only enabling a single layout language. To enable more, see the example at: http://wiki.sugarlabs.org/go/User_talk:Garycmartin/Maliit_Layouts Hopefully we'll have several languages enabled by default for the next build. Regards, --Gary > Note there currently isn't x86 builds. These should appear at some point > soonish with luck! > ___ > olpc mailing list > o...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/olpc ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Opportunities to slim down 13.1.0 build file cruft
Hi Peter, On 17 Oct 2012, at 19:40, Peter Robinson wrote: > On Wed, Oct 17, 2012 at 7:17 PM, Gary C Martin > wrote: >> Hi folks, >> >> I was just having a dig around in 13.1.0 build 6 for the XO-4 (using >> GrandPerspective), and noticed that we are still including libgweather and >> its 88Mb worth of Locations.xml files. I know this came up in a previous >> release cycle, but just want to check again that we can't save this valuable >> space. > > Try "yum remove libgweather" and see what it wants to remove. Thanks good idea, yes it wanted to remove: libgweather armv7hl 3.6.0-1.fc18@fedora/$releasever 88 M evolution-data-server armv7hl 3.6.0-1.fc18 @fedora_updates_testing/$releasever14 M gnome-panel armv7hl 3.6.0-1.fc18@fedora/$releasever 8.8 M Installed size: 111 M Regards, --Gary > I've made some improvements surrounding other bits and I'm aware of some > more but I've not had the time to pursue upstream. > > Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 13.1.0 build 6 released
On 14 Oct 2012, at 07:34, Gonzalo Odiard wrote: > Can you see any error in the file /home/olpc/.sugar/default/logs/shell.log? Same here, posted this ticket yesterday: http://bugs.sugarlabs.org/ticket/4031 --Gary > Gonzalo > > On Sun, Oct 14, 2012 at 12:36 AM, Hal Murray wrote: > > #12133 13.1.0 does not connect to a wireless AP > > My setup is XO-1 and Linksys WRT54GL AP that needs a password. > > I can't connect through Sugar. It doesn't ask me for a password. The WiFi > LED is off. (It blinks occasionally, and sometimes new APs appear shortly > after the blinks.) > > I can connect through Gnome. After that Sugar can connect automatically on > reboot using the saved password. > > OS 5 did the same thing. OS 4 worked as I expected. > > > -- > These are my opinions. I hate spam. > > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] NPR story on OLPC in Peru
On 13 Oct 2012, at 20:10, Alexandro Colorado wrote: > On 10/13/12, Chris Leonard wrote: >> 2012/10/13 Alexandro Colorado : >> Los trabajos que venimos realizando en forma coordinada entre SugarLabs + SomosAzucar + Ministerio de educación es en brindar una plataforma capaz de mantener a la comunidad educativa CONECTADA, con o sin internet, y esto por que nuestra realidad así lo requiere. >>> >>> Is there any 'intermediary projects' or setups that allow people to >>> keep connected? Giving 2 minute thought, I would think that a RAID >>> SERVER on the school could provide a school with the lastest >>> information sources like wikipedia, mailing list archieves, ebooks, >>> ezines, website pull downs, and other required service that people >>> could order to be delivered at the school. Then switch the info >>> harddisk from the general system harddisk. >> >> Yes, you should read up on Sugar Network which is part of the >> SomosAxucar effort Hernan references. >> >> http://wiki.sugarlabs.org/go/Sugar_Network >> >> You should also know that off-line Wikipedia versions are available in >> a variety of languages (English, Spanish, French, Polish, Quechua, >> more easily created). >> >> cjl >> > > Ah Links, thanks. http://activities.sugarlabs.org/en-US/sugar/search?q=wikipedia&cat=1%2C104 Regards, --Gary > -- > Alexandro Colorado > PPMC Apache OpenOffice > http://es.openoffice.org > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing Summary - Auckland 13 October 2012
Hi Tabitha, On 13 Oct 2012, at 08:52, Tabitha Roder wrote: > Auckland Testing Summary 13 October 2012 > Who: Alana, Fabiana, John, Oliver, Tabitha and Tom > > Rosella: XO-1.5 One Education OS 1.2 (build au248), Firmware Q3C09 > with first language Maori and second language English (Great Britain) > > Moon failed to start, but works if you change the language back to > English, log file attached for failed to start case Thanks for testing and the log files! Looks like the Moon Maori pootle string has a typo in: ""Surface Visibility:\n%.0f%% (estimated)\n\n"" ValueError: unsupported format character 'O' (0x4f) at index 16 So that error looks like the translator has typed in a O (capital letter O) instead of a 0 (number zero). > Firefox froze when you press the stop button > > Tam Tam Mini was mostly translated but the category names (percussion, > animal etc for the instruments) were not > > Record photos and videos worked fine > > Clock does not speak the time but otherwise works. Changing to English > fixes the talking clock. Note that the Days of the week were not > translated, but everything else was. Log attached. Looks like the translator has removed all the strings for the rules for generating the time in text, the error in the log suggest it found no rules. If you enable the toolbar button "Display time in full letters", do you see the time printed in Maori (or the default english)? My guess is you'll see noting, or worse will crash. > Screencast encoding was very slow. No translation. Saves to journal. > Attempting to play from the journal launches jukebox but the video > doesn't play > > Physics works Fab, I'm glad one of mine worked! :) BTW your cogs feature suggestion didn't make it into this release cycle, and we're frozen for new features now :( Maybe I'll get back to it once the XO-4 bug hunting/fixing calms down in a month or so. Regards, --Gary > Numbers works > > Speak has an english accent and doesn't understand the macrons. The > robot greeting "I'm a robot alice..." has been translated but the > robot converses in english otherwise. > > > > Ivy: XO-1.5 One Education OS 1.2 (build au248), Firmware Q3C07 in English > Maze, Memorize, Speak, Moon, Clock, Physics, Arithmetic, Implode, Tam > Tam Mini all worked > > Turtle Machine: Three people (including a neuroscientist and a primary > school teacher and a teacher of teachers) all got stuck at level 9 and > couldn't get past it. Our school teacher suggests that once you > complete a shape you should get told the name but we're not sure what > to do when the shapes don't really have names. We also think there > should be some sort of hint or help facility. It would also be good to > skip a level if you get stuck on it but maybe this is cheating. You > don't actually have to do very much for the first levels because all > you have to do is click on the number and it auto-advances to the > correct value (it jumps values, 1,2,3,4,5,6,8,12,30) and choose one > angle less than what is already selected. Perhaps these should be > type-in boxes where you have to choose the right angle? Eventually (7 > hours later on revisiting the activity) we found there was a library > of shapes created that we could reuse. > > Both One Education builds ask for the users age when you first start > the laptop but you cannot enter an age with the keyboard, you have to > use the clickers or the arrow keys. > > > XO-1.75 running One Education OS 1.2 (build au48) > Moon, Implode, Memorize, Numbers, Slider Puzzle, Dimensions, Clock all work > > Jigsaw was unusably slow when dragging pieces > > Screencast stops recording after one second and doesn't save anything > in the journal (but it says it does) > > The vmeta drivers won't load on this XO as they are for a different > architecture. Is there any other way to get hardware accelerated video > playback working? > > > XO-4 running 13.1.0 for XO-1.4 (build 5), firmware Q7B01 > Startup sound has a raspy quality, pressing reasonably hard on the > right hand speaker grille seems to make it much better. > > This laptop didn't shut down properly (perhaps because the shutdown > screen isn't always correctly understood) and stayed on in the bag. It > doesn't seem to have suffered from this. > > Touchscreen has an offset which makes using it quite difficult. Is > there any further protection for the screen planned? It doesn't feel > as robust to impact as any tablet I've used, and the matt finish looks > like it might collect scratches. > > There is a slight misalignment between the game key holes and the game > keys. This doesn't seem to stop them working. The front panel finish > is glossy with faint tool marks, while the finish on the rest of the > laptop is textured. > > The rotate button doesn't do anything > > Write works > > Get Books works but doesn't show icon as being coloured after you use it > > Read works > > Wikipedia didn't load any pages, it looked like it star
Re: [Techteam] 13.1.0 devel build 5 released, for the XO-1, XO-1.5, XO-1.75 and XO-4
Hi Peter, On 8 Oct 2012, at 15:09, Peter Robinson wrote: > On Mon, Oct 8, 2012 at 1:54 PM, Chris Leonard > wrote: >> On Mon, Oct 8, 2012 at 8:04 AM, Gary Martin >> wrote: >> >>>> Are the layouts each in a distinct set of files? If so we could possibly >>>> split out layouts to standalone packages to make it easy to add extras at >>>> a later date. >>> >>> Yes the language layouts are a distinct set of XML files in one directory. >>> They can be edited live on running system, so it's not like they really >>> need to be part of maliit-plugins build compilation. >> >> If the OLPC OS build creators (e.g. dsd) do not plan to include all of >> these files in "stock" releases, then we should definitely look at >> incorporating them into language packs installs. > > At the moment all layouts are packaged as part of the maliit-plugins package > >> Just like with L10n MO files there may be good reasons (mostly size in >> image) not to include them all, but in a such a case we definitely >> want to make them easy to find and easy to install, without much >> technical knowledge, or even knowledge that they even exist. > > The layouts are xml files and hence very small is size so the easiest > way to install them would be to have them there by default. > > My question to Gary about the layouts was more about how hard it would > be to package them up separately so it's easy to add new layouts post > release of a release. It's quicker to add a single package with a > single layout than having to QA an entire release again. How would you like them? I could just send you a zip of the files, though I guess you're after something a little more bundled, let me know ;) So this certainly seems a good way to go, though note I'm probably going to need at least one more pass at the style changes for this cycle (unfortunately key sizes are hardcoded in the style and I need to tweak there every now and againg to get a layout to work), which is a different set of files in maliit-plugins. These styles can also safely make their way up stream to Michael, leaving us just with our new language layouts to apply to builds. Regards, --Gary >> With a little tweaking of the language pack generating script, >> >> http://git.sugarlabs.org/pootle-helpers/mainline/trees/master/langpackgen >> >> the language packs could serve that purpose. > > I'm sure there's a number of ways to skin that cat :-) > > Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] 13.1.0 devel build 5 released, for the XO-1, XO-1.5, XO-1.75 and XO-4
Hi Peter, On 8 Oct 2012, at 07:02, Peter Robinson wrote: > > On 8 Oct 2012 00:41, "Gary Martin" wrote: > > > > On 7 Oct 2012, at 23:56, Peter Robinson wrote: > > > > > > > > On 7 Oct 2012 23:17, "Martin Langhoff" wrote: > > > > > > > > On Sun, Oct 7, 2012 at 5:22 PM, Peter Robinson > > > > wrote: > > > > > #12082 Maliit on-screen keyboard > > > > > > > > Yay!!! Is the evdev trickery all hooked up? Does ebook mode DTRT? > > > > > > Not yet, all the layouts are in and gtk2 works now > > > > Not quite all the layouts, but the vast majority are done in both landscape > > and portrait. I have Türkçe, Українська, Việt, and 1 usable (out of 3 due > > to the need of the others for a proprietary glyph composition engine) > > Chinese keyboards still to do, and some general bug fixes on several > > extended keys I spotted while testing. Expect an updated set of similar > > patches before build lockdown. There is also still the hanging question > > with regard for the need for additional keyboards for existing or potential > > deployments. Armenia has been raised as one possible extra, but not yet > > confirmed. Perhaps once XO-4's start to land and folks play with the OSK > > we'll see some formal requests. > > > > Are the layouts each in a distinct set of files? If so we could possibly > split out layouts to standalone packages to make it easy to add extras at a > later date. Yes the language layouts are a distinct set of XML files in one directory. They can be edited live on running system, so it's not like they really need to be part of maliit-plugins build compilation. Regards, --Gary > Peter > > > Regards, > > --Gary > > > > > > cheers, > > > > > > > > > > > > > > > > > > > > m > > > > -- > > > > mar...@laptop.org -- Software Architect - OLPC > > > > - ask interesting questions > > > > - don't get distracted with shiny stuff - working code first > > > > - http://wiki.laptop.org/go/User:Martinlanghoff > > > ___ > > > olpc mailing list > > > o...@lists.fedoraproject.org > > > https://admin.fedoraproject.org/mailman/listinfo/olpc > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] 13.1.0 devel build 5 released, for the XO-1, XO-1.5, XO-1.75 and XO-4
On 7 Oct 2012, at 23:56, Peter Robinson wrote: > > On 7 Oct 2012 23:17, "Martin Langhoff" wrote: > > > > On Sun, Oct 7, 2012 at 5:22 PM, Peter Robinson wrote: > > > #12082 Maliit on-screen keyboard > > > > Yay!!! Is the evdev trickery all hooked up? Does ebook mode DTRT? > > Not yet, all the layouts are in and gtk2 works now Not quite all the layouts, but the vast majority are done in both landscape and portrait. I have Türkçe, Українська, Việt, and 1 usable (out of 3 due to the need of the others for a proprietary glyph composition engine) Chinese keyboards still to do, and some general bug fixes on several extended keys I spotted while testing. Expect an updated set of similar patches before build lockdown. There is also still the hanging question with regard for the need for additional keyboards for existing or potential deployments. Armenia has been raised as one possible extra, but not yet confirmed. Perhaps once XO-4's start to land and folks play with the OSK we'll see some formal requests. Regards, --Gary > > cheers, > > > > > > > > > > m > > -- > > mar...@laptop.org -- Software Architect - OLPC > > - ask interesting questions > > - don't get distracted with shiny stuff - working code first > > - http://wiki.laptop.org/go/User:Martinlanghoff > ___ > olpc mailing list > o...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/olpc ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: F18/os4 on XO-1 [Devel Digest, Vol 79, Issue 37]
Hi Gonzalo, On 1 Oct 2012, at 06:55, Gonzalo Odiard wrote: > Thanks. This info help us identify if is related to platform or not, > and have a better clue about what can be wrong. > This cycle have _a_lot_ of changes, test is welcomed. I hit this a couple of days ago and happened to have a remote ssh session. The below happened each time I tried to record video. Photo taking worked fine. I tried several times and rebooted between tests. Was distracted by other tasks and forgot to ticket it. I was on the XO-1.75 (Touch) with 13.1 build 3, Record version 96. The Sugar does still kind'a keep going after this, it's not a complete lock up, but I needed to manually kill Record from ssh and things were a little glitchy after that (so I did in the end clean reboot). Regards, --Gary Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:15 ... kernel:[70732.506958] Internal error: Oops: 17 [#1] PREEMPT Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:15 ... kernel:[70732.594780] Process Record <90142da (pid: 11951, stack limit = 0xd4cd62f8) Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.601604] Stack: (0xd4cd7bcc to 0xd4cd8000) Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.605933] 7bc0:0001 0021 c003a148 1000 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.614062] 7be0: c04de610 c003a84c 1000 d44e89c0 e0bb 00026000 d4baa400 d4baa690 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.622184] 7c00: 00d0 0001 0080 00d0 d4baa690 0130 c04de610 0001 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.630310] 7c20: d4cd7c98 d463d640 d4baa408 c003a924 0247 0094 1000 d44e89c0 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.638435] 7c40: d4cd7c98 d463d408 d4baa400 d4cd7e58 d4baa400 bf016fe4 bf016fb4 d463d640 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.646558] 7c60: bf001488 d463d700 c0030d9c d4baa400 d463d640 d463d700 0001 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.654682] 7c80: d463d640 0001 0002 0002 0001 00025800 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.662804] 7ca0: d463d788 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.670931] 7cc0: d463d408 d4cd7e58 d463d408 d46c6260 0001 c0145608 bf016e70 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.679057] 7ce0: d4cd7e58 d463d490 bf0184cc c0261164 d4cd7d24 c00417c4 d4cd6000 d4bec840 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.687180] 7d00: d4bec840 d4bec840 d4bec840 c04e01d0 4a85 2726f40f 0185 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.695304] 7d20: d4575240 4054 c002bca0 c00385a4 c0067fb4 d4cd6000 d4bec840 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.703429] 7d40: d4bec840 d4cd6000 c04e01d0 c00681d8 0002 d525 d525001c Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.711553] 7d60: d4cd6000 d437bb40 d437bb40 d4bec840 d4cd7e04 c039cf08 008d d4448e20 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.719677] 7d80: 00020002 d4b19560 d254e3e4 c009b300 d4b19560 d254e3e4 003f d52dd4f0 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.727802] 7da0: d463f968 c009d754 0001 d5b2eca0 0041 d4cd7df0 d254e330 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.735926] 7dc0: d4cd7dd4 0deac18f deac c00c0a28 c0572000 c003b610 c072f580 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.744050] 7de0: c00b2640 d52dd4f0 003f 4353c000 c072f580 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.752174] 7e00: 000739c2 d463f968 d437bb40 003f 0001 d4cd6000 009894b2 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.760298] 7e20: 2b93e181 c0145608 d4cd7e58 bedb1484 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.768422] 7e40: d46c6260 c025f170 040f 0003 c025f344 0002 0001 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.776545] 7e60: 0001 040f 000f 00989680 0001 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.784671] 7e80: c0066cf0 00989680 4054 4054 4054 afbfb699 Message from syslogd@xo-6d-5e-7c at Sep 28 18:03:16 ... kernel:[70732.792796] 7ea0: 4054 4054 afbfed49 4054 c0070710 afbfed49 4054 Message f
Re: 13.1.0 feature freeze reminder
Hi Walter, On 28 Sep 2012, at 01:18, Walter Bender wrote: > On Thu, Sep 27, 2012 at 5:46 PM, Daniel Drake wrote: >> Hi, >> >> Just a quick reminder that we move to bug-fixes-only for 13.1.0 on >> October 11th which is exactly 2 weeks from now. > > I have a new feature I would like to propose. maintain a list of > launch times in the metadata. This will be useful for datastore > analysis in the client. (The sugar-stats package [1] developed and > maintained by alsroot can also be used to capture these data, but I > posit that having these data as part of the datastore will facilitate > data visualizations within Sugar itself.) > > The attached patch, also shown inline here to > sugar-toolkit/src/sugar/activity/activity.py adds a timestamp each > time an activity is launched. These timestamps can be used to answer > questions such as how often an activity has been used? in school or at > home, et al. that are being asked by teachers and also used to provide > feedback to the child as to when and where they are working. +1 for the goal of more auto captured Journal metadata, this has come up for discussion numerous times so would be good to finally make at least this one step improvement (and will nudge me towards making an achievements Activity for Journal visualisation in Sugar). I'll leave to others to review your implementation. Regards, --Gary > --- a/activity.py > +++ b/activity.py > > @@ -324,6 +324,14 @@ class Activity(Window, gtk.Container): > if 'share-scope' in self._jobject.metadata: > share_scope = self._jobject.metadata['share-scope'] > > +if 'launch-times' in self._jobject.metadata: > +self._jobject.metadata['launch-times'] = '%s, %d' % ( > +self._jobject.metadata['launch-times'], > +int(time.time())) > +else: > +self._jobject.metadata['launch-times'] = \ > +str(int(time.time())) > + > self.shared_activity = None > self._join_id = None > > @@ -376,6 +384,7 @@ class Activity(Window, gtk.Container): > jobject.metadata['preview'] = '' > jobject.metadata['share-scope'] = SCOPE_PRIVATE > jobject.metadata['icon-color'] = icon_color > +jobject.metadata['launch-times'] = str(int(time.time())) > jobject.file_path = '' > > # FIXME: We should be able to get an ID synchronously from the DS, > > >> http://wiki.laptop.org/go/13.1.0/Release_plan >> >> Daniel >> ___ >> Devel mailing list >> Devel@lists.laptop.org >> http://lists.laptop.org/listinfo/devel > > > -walter > > -- > Walter Bender > Sugar Labs > http://www.sugarlabs.org > > > [1] http://git.sugarlabs.org/server/client/trees/master > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Testing] Testing Summary, Auckland 14 July 2012
Hi Tom, On 15 Jul 2012, at 12:27, Tom Parker wrote: > Testing Summary, Auckland 14 July 2012 > Who: Brenda, Fabiana, John, Nevyn, Tom > > We tested 12.1.0 build 18 on XO-1.5 and XO-1.75 > > Nolan (XO-1.75): > paint - seems ok. > Physics: get the strange behaviour at the top of the canvas where things > don’t show over a band on the top (reported before) Yes we have been investigating this fir some weeks now, unfortunately seems to be a regression in the hardware graphics driver that is not going to be fixed in this cycle. My best guess is that pygame double buffering is no longer supported by the driver and your observing a vsync related frame redraw that should be happening in the hidden buffer. The blank band will grow as the scene gets more complicated :( Other pygame activities will also be affected (I've seen one mention of someone seeing something similar in Maze). I've looked to see if there's anything I can do to improve Physics at the activity level, but haven't found any options yet. Regards, --Gary > Record: patchy movie recording on high quality from the onset, whereas my > feeling is that previously it would record ok for a while before this > happened. > Turtle art: Something odd - seems like I am building the blocks and the > programme starts running without me asking for it. > Chart Activity: Opened a very big file from measure - it kept on going > forever. I cannot find a way to tell it to stop reading the file. I tried to > stop the activity but it looks like it will not stop until it finishes > reading. After a bit the menus at the top of the screen were no longer > visible (as if it was trying to stop) but I can see the data field and the > chart field, which is still bringing in and displaying/plotting the data > > Moa: > Managed to successfully open google doc, still can’t create a google doc. > > Open as a new tab does not work on a google search > > vmeta works in whaawmp, videos can be obtained with youtube-dl -f 18. > > fototoon is awesome and works great > > Distance still doesn’t work at all on XO-1.75, this activity should be > removed if it can’t be fixed. > > Jacob: > Measure with resistance sensor, we find that the trace drops off the bottom > of the screen at 6kΩ. It seems that the gain slider is a position control, > not a gain control as in audio mode, this doesn’t seem to be explained in the > documentation on wiki.sl.o. The position control can be used to position zero > on the screen. > > Shorting the input yields -10Ω which is a little surprising as negative > resistors are rare beasties. > > Saving data with measure seems strange. We always get some negative > resistances even when we ensure that we did not measure any negative > resistance. > > Write works with pictures, colors, writing, sizes. > > Rosella: > All the text is still tiny as reported previously. Sorry, we haven’t taken it > apart as recommended a while ago. Is it possible to do an fs-update with an > external drive as the target or otherwise copy the operating system to an > external drive? > > We had a strange crash on shutdown. The laptop ended up sleeping, and when > you press the power button the power light comes on for about 3 seconds and > then goes back to sleeping. Keyboard or mouse entry does the same thing with > the power light. > > Could Record display the preview as a mirror image like most webcams? This > makes it more intuitive when moving your head. > > ___ > Testing mailing list > test...@lists.laptop.org > http://lists.laptop.org/listinfo/testing ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing Summary, Auckland - 23 June 2012
On 14 Jul 2012, at 23:52, Daniel Drake wrote: > On Sat, Jul 14, 2012 at 2:43 AM, Tom Parker wrote: >> Not quite 1 month late, I present for your eduction: >> >> Auckland Testing Summary 23/06/12 >> Who - John, Fabiana, Tabitha, Tom >> >> We tested Build 12.1.0 RC 2 (build 15) on XO-1.5 and XO-1.75. >> >> Rosella: Geeze, need new glasses just to see what is going on! Tiny! I find >> those kissy lips at the bottom of the frame really disturbing. Uploaded a >> paint file fine to gdocs. Can open the image file and text file from google >> docs on browser with no issue. Record - Well that is a very tiny window! >> Created video on record and opened on jukebox, All good. Physics - Would be >> useful to have an ‘erase all’ button. Takes me forever to clear the canvas >> and of course can’t clear those outside of the screen which slow the >> activity significantly. But I don’t seem to get that odd behaviour at the >> top of the canvas reported in previous weeks. Turtle art seems ok. Measure - >> both channels are active - seems all right. Labryinth seems ok saved to pdf >> and png and could open -with read and image viewer - did not try inserting >> stuff. Can’t shut down through right click > > Thanks for testing. > I posted some tips for how to diagnose the font size issue on this > laptop in response to a previous report. > Anyway, I suspect we now know what it is: #12003. > > Please post the output of: cat /proc/device-tree/banner-name > > > Physics 'remove all' suggestion & horrible lips: CCing Gary. Thanks Daniel, yes this is the 2nd request for a delete all feature in Physics. It's an easy code addition (ignoring that we would need to redesign the primary toolbars to fit in an additional icon), but a dangerous one without an undo feature, allowing you to wipe everything with a single toolbar click is asking for trouble... Best we could do given that adding undo to Physics is not an easy task is to have the feature raise a confirmation alert. Note that the Erase tool works like an eraser, you can scrub over the canvas with a 'line of death' removing many objects all in one quick scribble. Thanks for the feedback, I'm hoping to get back to Physics feature work in the next cycle. Regards, --Gary > Shutdown issue: at which point did it hang, or what was the exact > response of the system? Build 18 fixes an issue where it could hang on > shutdown at the "warning screen". > >> Hoiho >> Memorize: >> Start as new. Change game to 6x6. Stop. Start from journal. Expect 6x6 game >> get 4x4 game. > > Thanks, filed as http://bugs.sugarlabs.org/ticket/3754 > >> ivy: >> Browse, works but open in new window from the right click menu does nothing. > > We need to fix this menu. This is http://bugs.sugarlabs.org/ticket/3455 > >> Browse’s cutnpaste continues to be strange, with it not effecting the url >> bar. You have to use the right click menu to do that > > Can you explain what you mean by this? > >> totem does not play .mp4, failing with a segfault. > > Is this file available somewhere? > >> Wikipedia-en has a lot of html source code visible. The page for Eduction >> contains a below every heading. > > Thanks, filed as http://bugs.sugarlabs.org/ticket/3755 > > Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Python bindings based on Phonegap?
On 21 Jun 2012, at 20:50, Lester Leong wrote: > Does anyone know if there are Python bindings based off the Phonegap > API, with similar method calls, etc.? > > I'm developing an HTML5/Javascript activity that I would like to > eventually port to Android and other mobile platforms. Having a set of > Phonegap-like Python bindings for Sugar would help considerably. Yes, or even a minimal example web based activity that folks could clone and extend. FWIW This has come up numerous times over the last few years but I see to remember Gecko and hulahoop api compatibility overhead issues stalled most work. Now that we've moved to webkit (only just in the latest dev builds) this is worth revisiting. FWIW2 Browse [1] and (I think) Help [2] are both ported over to webkit, a good place to look to see what the code is like. Regards, --Gary [1] http://git.sugarlabs.org/browse [2] http://git.sugarlabs.org/help > Lester > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Testing] Testing Summary, Auckland - 16 June 2012
Hi Tom, On 16 Jun 2012, at 12:56, Tom Parker wrote: > Kiwi (an XO-1.75): > Memorise seems ok. > Physics: still has that odd behaviour at the top of the canvas that was > reported i think two weeks ago. Rosella (an XO-1.5 does not seem to have the > same issue in physics as kiwi. Thanks for noting this again, I've had no luck reproducing this here on an XO 1.75, any chance of a screen shot, or a little more description to help me try and track it down? Regards, --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH powerd] audio inhibit support
Hi Walter, You might also want to take a quick look at what Physics is doing, might not be pretty, but I remember needing to catch more than one event/test to make sure the simulation was suspended correctly across a range of past build releases, perhaps also a case where switching to a desktop view vs. another activity needed to watch for a different event. Regards, --Gary On May 21, 2012 1:44 PM, "Walter Bender" wrote: > On Mon, May 21, 2012 at 6:44 AM, Sascha Silbe > wrote: > > Walter Bender writes: > > > >> On Sun, May 20, 2012 at 7:00 PM, Sascha Silbe < > si...@activitycentral.com> wrote: > > [...] > >>> - Turtle Art v138 > >> > >> For TA, this is by design: if you are recording data, you want to keep > >> recording even when in the background. Same goes for Measure. > > > > Ah, should have noted exactly what I tested for each Activity. For > > Turtle Art (wasn't that Turtle Blocks at some time? still confused) that > > was only playback, not recording. > > > >> For playback it should release the device. > > > > I agree, for Turtle Art it will usually be the right thing to do when > > switching to a different Activity. Jukebox OTOH would be a good example > > of an Activity that should continue playback even in the background (but > > close the device as soon as it's finished playing). > > > > Sascha > > > > -- > > http://sascha.silbe.org/ > > http://www.infra-silbe.de/ > > I see that Clock is using notify::active and then checking > self.props.active. In Turtle Blocks, I had been using > visibility-notify-event. Is the former recommended? More reliable? > > regards. > > -walter > > -- > Walter Bender > Sugar Labs > http://www.sugarlabs.org > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 12.1.0 devel build 5 released, for the XO-1, XO-1.5 and XO-1.75
On 26 Mar 2012, at 17:30, Gary Martin wrote: > On 26 Mar 2012, at 16:24, Daniel Drake wrote: > >> On Sat, Mar 24, 2012 at 4:56 PM, Peter Robinson wrote: >>> The release is our first combined 12.1.0 / Fedora 17 release, such a >>> small release but represents so much time by so many people in both >>> OLPC and Fedora in the ARM side of things to get a "hardfp" ARM >>> release. >> >> Thanks everyone for all the feedback so far! > > Just noticed that on the XO-1, the laptop power button doesn't trigger the > usual sleep/shutdown full screen UI. Works fine on the XO-1.75. Sorry, just one more heads-up, while I bump into it (please shout if there's more appropriate channel than this mail thread): The XO-1.75 test unit I have here with the touch screen layer is no longer responding to screen touch input with the 12.1.0 dev build 5, it works fine on 11.3.1 build 31. Have been looking into the on-screen keyboard overlay, added to GNOME 3.2 [1] (originally a GSoC 2011 project by Nohemi Fernandez, mentored by Dan Winship), to see if it's an option we can adapt for Sugar. Regards, --Gary [1] http://library.gnome.org/misc/release-notes/3.2/index.html.en#rna11y > Regards, > --Gary > >> We've put tickets in trac for the biggest issues reported here and >> will now be working to resolve all the problems. Stay tuned for new >> builds! >> >> Daniel >> ___ >> olpc mailing list >> o...@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/olpc ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 12.1.0 devel build 5 released, for the XO-1, XO-1.5 and XO-1.75
On 26 Mar 2012, at 16:24, Daniel Drake wrote: > On Sat, Mar 24, 2012 at 4:56 PM, Peter Robinson wrote: >> The release is our first combined 12.1.0 / Fedora 17 release, such a >> small release but represents so much time by so many people in both >> OLPC and Fedora in the ARM side of things to get a "hardfp" ARM >> release. > > Thanks everyone for all the feedback so far! Just noticed that on the XO-1, the laptop power button doesn't trigger the usual sleep/shutdown full screen UI. Works fine on the XO-1.75. Regards, --Gary > We've put tickets in trac for the biggest issues reported here and > will now be working to resolve all the problems. Stay tuned for new > builds! > > Daniel > ___ > olpc mailing list > o...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/olpc ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] 12.1.0 devel build 5 released, for the XO-1, XO-1.5 and XO-1.75
On 25 Mar 2012, at 19:40, Simon Schampijer wrote: > On 03/25/2012 07:59 PM, Chris Ball wrote: >> Hi, >> >> On Sun, Mar 25 2012, Simon Schampijer wrote: >>> I have filed the Browse related tickets 11716, 11718 testing on the >>> XO-1.5. My 1.75 does boot until the naming screen but I can not use >>> the trackpad or the keyboard. This is a 1.75 1B1 with 4GB. >> >> Keyboard/trackpad both work here on 1.75 1C2 8GB. Constant libertas >> timeouts, though. >> >> - Chris. > > Yeah, flashed now another 1.75 machine (1C2 4GB) and the first boot when I > did not sit next to the machine it came up the same as my 1B1 with a non > usable keyboard and trackpad. I rebooted and directly entered a name and > could use than the machine. Successfully flashed both an XO-1 with update-nand [1] and an XO-1.75 with fs-update. > Things I came across from a first quick look: > - the trackpad was not as good responsible Yes, on the XO-1.75 after disabling powerd to prevent the lockups at idle suspend, the track pad feels a little spongy/laggy but it might just be different accel. settings, not sure? The XO-1 (original trackpad) is notably worse, if you trace circles the cursor stops from time to time along the path. Also had the cursor stall completely twice and then slowly stutter, perfectly vertically, every few seconds down the screen; then fluttered randomly vertically very fast and disappeared (keyboard and UI still worked OK). > - the neighborhood view had no APs listed Yes same here on the XO1.75. It also fails to create or connect to an ad-hoc network, the three icons are shown in neighbourhood but have no 'Connect' ability. The neighbourhood view on the XO-1 is showing AP's just fine, connected to my AP without issue. Regards, --Gary [1] Spent a long time looking for the wiki page Daniel wrote that described the ofw install command for .onu and .uim files on the XO-1 but could not find, an old email thread archive via google to the rescue. > - Paint did not start due to missing binaries (does start on the 1.5) > > Regards, > Simon > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.1 development build 31 for XO-1.75
On 21 Mar 2012, at 00:38, Martin Langhoff wrote: > "Are we there yet?" > > This build brings fixes for two critical camera and Sugar crash bugs. > > Updatable via olpc-update -- try the cmdline below. olpc-update worked well on two different XO1.75s. > Fixes (please help us confirm): > > #11657 XO-1.75 "Kernel panic- not syncing" while using Record No panics yet with Record (five 6min videos so far). Changing quality to high causes the video to stall after a handful of frames, but no panic, and Recored would respond to Stop even if it was beach-balling. Low quality video records fine. Regards, --Gary > #11698 Python segfault / error 4 in libglib-2.0.so > > Changes: > > -kernel-3.0.19_xo1.75-20120313.0039.olpc.7f116f1.armv7l > +kernel-3.0.19_xo1.75-20120320.0238.olpc.7e610e7.armv7l > -sugar-0.94.1-2.fc14.olpc.noarch > +sugar-0.94.1-3.fc14.olpc.noarch > > Kernel changelog > > Andres Salomon (4): > Revert "ARM: mmp: Implement periodic timer mode." > ARM: mmp: timer cleanups > ARM: mmp: further timer cleanups > ARM: mmp: implement read_persistent_clock() > > Chris Ball (1): > Revert "mmp-driver.c: Protect access to mmp registers with > dev_lock mmpcam_power_down." > > Jonathan Corbet (6): > marvell-cam: Remove broken "owner" logic > marvell-cam: Increaase the DMA shutdown timeout > marvell-cam: fix the green screen of death > marvell-cam: Don't signal multiple frame completions in > scatter/gather mode > mmp-camera: Don't power up the sensor on resume > marvell-cam: Demote the "release" print to debug level > > Paul Fox (1): > implement calibration for the raydium touchscreen > > Peyton Huang (3): > siv120d: Fix clock divider setting > siv120d: Keep 30 fps in dark lighting condition > siv120d: Corrected vendor recommended values > > Saadia Baloch (2): > mmp-driver.c: Protect access to mmp registers with dev_lock > mmpcam_power_down. > Revert "mmp2-pcm.c: Protect audio DMA from interrupts" > > cheers, > > > > m > -- > mar...@laptop.org -- Software Architect - OLPC > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.1 development build 31 for XO-1 and XO-1.5
Hi Martin, On 21 Mar 2012, at 21:56, Martin Langhoff wrote: > On Wed, Mar 21, 2012 at 4:00 PM, Martin Langhoff wrote: >> Upgrade online with: >> >> # XO-1 >> olpc-update 11.3.1_xo1.5-31 >> # XO-1.5 >> olpc-update 11.3.1_xo1-31 > > That's obviously backwards :-) -- success/fail reports on this > welcome, as at least one user had a failure (I believe a transient > failure, not a bug). Sorry, no luck here with an XO-1 using olpc-update 11.3.1_xo1-31, error is: 8< 8< 8< 8< Downloading contents of build 11.3.1_xo1-31. @ERROR: unknown module 'build-11.3.1_xo1-31': None rsync error: error starting client-server protocol (code 5) at main.c(1516) [Receiver=3.0.8] Could not download update contents file from: rsync://updates.laptop.org/build-11.3.1_xo1-31/contents I don't think the requested build number exists. >8 >8 >8 >8 Downloading and copy-nand'ing the image from http://build.laptop.org/11.3.1/os31/ flashed and booted fine. Regards, --Gary > cheers, > > > > m > -- > mar...@laptop.org -- Software Architect - OLPC > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On 1 Feb 2012, at 04:43, Paul Fox wrote: > sridhar wrote: >> We are considering disabling Automatic Power Management because of its >> impact on collaboration and 3G connectivity. >> >> What kind of battery life can we expect from an XO-1.5 with Automatic >> Power Management disabled as opposed to enabled? I understand that >> this can vary wildly with usage, but is there an average estimate? > > he's on a very long plane flight, but i'll try and channel richard: > >"it depends." > > how did i do? :-) > > you're probably in as good a position to answer this as we are, since > you have a better idea of your system activity load. with automatic > power management turned off, a 1.5 is good for several hours of use, > where "several" is intentionally vague. backlight on full? wireless > on? continuous cpu activity? etc. > > would it help to disable automatic power management only when specific > Activities are running? only when certain kinds of collaboration are > in effect? only when certain drivers are active? Thanks Paul, yes excellent point. With my Activity Team hat on, Sridhar if you could please expand a little on the test cases you are hitting Activity collaboration issues with, so that we can try and resolve or minimise issue from Automatic Power Management kicking in. There are already a number of Activities that programatically keep the machine awake – a simple example is Clock, who wants the clock display to continuously keep stopping as if there's sand stuck in the gears ;) Regards, --Gary > paul > >> >> Thanks, >> Sridhar >> >> >> Sridhar Dhanapalan >> Engineering Manager >> One Laptop per Child Australia >> ___ >> Devel mailing list >> Devel@lists.laptop.org >> http://lists.laptop.org/listinfo/devel > > =- > paul fox, p...@laptop.org > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
On 22 Dec 2011, at 00:23, Martin Langhoff wrote: > On Mon, Dec 19, 2011 at 10:34 PM, Sridhar Dhanapalan > wrote: >> It's a recognition that no software is bug-free, and that users >> (especially children) will always find a way to make a system >> difficult to use. For example, children often load activities without >> closing previous ones. We can educate them to not do this, but it >> still happens on occasion. > > That's exactly the feedback I was looking for, thanks. That's a UI bug > in Sugar. I would strongly prefer the Sugar environment to behave more > like Android, where any app/activity that is in the bg may get an > instruction from the shell / OS to cleanup and exit. +1! (fwiw same as iOS), though the horse has already bolted due to the past calls to support GNOME ported applications with few design considerations for our resource targets. Perhaps we can release/exit activities that at least support the write_file() method, and maybe add an additional new method for something like remember_state(), seeing as the original design requirements were not strict enough in requiring developers to expect to completely resume state accurately (cursor position, UI view modes, etc). --Gary > Do you have any other end-user use cases that have Ctrl-Alt-Erase as a > solution? > > cheers, > > > > > m > -- > martin.langh...@gmail.com > mar...@laptop.org -- Software Architect - OLPC > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
Hi Paul, On 24 Nov 2011, at 15:09, Paul Fox wrote: > bert wrote: >> Today is a sunny day in cold Germany, unlike in the first half of the week. >> So >> I took the 1.75 outside. >> >> IMHO the auto-off is fine as implemented in os12. Not distracting at all. >> Someone suggested turning it back on quicker, I tried that (replaced >> brightness_ramp with set_brightness), but that was much less nice. >> >> As I said previously I like the new mono toggle using the brightness keys >> with >> ctrl. >> >> But I also like the switch to mono when turning the brightness down >> manually. >> Much more convenient (and way more discoverable) than having to remember the >> ctrl-modifier. So I added those two lines back just as they were before, and >> it >> works fine. I would find it a foolish consistency to drop this just because >> automatic switch-off doesn't do it. > > okay, sold. > > i did have a very brief chance to play with the laptop in the sun two > days ago, and after trying more varied types of content, i better > appreciate the value of mono mode. it's sunny here today, so i hope > to get to play with it some more myself. > > i've implemented what a couple of people suggested for brightness key > behavior: I've been trying to keep up with the thread, but just wanted to ask, why would anyone not want to auto switch to mono mode when setting the back light brightness to 0? Mono mode is just so much sharper and clear! For me switching the backlight off in direct sunlight is almost never to do with saving power, I'm after the sharp, crisp, clear, high contrast display. --Gary > - reducing brightness manually to level 0 remains colored (unlike >past releases, where level 0 also implied mono). > > - hitting "brightness down" one more time when at level 0 will >switch to mono. users that use auto-repeat to get there probably >won't see a difference. > > - alt-brightness-down goes to level-0 in mono mode, as it always did. >i think it's a coin-toss whether it should go to level-0 in mono or >level-0 in color. (thoughts?) > > - "brightness up" from level 0 (whether from the color or mono >version of level 0) will always go to level 1, and restore color. > > - sunlight-driven auto-turnoff will go all the way to 0, but won't >invoke mono mode. > > bert, i think you approved of the idea of this scheme on irc, please let > me know if you still think so. > > paul > > >> >> - Bert - >> >> >> ___ >> Devel mailing list >> Devel@lists.laptop.org >> http://lists.laptop.org/listinfo/devel > > =- > paul fox, p...@laptop.org > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.1 build 13 released for XO-1.75
On 22 Nov 2011, at 17:28, Martin Langhoff wrote: > The "oh! and one more thing" build. An OFW full of goodies, and a > kernel that should S/R reliably. > > Download from: > > http://build.laptop.org/11.3.1/os13/ Before I try and open a ticket, is anyone else seeing the cursor sprite corrupt after waking from fast suspend? It doesn't happen every time, but more often than not. Moving the corrupt block of bits over some UI widget restores it back to the correct pointer again. This started appearing in os12. Think I'm also seeing the (clicky) keyboard intermittently fail to wake from the fast suspend as well. Only happend once so far, but it was on first boot while I was typing a name in. I paused after typing one character, just long enough for it to fast suspend. The cursor corrupted when I woke it, and I couldn't type any more name, though I could select/highlight the one character with the trackpad cursor. Have only just installed os13 so will try to trigger it some more. Regards, --Gary > Changes: > - OFW&EC at http://wiki.laptop.org/go/OLPC_Firmware_q4c05 > - Kernel >Andres Salomon (1): > pm: don't use sram when suspending; just use wfi > > > --- os12/xo1.75/os12.packages.txt 2011-11-21 18:10:40.0 -0500 > +++ os13/xo1.75/os13.packages.txt 2011-11-22 12:17:38.0 -0500 > -kernel-3.0.0_xo1.75-2018.1738.olpc.e3f6aac.armv7l > +kernel-3.0.0_xo1.75-2021.1409.olpc.6b59895.armv7l > -olpc-firmware-q4c04-1.unsigned.noarch > +olpc-firmware-q4c05-1.unsigned.noarch > > > cheers, > > > > m > -- > mar...@laptop.org -- Software Architect - OLPC > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO 1.75 update
Hi Peter, On 2 Nov 2011, at 11:40, Peter Robinson wrote: > On Wed, Nov 2, 2011 at 11:36 AM, Kevin Gordon wrote: >> For the past couple of days, the directory: >> >> http://dl.fedoraproject.org/pub/fedora-secondary/releases/14/Everything/arm/os/repodata/ >> >> seems to be empty. >> >> This seems to be the cause of why any yum install attempts are failing, as >> the process cannot 'retrieve repository metatdata (repomd.xml)'. The actual >> error number returned is an HTTP 404, which indicates to me that I can >> communicate with the server. Browsing to many other sites is fine. >> Lastly, the process is also indicating that no other mirror seems to be >> succeeding either. > > There might be a mirror sync problem. I'll investigate. I'm also getting issues trying to yum install some basic dev tools here on the XO-1.75, have you get a chance to poke a stick at this one yet or is it something new? Here's the output I get: [olpc@xo-6d-5e-7c ~]$ sudo yum install -y vim git pylint fedora/metalink | 1.0 kB 00:00 http://dl.fedoraproject.org/pub/fedora-secondary/releases/14/Everything/arm/os/repodata/repomd.xml: [Errno 14] HTTP Error 404 : http://dl.fedoraproject.org/pub/fedora-secondary/releases/14/Everything/arm/os/repodata/repomd.xml Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again Regards, --Gary > P > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.0 release candidate 4 (build 883) released
Hi Daniel,On 29 Oct 2011, at 22:28, Daniel Drake wrote:Hi,We're pleased to announce our 4th release candidate of our new11.3.0 software release.Information and installation instructions can be found here:http://wiki.laptop.org/go/Release_notes/11.3.0Quick links for those who know which files need to be grabbed and saveto USB disks:http://download.laptop.org/xo-1/os/candidate/883/http://download.laptop.org/xo-1.5/os/candidate/883/http://download.laptop.org/xo-1.75/os/candidate/883/This is a signed release candidate that can be installed on all XOs,even those with security enabled.We're looking for testing and feedback on all aspects of the system.I've just been testing Telescope-12 on the XO-1.75 running the new 883 build, first the good news, the camera is showing up correctly in Record and Telescope, fab! :) Now the not so hot:- While in Telescope-12, clicking the digital zoom toolbar button completely locked up the XO-1.75 (re-testing with an XO-1 the digital zoom works ok).- After some waiting and many attempted keyboard shortcuts, I decided to power down. Clicking the power hardware button did not trigger the usual shut down screen during this particular lockup case; clicking the power button twice (assuming it might just be the gfx that had locked-up) had no effect; finally I held down the power button for some seconds until the power led flashes and then the hard powers off.- On reboot the Journal now shows 3 corrupt entries (see attached screen shot) with no name and unknown metadata. None of the three entries allow invoking the details view or raise their palette so can not be erased via the Sugar Journal UI. The three corrupt entries will be an entry for Browse where I visited ASLO to download telescope and then quit Browse; the downloaded Telescope-12 bundle; and the instance entry for the Telescope that was running when the XO locked up.Given the nature of the hard power off I understand why some data would not have been synched to disk, but just wanted to raise this case here. I guess the actionable items might be:1) fixing Telescope-12's digital zoom not to lock up an XO-1.75 (I don't have an XO-1.5 to test but I re-checked on an XO-1 which still worked fine).2) Seeing why the XO-1.75 hard crashed, I'm assuming something camera driver related may have borked badly (I do have a serial cable here for un-bricking an XO-1.75 but don't know my way around that side of things very well).3) Making Datastore more robust to corrupt entries; and/or perhaps just not displaying corrupt entries in the Journal UI (assuming they can be tested for reliably); and/or allowing them be erased via the Journal UI; and/or improving the way Journal displays a corrupt entry (broken document icon, fake title name).I'll hang onto this datastore as is, for a little while, in case someone wants to explore.Regards,--GaryThanks for any help you can offer, and for all the feedback that wasreceived throughout development.Our scheduled release date is November 1st.Please review the "Known problems" section of the release notes. Somedocumented issues are carried over from previous releases, but othersare new and are things that we will aim to fix in the few weeks beforerelease, including:XO-1.75 Sound does not work in many activities (ticket #11296). There is no suspend/resume support yet. There is slight mouse cursor visual corruption in Sugar, and themouse cursor in GNOME appears odd, but is otherwise functional.XO-1 users: we have identified a bug in the firmware releases shippedduring 11.3.0 development and in earlier 11.3.0 release candidatebuilds 880 and 881.Affected versions are Q2E46 and Q2E47. You can check which version youare running in the Sugar 'Settings' dialog.Unfortunately, a bug in the firmware update code means that thesefirmware versions will not automatically upgrade to newer versions. Wehave fixed this in Q2E48 (included in 11.3.0 build 882 onwards), butexisting users of Q2E46 and Q2E47 will need to update manually. Sorryabout that. The procedure is outlined here:http://dev.laptop.org/ticket/11336#comment:8Ask for help on these lists if needed.Users of 11.2.0 and previous (who will be running older firmwarereleases such as Q2E45) are not affected, and XO-1.5 and XO-1.75 usersare similarly unaffected.Changes since build 882:Camera use under Scratch on XO-1.5 no longer exhibits bad colors.Upgrades from 11.2 will now prompt the user to update activities.An XO-1.75 "third dot" boot hang is hopefully fixed.uvc USB webcam driver is now available on XO-1.75XO-1.75 kernel update includes some audio improvements - but we knowthere are still issues.XO-1 screen backlight will turn itself off upon inactivity againXO-1.5 and XO-1.75 firmware updates included.Closed tickets:#11357 Boot freezing on third clock dot#11297 Scratch: Camera quality in xo-1.5 is worst than in os874#11304 11.3.0 build 8 is not dimming, powering off the screen backlight on XO-1#11354 UVC webcam driver not available on XO-1.75#11355 No software-upd
Re: [Testing] 11.3.0 release candidate 3 (build 882) released
Hi Daniel, On 21 Oct 2011, at 19:53, Daniel Drake wrote: > Hi, > > We're pleased to announce our third release candidate of our new > 11.3.0 software release. > > Information and installation instructions can be found here: > http://wiki.laptop.org/go/Release_notes/11.3.0 > > Quick links for those who know which files need to be grabbed and save > to USB disks: > http://download.laptop.org/xo-1/os/candidate/882/ I just wondered if this XO-1 backlight power saving issue has made it onto anyone else's radar, or if I should be setting some special trac flag/keyword? Seems a shame to regress on a basic XO-1 power saving feature. https://dev.laptop.org/ticket/11304 Regards, --Gary > http://download.laptop.org/xo-1.5/os/candidate/882/ > http://download.laptop.org/xo-1.75/os/candidate/882/ > > This is a signed release candidate that can be installed on all XOs, > even those with security enabled. > > We're looking for testing and feedback on all aspects of the system. > Thanks for any help you can offer, and for all the feedback that was > received throughout development. > > Our scheduled release date is November 1st. > > > > Please review the "Known problems" section of the release notes. Some > documented issues are carried over from previous releases, but others > are new and are things that we will aim to fix in the few weeks before > release, including: > > > XO-1.75 > Sound does not work in many activities (ticket #11296). > There is no suspend/resume support yet. > There is slight mouse cursor visual corruption in Sugar, and the > mouse cursor in GNOME appears odd, but is otherwise functional. > Sometimes, part of the screen may not redraw correctly, such as > Sugar's neighborhood view after dismissing the wireless security > dialog (ticket #11273) > > > > XO-1 users: we have identified a bug in the firmware releases shipped > during 11.3.0 development and in earlier 11.3.0 release candidates. > Affected versions are Q2E46 and Q2E47. You can check which version you > are running in the Sugar 'Settings' dialog. > Unfortunately, a bug in the firmware update code means that these > firmware versions will not automatically upgrade to newer versions. We > have fixed this in Q2E48 (included in 11.3.0 build 882 onwards), but > existing users of Q2E46 and Q2E47 will need to update manually. Sorry > about that. The procedure is outlined here: > http://dev.laptop.org/ticket/11336#comment:8 > Ask for help on these lists if needed. > Users of 11.2.0 and previous (who will be running older firmware > releases such as Q2E45) are not affected, and XO-1.5 and XO-1.75 users > are similarly unaffected. > > > > Changes since build 881: > > The Sugar intro screen now shows the correct mouse cursor. > > The Sugar "About my computer" dialog now shows firmware versions on > the XO-1.75 as it does on other laptop models. > > A XO-1.75 graphics drawing problem has been solved: closing the > wireless key dialog no longer leaves an unpainted region on the > screen. > > The camera now works in Scratch on XO-1.75. > > Wikipedia should no longer crash on XO-1.75 and will use less network > bandwidth when online on all laptop models (previously we were > downloading and rendering huge images, now we use thumbnails as we > should!) > > Record no longer crashes on XO-1 when recording audio/video. > > A XO-1 keyboard problem was fixed causing some XO-1 models to have > non-functional special keys (e.g. the frame key) > > An issue preventing XO-1 firmware upgrades was fixed, but affected > users will need to manually update the firmware just this once. > > A trivial bug fix was applied to further reduce the window where the > system may decide to suspend while connecting to a network. > > XO-1.75 now sends kernel log messages over serial console in secure > mode. A XO-1.75 firmware update also reduces the popping at the > start/end of the bootup jingle. > > 8GB disk images are now produced for XO-1.75. > > > Closed tickets: > #11332 Record activity dying while recording on SIGILL on XO-1 > #10712 wrong cursor on welcome screen > #11232 Sugar "About my Computer" dialog does not show 1.75 > firmware/wireless firmware versions > #11315 XO 1.75 secure mode gets ttyS0 console instead of ttyS2 > #11335 Specialized Sugar keys on XO-1 Keyboard not working after battery pull > #11336 Q2E46 does not automatically pick up new firmware builds. > #11318 Ad-hoc network is not brought back after idle suspend/resume > #11319 Scratch looks for wrong libv4l2.so file > #11280 Drawing issue in neighborhood view > #11295 insufficient resources for operation in wikipedia > ___ > Testing mailing list > test...@lists.laptop.org > http://lists.laptop.org/listinfo/testing ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.0 build 6 released, for XO-1.75, XO-1.5 and XO-1
Hi Sameer, On 22 Sep 2011, at 04:23, Sameer Verma wrote: > On Wed, Sep 21, 2011 at 12:43 PM, Peter Robinson wrote: > The "cows with water pistols, chickens in choppers" release. > > We're into Activity freeze so no major changes there > Download from: > > http://build.laptop.org/11.3.0/os6/ > > Bugz fixed: > #11136 XO-1.75 os36 USB device removal may cause hangs and stops USB working > #11255 os5, ARM: telepathy-salut package is out of sync > #10868 Memorize activity has old toolbar > #3 Synchronize 1.75 kernel module list with other XO models > #11144 XO-1.75 ipv6 missing > #11167 XO-1.75 os36 USB modem does not appear in frame > #11177 XO-1.75 powerd does not see touchscreen as activity > #11191 iptables missing from kernel > #11209 XO-1.75 does not host serial adapter, no data flow > #11211 XO-1.75 B1 - synaptics touchpad not detected / does not disable > tap-to-click > #11234 use mtd mounts instead of /dev/mtdblock* on XO-1 > #11242 xulrunner-1.9.2.22-1.fc14 fork needed > #11248 Add Portfolio activity to 11.3.0 > #11253 runin-camera: switch to Xv > #11263 Add device-tree support to olpc-netutils > #10362 Create Game: Palette of "equal pairs" option does not always go away > > Changes and notes from os5: > > kernel: > - audio input (audio still a WIP) > - usb fix > - tap-to-click fix on synaptics > - sync driver support w x86, this adds many USB-Ether, USB2VGA, > USB-WLAN, USB-CDROM drivers... > - 1.75 can now drive our serial adapter > > Activity changes: > > -Memorize-36 > +Memorize-38 > +Portfolio-11 > ___ > olpc mailing list > o...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/olpc > > > > Reflashed a 1.75B1 with os6 It boots up with text messages scrolling, but > when it gets to X with the mouse pointer, it doesn't show me the name screen. > Mouse isn't frozen, but the blank white screen just sits there. Anyone else > seeing this? I'm getting the pretty boot OK, but am seeing the same issue as you where the Naming screen should be (I get a white screen, X mouse pointer). Not sure if it's related, but If I hop over to the console and use top, I can see a python process running along at 95%. Regards, --Gary > > Sameer > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] 11.3.0 build 5 released, for XO-1.75, XO-1.5 and XO-1
On 15 Sep 2011, at 22:15, Martin Langhoff wrote: > On Thu, Sep 15, 2011 at 4:49 PM, Gary Martin > wrote: >> This last one is interesting – the yum install completes successfully >> all the usual output to screen, but vim/git/pylint are all 'command not >> found' > > Actually, what happens is that it fetches the rpm, but refuses to > install it because it' s not signed. Edit /etc/yum.repos.d/*.repo to > say gpgcheck=0 > > I got confused with the same earlier today installing nc, saw all the > familiar yum output, and then it wasn' t there. I hadn't spotted the > gpg check error. Oooh yea, I did briefly notice a single line message, but it says absolutely nothing about aborting, preventing, or failing to install the otherwise requested item/s... +1 for security, -10 for the user feedback ;-) --Gary > Cannot comment on olpc-update problems... > > > > m > -- > mar...@laptop.org -- Software Architect - OLPC > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.0 build 5 released, for XO-1.75, XO-1.5 and XO-1
On 15 Sep 2011, at 09:44, Daniel Drake wrote: >> http://build.laptop.org/11.3.0/os5/ > > Thanks Peter. > > It would be neat if someone can test the olpc-update from build 4 > (*not* any previous one) to this one, with > > sudo olpc-update 11.3.0_xo1.75-5 Not going so well here... Going from build 4, fresh boot, into Terminal and then olpc-update. Each time (three so far) I've run it I've returned to find Terminal has died at some point leaving no log or history so I'm assuming it might be an OOM case and terminal is getting killed. I've installed a handful of new activities from ASLO, edited the x config to disable the Copy acceleration, and tried to sudo yum install vim/git/pylint. This last one is interesting – the yum install completes successfully, all the usual output to screen, but vim/git/pylint are all 'command not found' and I can't find them installed anywhere (using sudo find / -name _ ). I've not rebooted the machine yet, any logs folks wants me to preserve, or incantations to try (I have downloaded the os5 image and was planning to do a clean re-flash tomorrow). Regards, --Gary > as documented: > http://wiki.laptop.org/go/11.3.0 > > Thanks, > Daniel > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO 1.75 os4 display
Hi Sameer, On 11 Sep 2011, at 02:32, Sameer Verma wrote: > I installed os4 on a XO 1.75 B1 last night. I see a screen corruption > with text on both the GNOME and Sugar sides. Entering text into a > textbox in a browser will start corrupting to a point that I can no > longer see some of the letters typed. Minimizing the window and > maximizing it will bring the text back. > > Anyone else seeing this? Yes I'm seeing something similar here in Browse particularly where you have mouse over button UI changes where the cursor seems to be related to the clobbering of the redraw. Regards, --Gary > Sameer > -- > Dr. Sameer Verma, Ph.D. > Professor, Information Systems > San Francisco State University > http://verma.sfsu.edu/ > http://olpcsf.org/ > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: development environment
On 2 Sep 2011, at 14:58, Kevin Gordon wrote: > Hi: I may have some access to a couple of university students who are > interested in doing some python development, using the XO 1.5. > > In order to build a couple of boxes, I'd like to pre-install 'the right > stuff'. > > Might I get a list of packages to install to accomplish this? For Python work on an XO (for Activity and/or Sugar hacking) I find all the extras I need from a regular build is to yum install git, vim and pylint — usually the first habitual reflex thing I do after reflashing a fresh build :) Regards, --Gary > Like maybe > > yum install gcc > yum install gtk3 > yum install gtk3-devel > yum install binutils > yum install vim > or yum install emacs > any python development rpms? > > Is there a page to go for best-practices to develop on the XO. Or, I could > always just have them run a full Fedora install on their Lenovo's :-) > > Right now, they are interested in Python development, not Sugar development, > but sometimes baby steps are best :-) > > Cheers. > > > KG > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] New F14-arm build os31
Hi Gonzalo, On 2 Aug 2011, at 21:18, Gonzalo Odiard wrote: > Gary > I have tested Physics in XO 1.75 installing the package pybox2d and removing > the file Box2D...egg > and works ok. Fab. Thanks for re-testing. Have filed myself a ticket to remind me to make Physics check if the system already has the needed Box2D dependencies before it uses the one in its local bundle: http://bugs.sugarlabs.org/ticket/3012 Regards, --Gary > Gonzalo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] New F14-arm build os31
Hi Gonzalo, On 31 Jul 2011, at 06:15, Gonzalo Odiard wrote: > > Moon: does not start, but with a python error in the activity, must try > > update it > > For Moon also check you have the date set to the current time (I have a > ticket still open for having it fail more gracefully). Latest release is > Moon-12. Let me know the error if it's something else, Moon is a very simple > python activity and isn't doing anything weird :-) > >> Ok, the date was from year 2000. I have set date and Moon started ok. Thanks for re-testing. > > Physics: probably no binaries in egg, we must try with package pybox2d > > Yes, very likely. I'll need some help re-building the eggs if we want this > fixed from inside the activity. It could also be olpcgame/pygame related? Any > other pygame based activities you know of working? > >> I could not try with 1.75 yet, but in xo 1.5, I removed the egg in the >> activity and installed pybox2d package and the activity worked ok. In Pippy >> we need do a few changes. Thanks, that gives me an idea. I could add a simple check to see if a version of pybox2d is already installed and then not add the locally included module version to the python search path. Regards, --Gary > > Maze: do not start and do not write anything in the log file > > Could be olpcgame/pygame related? > > I don't know yet. > > Gonzalo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] New F14-arm build os31
Hi Gonzalo, On 29 Jul 2011, at 05:34, Gonzalo Odiard wrote: > Hey, no so bad :) > The good news first: > The following activities starts and works: > TurtleArt, Speak, TypingTurtle, Labyrinth, Memorize,Browse, Log, Words, Help, > Chat, Scratch, Distance, Finance, > Infoslicer, Implode, Terminal, Calculate, Etoys and ImageViewer > > Activities with errors: > GetBooks: no HAL (anyway we must substitute by udev) > TamTam*: no blobs, probably only recompile > Puppy: starts ok and many examples work, but no the camera and no sound > examples (I have not tested all) > Measure: no HAL > Stopwatch: do not start and do not write anything in the log file > Write: no abiword module > Paint: no blobs, probably only recompile > Moon: does not start, but with a python error in the activity, must try > update it For Moon also check you have the date set to the current time (I have a ticket still open for having it fail more gracefully). Latest release is Moon-12. Let me know the error if it's something else, Moon is a very simple python activity and isn't doing anything weird :-) > Jukebox, started but did not played a ogg file > Record: starts but only with audio > Physics: probably no binaries in egg, we must try with package pybox2d Yes, very likely. I'll need some help re-building the eggs if we want this fixed from inside the activity. It could also be olpcgame/pygame related? Any other pygame based activities you know of working? > Maze: do not start and do not write anything in the log file Could be olpcgame/pygame related? Regards, --Gary > Read: no module webkit > > Gonzalo > > > > On Thu, Jul 28, 2011 at 5:35 PM, Martin Langhoff wrote: > On Thu, Jul 28, 2011 at 4:03 PM, Martin Langhoff wrote: > > The "Switch to Fedora-14" build. > > http://build.laptop.org/F14-arm/os31/ > > Looks like we have major framebuffer performance diference in F14. > Comparing os23 (f13) and os31 (f14), both with the same kernel... > > Camera to ximagesink is much better behaved. Quick test procedure > > - Boot into sugar > - open Terminal activity > - sudo /runin/runin-camera & > - click on terminal window, start top > - move pointer to a corner to get frame, bring forward the gts-launch > window, move it so that you can read top's top lines > > = os23 shows ~1% idle, 88.7user, 11%sys -- user time is split between > gst-launch (~70%) and X (~25%) > = os31 shows ~35% idle :-D -- 55% user, 6% sys -- gst-launch at 45%, X at 2% > > Implode appears to be a bit faster too -- but it's hard to judge. > > cheers, > > > > m > -- > mar...@laptop.org -- Software Architect - OLPC > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > ___ > Techteam mailing list > techt...@lists.laptop.org > http://lists.laptop.org/listinfo/techteam > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Announcing OLPC OS 11.2.0 for XO-1 and XO-1.5
Hi Daniel, On 22 Jul 2011, at 21:32, Daniel Drake wrote: > We're pleased to announce the release of OLPC OS 11.2.0 for XO-1 and > XO-1.5. Details of new features, known issues, and how to > download/install/upgrade can all be found in the release notes: > http://wiki.laptop.org/go/Release_notes/11.2.0 > > Many thanks to all contributors, testers, upstreams, and those who > have provided feedback of any kind. > > For those who were following the release candidate process in the last > few weeks: candidate build 874 is released as final with no changes. Fantastic — thanks for all your hard work getting this release out the door! --Gary > Thanks and enjoy! > Daniel > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.2.0 release notes ready for review
Hi Alan, On 21 Jul 2011, at 20:46, Alan Jhonn Aguiar Schwyn wrote: > Hi Gary, > >> Complicated! ;) >> >> As to why there is no 'don't save', well a couple of points: >> >> 1) the Journal was designed to be a log of activity not just a flat >> list of saved data files, it would be great to have more interesting >> metadata auto stored (e.g. length of time spent in activity, number of >> times resumed), and/or to be able to better encourage the child to write >> short descriptions about what they were doing for later review (e.g. "I >> searched google for cool pictures of sharks with lasers, for my >> school essay, but didn't find one I liked."). >> > > Yes, in theory. I am Uruguayan. I have seen thousands of XO .. No one uses > the journal that way, the little disk space (1 GB 400 MB are available) and > when you have hundreds of entries, and begins to complicate, to walk slower. Journal entries, especially ones that are just metadata that an activity was used are very small amounts of data on the disk. I think perhaps the worst case would be if a child is making lots of video or audio recordings using the Record activity, EToys projects, and perhaps Paint being the next worse for disk size. I would love to know what children are using up their disk space with. I'm guessing some of it is downloads of the less disk space efficient Activity software ports from Gnome (Tux Paint, Open Office, Firefox, some of the GCompris activities), and perhaps using Browse to save music, video and pictures from the Internet. Would be great if you have any information/data on how you see children have used up most of their disk space! With the new builds OLPC are currently finishing up for release, the version of Sugar in them supports sorting the Journal by size, and by creation date (in addition to the default modification date). Sorting by size is great for tracking down where all your disk space went, sorting by creation date is helpful when you are looking for work you know you started last Monday, or at the beginning of term, or you can remember other activities you did at the same time (I took 5 photos and then started the essay I'm looking for). > And the problem of "find nothing" is repeated often. Cause: You may need to > teach children the proper use of labels. But the kids out of an activity and > never notice that ... I have come across many machines you have to reflash > because it does not leave or enter the newspaper to delete things (in old > sugar images, in this new I not do a stress test) … I'm hoping this is only an issue with an old version of Sugar, and it's now been fixed… But please do report back if you continue to see such things in new releases. > >> 2) The naming dialogue was added as an opportunity for the child to >> provide a useful name, description and tags when they stop a new activity >> instance. The activity state will very likely havebeen already >> automatically stored in the Journal (e.g. activity state is stored in the >> Journal whenever you switch views). So the 'don't save' button would really >> be an 'erase this entry from the journal' button. >> > > Changing the implementation of the saved, change this too > >> FWIW, there is already an accepted design for dropping this naming >> dialogue (at least one deployment has already removed it from their builds) >> as the psychology of a user who has just clicked 'Stop' is one of >> "get me out of here, I want to do something else now", not "I would like to >> describe what I was just doing", most folks seem to skips past the dialogue >> as fast as they can, annoyed/distracted by the interruption. The >> replacement design is a system wide 'detail view' dialogue (similar features >> as per the current Journal details view) that can be opened at the users >> discretion while working in an activity. >> >> "most folks seem to skips past the dialogue as fast as they can, >> annoyed/distracted by the interruption" > > Yes, I'm agree. > Also is annoying is to have the obligation (not freedom) the save something .. > For example, when I use the Activity Maze, entered to play at level 1. When I > return to the entrance that, start in 1! That's the point? Many of the > activities create an entry "habit", butbear no relevant information, For the Maze activity, this is considered a missing feature. I'm pretty sure we have a bug ticket (or two) open requesting that a resumed Maze activity continues from the level you had last reached (and perhaps having a leader board for who solved the maze first/second/third for each level completed). Over time, Activities are getting better and better at keeping useful state in the Journal (have you experimented with the Physics activity yet?), we need to keep on making sure activity designers make best use of Journal state. > and generate an endless list of meaningless entries(k
Re: 11.2.0 release notes ready for review
Hi Alan, On 21 Jul 2011, at 00:37, Alan Jhonn Aguiar Schwyn wrote: > > The idea of the X is not save the entry.. > > to avoid a shutdown by mistake could add the classic triangle of return ... > > The final windows may be with 3 options: > > Triangle: return to the activity (The problem is that usually the activity is > closed) > > Cross: don't save the entry in the journal.. > > Tick: save the entry > > It's a simple system, no? Or is't complicated? Complicated! ;) As to why there is no 'don't save', well a couple of points: 1) the Journal was designed to be a log of activity not just a flat list of saved data files, it would be great to have more interesting metadata auto stored (e.g. length of time spent in activity, number of times resumed), and/or to be able to better encourage the child to write short descriptions about what they were doing for later review (e.g. "I searched google for cool pictures of sharks with lasers, for my school essay, but didn't find one I liked."). 2) The naming dialogue was added as an opportunity for the child to provide a useful name, description and tags when they stop a new activity instance. The activity state will very likely have been already automatically stored in the Journal (e.g. activity state is stored in the Journal whenever you switch views). So the 'don't save' button would really be an 'erase this entry from the journal' button. FWIW, there is already an accepted design for dropping this naming dialogue (at least one deployment has already removed it from their builds) as the psychology of a user who has just clicked 'Stop' is one of "get me out of here, I want to do something else now", not "I would like to describe what I was just doing", most folks seem to skips past the dialogue as fast as they can, annoyed/distracted by the interruption. The replacement design is a system wide 'detail view' dialogue (similar features as per the current Journal details view) that can be opened at the users discretion while working in an activity. Thanks for taking the time to write some feedback, hope the above was of some help. Regards, --Gary > > Alan > > > Date: Wed, 20 Jul 2011 20:26:42 -0300 > Subject: Re: 11.2.0 release notes ready for review > From: gonz...@laptop.org > To: alan...@hotmail.com > CC: d...@laptop.org; devel@lists.laptop.org; support-g...@laptop.org > > > > On Wed, Jul 20, 2011 at 8:04 PM, Alan Jhonn Aguiar Schwyn > wrote: > > Hi, > > I'm down the new version ... > > When you leave an activity, a window appears that asks the name of the > journal entry.. > > Is like this? (capture01.png) > > Why is not this? (capture02.png) > > > God question. > What is your idea about the X icon? > Do not close the activity? > There are times when I accidentally close one activity and think about this. > Close the activity without saving? > > > Some activities don't save any relevant information in the journal... > > All the time, I used an activity, exit of it, click on the 'tick' button to > save the entry in the journal and need to delete it... > > > If one activity does not save relevant information and save to the Journal, > is a bug in the activity. Can you point to the failing activities? > > Is important remember the window is opened only when you start a new instance > of the activity and by default you restart the last instance. > > Gonzalo > > Give to the users the freedom to save or not the entry, as in any system... > > I think in this... It's possible? A very small change... > > Alan > > > > > > Date: Wed, 20 Jul 2011 10:32:50 +0100 > > Subject: 11.2.0 release notes ready for review > > From: d...@laptop.org > > To: devel@lists.laptop.org > > > > > Hi, > > > > The 11.2.0 release notes are now ready for review by the OLPC team and > > by any other interested contributors: > > http://wiki.laptop.org/go/Release_notes/11.2.0 > > > > Feedback needed quickly, as the release is imminent. > > > > cheers > > Daniel > > ___ > > Devel mailing list > > Devel@lists.laptop.org > > http://lists.laptop.org/listinfo/devel > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [support-gang] [ANNOUNCE] Sugar Labs Licensing Referendum (non-binding) results
Hi Luke, On 11 Jul 2011, at 16:43, Luke Faraone wrote: > On 07/10/2011 10:23 PM, Gary Martin wrote: >> I was surprised as I had no recollection at all of the original email >> (subscribed to way too many Sugar related lists), but after some >> digging found it had been clobbered as junk email, so not sure who >> else this may have hit, but thought it worth mentioning. > > Odd. Did you at least get the mail from Selectricity? Not that I was aware of, but I just did a search for selectricity and found a June 15th email "[Sugar Labs Licensing Referendum (non-binding)] Election Begun!" again tagged as spam and unread. I'm using gmail, it usually does an excellent job with spam, so something's clearly triggered their filters. --Gary > -- > Luke Faraone > Sugar Labs, Systems > ✉: l...@sugarlabs.org > I: lfaraone on irc.freenode.net > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [support-gang] [ANNOUNCE] Sugar Labs Licensing Referendum (non-binding) results
Hi Luke, I was surprised as I had no recollection at all of the original email (subscribed to way too many Sugar related lists), but after some digging found it had been clobbered as junk email, so not sure who else this may have hit, but thought it worth mentioning. Regards, --Gary On 10 Jul 2011, at 23:45, Luke Faraone wrote: > On 06/14/2011 05:42 PM, Luke Faraone wrote: >> This is a vote to determine the suggested license for future releases >> of Sugar. This poll will run from right now until Wed Jun 29 2011 at >> midnight UTC-4. > > Sorry for the late update; the reporting mechanism for our voting > software temporarily broke. > > Summary: the winner was **GNU GPL version 3, or any later version**. > > ## Results Details ## > > 55 out of 217 eligible members voted, or a little more than ¼. > > The full results of this election ranked the candidates in order of > preference (from most preferred to least preferred): > > 1. GNU GPL version 3, or any later version > 2. GNU GPL version 2, or any later version > 3. Don't know or don't care > > > Each number in the table below shows how many times the candidate on the > left beat the matching candidate on the top. The winner is on the top of > the left column. > v3 v2 DC > v3-- 34 37 > v221 -- 42 > DC18 13 -- > > Based on a sheer count of 1st place votes, v3 received 49% of the vote, > v2 received 29% of the vote, and the apathetic position received the > remaining 22% of the vote. > > Full details (and alternative election method calculations) are visible > at the Selectricity page linked in the original voting ticket email. > > Thanks, > > Luke Faraone > Sugar Labs, Systems > ✉: l...@sugarlabs.org > I: lfaraone on irc.freenode.net > > ___ > support-gang mailing list > support-g...@lists.laptop.org > http://lists.laptop.org/listinfo/support-gang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.2.0 release candidate 2 (build 871) released
Hi, On 1 Jul 2011, at 12:18, Daniel Drake wrote: > Hi, > > We're pleased to announce our second release candidate of our new > 11.2.0 software release. > > Information and installation instructions can be found here: > http://wiki.laptop.org/go/Release_notes/11.2.0 > > Quick links for those who know which files need to be grabbed and save > to USB disks: > http://download.laptop.org/xo-1/os/candidate/871/ > http://download.laptop.org/xo-1.5/os/candidate/871/ Now I'm back home with a better internet connection and more XO-1s (hoping to run some collaboration tests between 3 machines), I've been trying to download the latest XO-1 image the past few of days but download.laptop.org seems to be not responding. Is it just something at my end, or is anyone else having difficulties? Regards, --Gary > This is a signed release candidate that can be installed on all XOs, > even those with security enabled. > > We're looking for testing and feedback on all aspects of the system. > Thanks for any help you can offer, and for all the feedback that has > been received already. > > Our scheduled release date is July 18th. > > > Since release candidate 1 (build 870) we have fixed the following issues: > > Various collaboration-related bugs were fixed. Collaboration in Read > and ImageViewer is now working again. In the neighborhood view, users > correctly cluster around shared activities again, and connecting to > gabble no longer results in duplication of your own buddy icon. > > Journal fixes include less needless rescanning and the ability to > modify file information on external disks. > > FotoToon is now a favorite activity by default. > > XO-1.5 graphics rendering bugs could be seen sometimes in Moon and > Browse - now fixed. > > XO-1.5 laptops using the original XO-1 "ALPS" keyboard are now usable again. > > The XO-1.5 boot partition is now correctly mounted after boots where > activation happens. > > The blank screen during XO-1 boot no longer happens. > > > Closed tickets: > #10851 mysterious black monolith on the moon > #10880 Display corruption in Firefox displaying a png > #11015 Barbershop-style Video corruption on XO-1.5 in 11.2.0 > #10941 Clock, Abacus, HelloWorld, Fototoon not favorite > #11016 ALPS keyboard on XO-1.5 outputs gibberish in OFW & Linux > #11018 /bootpart not mounted after activation > #11019 black screen during XO-1 boot > #10749 salut: mission control account information is not updated when > changing the nick name > #10965 When connected to school server and using gabble buddy is drawn > twice in home view > #10675 Shared activity users do not get clustered around activities > they are collaborating in > #10840 Entry not colored when started from external device (or first > copied from device) > #10717 Journal: Can not change entry information on external device > #10841 Journal: Rescan of external device view when dragging an image > #10817 friendstray does represent buddies of a shared activity we have > not joined yet > #10906 Transfer files in sharing from one to many is broken > SL#2880 Use the same wording for the filesize of an entry without a file > SL#2926 Journal detail view: sync updates of elements > > Thanks! > Daniel > ___ > olpc mailing list > o...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/olpc ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 870 on XO1
On 26 Jun 2011, at 14:20, Daniel Drake wrote: > On 26 June 2011 00:03, Kevin Gordon wrote: >> Folks, on XO 1 with new 870 build : >> >> 1) At boot, once the animation has completed its little circle, the screen >> goes black for about 17 seconds before the favourite wheel comes up. Does >> this on multiple XO's. Does not happen on os23. > > Thanks, filed as http://dev.laptop.org/ticket/11019 Yes saw this one as well, for the first couple of boots I thought it might be power saving kicking in at the wrong time, glad you've spotted the cause :) >> 2) In general, boot takes about twice as long on 870 than on os23, again on >> multiple XO's compared. >> >> 3) Activities take longer to launch, flashing icon stays almost twice as >> long on the screen before the screen comes up than it did on os23 for some. Just so we have some rough numbers, from power key press to seeing the central XO icon on the Sugar desktop, the previous 11.2.0 os23 started in 60sec, and the new candidate os870 started in 82sec (average over two runs). For activities – excluding the first run case – Moon & Browse both started in 13sec +/-1sec in both builds. > These are due to the filesystem switch, or more specifically the > switch in compression methods used. The result is significantly > reduced disk utilisation (higher compression) but more CPU-intensive > work needed to read and write files. Unfortunate, but true. A slowdown > is expected, as a tradeoff for not shipping a nearly-full disk. > > What we've effectively done is reverted to what we had for 10.1.3. So, > a more interesting comparison would be observing build 860 at the side > of build 870. Bear in mind that some activities take a lot longer to > launch the first time after flashing, e.g. Browse and Record, so care > is needed to ensure the comparison is fair. I didn't check 11.2.0 os23 (and don't have that build here to re-flash again), but on a clean os870, a Terminal df -h says 69% (699Mb) used. Regards, --Gary > Thanks, > Daniel > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 touchpad once more
On 13 Jun 2011, at 20:36, Yioryos Asprobounitis wrote: > I came across a forum post [1] (last sentence) that remind it me once more > the ALPS XO-1 touchpad issue. > In all the post os802 builds, OLPC 10.1.x, Dextrose 2x and OLPC 11.2.0, the > problem is *considerably* worse eg much more often and persistent than in F9 > builds. > > The fact that the touchpad was jumpy before, may result in labeling this "not > a regression". But is clearly NOT the case. > With post F9 builds is really hard to use first generation XO-1s without a > mouse. > Before was bad, now is close to intolerable. Just wanted to chime in that I've been switching between 802 and os19/os21 while testing/debugging some of the activities I maintain on XO-1 hardware. The trackpad reliability does seem to have taken a step or two back from where we were with 802 (more frequently grinds to near stationary, and more frequently decides to drift when no fingers are near the trackpad). Sorry, no hard numbers. I wouldn't go as far as to say it is close to intolerable, but it is more frustrating than before. I did wonder if it could be due to the debugging level for these test builds? Lots more getting written to the logs. Not sure how to change logging level these days, is it now hidden in gconf somewhere? Regards, --Gary > I can appreciate that ALPS XO-1s are long EOL and newer builds and hardware > are more pressing matters, but we are talking probably half the OLPC > installed base here that may not be able to be fully benefited by the newer > builds. > > I do not think that should be seen as a secondary issue or something that > there is nothing to be done about. > Yes, it is a hardware problem in its core but it was not that bad in older > builds. > So something should/could be done to at least go back to that level of > discomfort. > > What about going back to the 2.6.25 driver? > Even without auto-recalibration provided a better user experience apparently. > > [1] http://www.olpcnews.com/forum/index.php?topic=5000 > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Initial tests of Activities, as shipped, on a New XO-1.5
On 2 Mar 2011, at 13:34, Thomas C Gilliard wrote: > Attached is an OpenOffice.org Calc spreadsheet of my initial testing of > activities on a new XO-1.5 > > All activities started and functioned well. > The Only exception being Maze where I could not get the ball to move. > (May be my lack of understanding of the application) > > I used a wireless connection to an apple airport extreme (type 2) > ( Alphabetical Wep connection) > The Control Panel/Software Updates worked and updated 3 activities. > > Jabber.sugarlabs.org was not responding so I could not test these functions > > Note: I tested all of the activities listed in sequence in the F3 list view. > This almost borked the XO-1.5. > the memory became almost full and responses became very lethargic. > I had to go to the journal and delete each entry, one at a time. Could you confirm low storage space was the issue? Perhaps some activity is being mischievous on exit and not freeing up resources? It sounds more like low ram, or a hung process eating CPU. If some activity is indeed creating massive Journal entries, eating large chunks storage space it should be reported as a bug otherwise it'll likely trigger many maintenance issues. One other possibility is a ram leak in Sugar, we did have one just prior to a release a year or so back, but that was discovered and fixed just in time for the GM (each activity launch consumed some memory that it didn't release). You could test for this by repeatedly resuming and stopping a simple Activity (I usually used Moon), while keeping an eye on top running in Terminal. > A very slow process. > There needs to be a way to select by group checking the "stars" in the > journal to allow > group deletions from the journal. The stars are for marking favourites (currently used for quick filtering from the Journal toolbar). There are a number of design mockup for a Journal with multi select support, using a column of check boxes and showing a new group operation toolbar seems to have most support last time it was discussed. It's a fairly invasive chunk of Journal work and last time this came up there were not enough resources to tackle it. Regards, --Gary > There was also no warning of the impending lockup. > I believe some of these issues have been addressed in the software I will be > testing on this Loaned > XO-1.5 [1] > > No collaboration testing has been done in this initial set of tests. > I plan to test against my XO-1 (G1G1) currently running os439dg and > My Collection of Netbooks running sugar native and as Virtual Box Appliances. > > Tom Gilliard > satellit on freenode IRC > Bend Oregon > > [1] http://wiki.laptop.org/go/Projects/Dextrose2_testing_with_a_loaned_XO-1.5 > > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: USB Ethernet test
On 11 Jan 2011, at 22:57, James Cameron wrote: > On Tue, Jan 11, 2011 at 02:40:23PM -0300, Martin Abente wrote: >> Researching on the web, I found this [1]. Basically autoip was causing >> confusion when making the users to believe that the ethernet >> connection was _always_ successful. > > Caused by conflating two concepts; network interface configured, vs user > perception of a useful network. > >> http://www.mail-archive.com/networkmanager-list@gnome.org/msg04835.html > > I disagree with Jerone. The connection is not useless, it is ready. > > Once another node joins the network, it will be accessible. However, I > don't think the connection state should be given to the user as a claim > that they have a useful network that will carry their packets to the > internet. That's a fundamental design issue. Ooh, interesting. I take it the below 'indicate connected to provider and, I seem to be able to talk to some Internet servers' is the UI direction you've seen provided for this before? FWIW: OS X uses a red (no network), amber (a network found), green (can talk to some remote Internet server) visual warning on network status. Regards, --Gary > It can be made to work in our case, just by assigning an IP > automatically, since Sugar can operate well on a network that does not > carry packets to the internet. > > p.s. modern consumer DSL and wireless routers in Australia deal with > this issue by adding an indicator; one LED indicates connected to > provider, another LED indicates success of ping to one of a set of > predefined test IPs on the internet. > > -- > James Cameron > http://quozl.linux.org.au/ > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] A heads up for the major changes that will appear in Fedora 15 / SoaS 5
Hi Peter, On 28 Dec 2010, at 21:17, Peter Robinson wrote: > Hi All, > > I just thought I would give people a heads up for changes that I'm > aware of that are going to be appearing in Fedora 15 / SoaS 5. > > The big one will be gnome3/gtk3 plus the associated changes that will > come with the required pygtk / gobject-introspection (Tomeu could you > possibly fill out some of the impact of this?), I'm somewhat concerned > about this actually but time will tell. This is the monstrous gaping maw of doom, from my perspective. Just about every Activity and much of the Sugar UI will break. Hopefully some of the fixes may be cookie cutter applied once we've worked through a few. It'll be a red flag day for all Activities, as once fixed up, they will be incompatible with past Sugar releases (up to now it has been largely possible for an Activity to run on all past Sugar releases). Tomeu mentioned the idea of a Sugar hackathon event of some kind to try and fix up as much as possible. Regards, --Gary > Also on the cards is the following: > - csound 5.12.1 (in rawhide now - please test) > - systemd - new init startup - I don't this affects us directly in > that we don't have any specific custom services that depend on it > (although it might affect olpc) > - /var/run and /var/lock mounted as tmpfs (likely no affect as the last one) > - Replace setuid applications with File Capabilities in order to make > them more secure (again I don't think anything will be affected) > > All the current approved Fedora 15 features can be found here [1] > > If anyone else knows of anything else that might affect the release, > or if anyone has queries or more information to add please speak up. > > Regards, > Peter > > [1] https://fedoraproject.org/wiki/Category:FeatureAcceptedF15 > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.75 progress
Ed, On 11 Nov 2010, at 18:30, Ed McNierney wrote: > Bert - > > No, not at all. Our plans were, and are, to build XO-1.75 laptops with > touchscreen support. That's an essential step in our tablet development, we > think. That will essentially provide us with a 7.5" 4:3 tablet inside a > laptop case. That's a little small for a tablet, but it allows useful > software development for a tablet model quite early - with a keyboard and > mouse as fallback tools. Many thanks for the clarification, really good to know. I was hoping to use an iPad for early UI Sugar testing using remote sessions back to a host (VNC and RDP), unfortunately the clients get in the way of useful UI testing. --Gary > But I think it's important to think about XO-1.75 more as a set of > technologies than as a "product" right now. We're still experimenting. > We're learning, for example, that while interested deployments like the idea > of an XO laptop with a touchscreen, they're also very sensitive to price, and > aren't likely to purchase machines with an optional piece of hardware that > isn't necessary for the device's operation, especially when that hardware > will add more than $10 to the cost of the machine. So we're certainly going > to produce XO-1.75 machines with touchscreens for software development, but > it's entirely possible that no machines will be delivered to deployments with > touchscreens installed. > > - Ed > > > On Nov 11, 2010, at 7:32 AM, Bert Freudenberg wrote: > >> On 11.11.2010, at 12:49, Ed McNierney wrote: >> >>> [...] we're talking about XO-1.75 right now, which is a laptop. An OLPC-3 >>> tablet is a long way away and it's not really useful to discuss/speculate >>> on it now. We're working on XO-1.75. >>> >>> - Ed >> >> Back in July there were plans to have a touchscreen in the XO-1.75: >> >> "the XO-1.75 will have a touchscreen, as will future OLPC tablets based >> on its design" >> >> http://lists.sugarlabs.org/archive/sugar-devel/2010-July/025376.html >> >> So this has been tabled? >> >> - Bert - >> >> ___ >> Devel mailing list >> Devel@lists.laptop.org >> http://lists.laptop.org/listinfo/devel > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar on Tablet - On Screen Keyboard
Hi Narendra, On 21 Sep 2010, at 05:56, Narendra Sisodiya wrote: > Is anybody working on Onscreen Keyboard or related stuff on Sugar ? > also what is the current status and how I can contribute. > We got some success to bring Sugar on ARM tablets[1]. now we are > exploring more. need suggestion too As per Tomeu's email, Sayamindu had done the most investigation in this area I think. He implemented mobins fvkbd (http://git.moblin.org/cgit.cgi/fvkbd/) as an experiment in Sugar. Here's the .iso he made with it added in (virtual keyboard device icon is in the frame): http://dev.laptop.org/~sayamindu/sugar-vkbd-test/sugar-vkbd-test.iso There is a screen cast of it at: http://dev.laptop.org/~sayamindu/sugar_vkbd_multi.ogv And the feature wiki page is at: http://wiki.sugarlabs.org/go/Features/Onscreen_Keyboard Also note that the Dextrose images have the gnome accessibility virtual keyboard (enable it from the My Settings control panel). Its visual theme is not very Sugar like, but I think it may be a better choice as is has all keys available, the vkbd seems more for casual phone type messaging use (missing lots of symbols you would need if you wanted to do a programming type task, even missing some basic maths characters). I'm not sure how well the gnome virtual keyboard is to localise, that would be rather critical to make sure it works easily for many language keyboards. Regards, --Gary > [1] - > http://blog.narendrasisodiya.com/2010/09/fedora-12-olpc-sugar-on-arm.html > -- > ┌─┐ > │Narendra Sisodiya > │http://narendrasisodiya.com > └─┘ > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Calculate-33 request for activities wiki update page
Hi Frederick,
On 13 Sep 2010, at 05:22, Frederick Grose wrote:
> On Sun, Sep 12, 2010 at 8:49 PM, Gary C Martin
> wrote:
>> Hi Folks,
>>
>> Not sure where this email should be going, but now that the
>> http://wiki.laptop.org/go/Activities/G1G1 and equivalent update pages are
>> locked down, could I request the links for Calculate be updated to the
>> current version?
>>
> The page is based on Activity page templates that don't seem to be protected
> from editing. See
> http://wiki.laptop.org/index.php?title=Activities/G1G1&action=edit, to view
> the source for the page.
>
> http://wiki.laptop.org/go/Activities/Calculate-G1G1 is unprotected, so
> responsible parties may keep these up-to-date.
Sorry no luck. If you follow the edit trail the page is locked (for me at
least, perhaps you are flagged as an admin). Here's the error I see:
""
You do not have permission to edit this page, for the following reason:
This page has been protected from editing, because it is included in the
following page, which is protected with the "cascading" option turned on:
• Activities/G1G1/10.1.1
""
I get the same error when I try to edit Moon or Maze. Maybe it's because these
activities were maintained and tested to work in all shipped builds and didn't
need to fork out various update pages for releases and deployments? Analyze
(http://wiki.laptop.org/go/Activities/Analyze-G1G1) lets me edit without the
error, I seem to remember that forked at one point.
Regards,
--Gary
>>
>> {{Activity-oneline
>> |icon = activity-calculate.svg
>> |activity_name = Calculate
>> |activity_description = Basic calculator
>> |activity_id = org.laptop.Calculate
>> |activity_bundle = Calculate-33.xo
>> |activity_bundle_url =
>> http://activities.sugarlabs.org/en-US/sugar/downloads/file/27032/calculate-33.xo
>> |activity_bundle_branch = Calculate (latest)
>> |activity_version = 33
>> }}
>>
>> If you'd prefer the .xo bundle to be served from wiki.laptop.org let me know
>> and I can upload (or feel free to upload it yourself). The version 30
>> currently linked to is rather out of date and I'm seeing bugs filed that
>> have already long been fixed.
>>
>> I've tested Calculate-33 on an XO-1 in build 802 (Sugar 0.82), 852 (Sugar
>> 0.84), 373pyg (Dextrose/Sugar 0.88), and a number of VM based images
>> including an F13 Sugar 0.88.1, and an F14 Sugar 0.89.3.
>>
>> Kind Regards,
>> --Gary
>>
>> P.S. On a more general note activity, I'm not sure of the policy for keeping
>> the wiki update pages pointing to the latest stable releases. Do we/I need
>> to go through the current list and raise the newer releases from ASLO that
>> should be considered/re-tested/updated now that the OLPC 0.84.x based Sugar
>> build is official?
>>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Initial F14 developers-only release for XO and XO-1.5
Hi Mikus, On 4 Sep 2010, at 10:24, Mikus Grinbergs wrote: > > For instance, Read-87 fails to launch on XO-1 os1 (F14) when it tries to > 'import evince'. Though the necessary gnome-python2-evince package was > not included in the os1 build, when I manually install that package from > the yum Fedora-14 repositories, the import statement still fails -- > apparently because the evince.so module provided by the current > Fedora-14 package has internal inconsistencies. I myself do not have a > Python test case which does 'import evince' - nor do I have a patch - > but perhaps the maintainers of the Read Activity might want to discuss > this situation with the maintainers of Python on Fedora 14. FWIW, long story, and much traffic about this. The evince API has radically changed. Read was/is broken on distros that shipped the new evince. Lucian very kindly took some time out from his Browse/Surf web kit work to update Read (he had been already working with new evince for PDF support). I think the only feature regression was that of Epub support (works, but the toolbars have been disabled until it's also hooked into the new API — on my todo but quite far down and quite complicated for me). ... and just to complicate matters the git rep mainline (which Lucian updated to support the new evince) is at version 79 — no idea where 87 came from, looks like releases have been made from some other rep/branch, so am not sure what other changes happened 78 -> 87, yes it's a mess :-( When I last tested, the current version in git is good for F14 (excluding the above Epub UI regression). Regards, --Gary > mikus > > Traceback (most recent call last): File "/usr/bin/sugar-activity", line 21, > in main.main() File > "/usr/lib/python2.7/site-packages/sugar/activity/main.py", line 115, in main > module = __import__(module_name) File > "/home/olpc/Activities/Read.activity/readactivity.py", line 25, in import > evince ImportError: /usr/lib/python2.7/site-packages/gtk-2.0/evince.so: > undefined symbol: ev_selection_get_selection_map 1283617092.832518 DEBUG > root: _cleanup_temp_files Exited with status 1, pid 1919 data (None, ', mode > 'w' at 0x94ff5f8>, 'cc1399fc91616fa81d576acdc0389304f4e8bce9') > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Killing activities when memory gets short
On 11 Aug 2010, at 18:42, Paul Fox wrote: > gary wrote: >> >> P.S. of corse you'll now tell me os850 was also pre-linked (I couldn't see >> anything about it in the build notes for either os850 or os851), and I'll >> look >> silly for trying to test for a difference, confirming my results were non >> significant ;-) > > that's exactly right. :-) > > pre-linking has been in the builds for some time, i believe. Lol! :-) At least it's nice to know that the usual OOM behaviour is that the just launched activity is the one that gets it in the neck, most of the time. Pity about the lockup that usually happens before the kill, is it possible to make the OOM happen at a higher free mem threshold? --Gary > paul > =- > paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Killing activities when memory gets short
Hi James, On 11 Aug 2010, at 04:05, James Cameron wrote: > On Tue, Aug 10, 2010 at 05:48:00PM -0700, John Gilmore wrote: >> ... and was also unsuccessful in convincing OLPC to prelink the shared >> libraries before shipping a release, thus allowing read-only pages to >> not get dirtied with shared library linkage relocations. > > 10.1.2 release candidate os851 has prelink before shipping, it's done in > the builder. Out of curiosity, just been testing two XO-1s side by side one os850 and one os851. Rough observations (repeated about 12 times): - resuming/starting a sequence of activities after another reliably gets to 9 simultaneous activities (Terminal, Calculate, Log, Pippy, Implode, Chat, Moon, Paint, Memorize) - the tenth activity I happened to be testing, Turtle Blocks, usually triggered an OOM hang of some kind - the OOM hang was usually Turtle Blocks failing to launch. Failed launch would consist of the pulsing startup window, then hanging at a mainly dark grey screen with some partial toolbar light grey fill, non-responsive UI for ~30 seconds to a number of minutes (possibly 5 or 10min), finally you'd be dropped back at the last activity you had successfully launched (Memorize in my test cases). - on three occasions os851 successfully started Turtle Blocks - on one occasion os850 successfully started Turtle Blocks, however on one occasion resuming Turtle Blocks os850 managed to trigger an OOM kill of the Sugar shell resulting in all resumed activities dying and being dropped back at the home fav ring view. - as Turtle Blocks seems a little more memory intensive than some other activities, I tried a few others as the tenth and onward test case. Write as no. ten usually was fine and Distance as eleven. Then trying Maze, or Speak as no. twelve would trigger OOM and the activity would be killed (after some delay, as noted above). - on one occasion trying to start Maze in os850 as activity no. twelve, managed to trigger an OOM kill of the Sugar shell. So, not significant results over just 12 cycles for each XO-1 (need finer grained testing rather than 'number of activities'). Both exhibited long UI lockup's when launching an activity while resources were already maxed out, usually resulting with the activity in question being killed; but os850 did trigger OOM to kill the Sugar shell twice, bringing down all activities with it, where as os851 didn't. --Gary P.S. of corse you'll now tell me os850 was also pre-linked (I couldn't see anything about it in the build notes for either os850 or os851), and I'll look silly for trying to test for a difference, confirming my results were non significant ;-) > -- > James Cameron > http://quozl.linux.org.au/ > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Killing activities when memory gets short
On 11 Aug 2010, at 01:56, Lucian Branescu wrote: > 2010/8/10 NoiseEHC : >> >>> We used to do that, the problem is that we don't control our platform >>> as Google controls Android and you need to make sure that resources >>> that need to be specific of each child process aren't shared (dbus and >>> X connections, etc). >>> >>> I'm personally more interested in reducing the amount of resources we >>> need to start activities (which is quite insane right now), but >>> sharing more of those resources sounds like a good idea to me. >>> >> >> Since I spent quite a bit of time analyzing the Python runtime here is my >> conclusion, maybe it will make wasting all that time less painful. >> >> First, most of the memory consumed by an activity is the process heap. While >> the Python runtime and native libraries are shared among processes, the heap >> is not. Even if you fork processes it will not work because reference >> counting will dirty the shared pages and my instinct tells me that just >> loading a Python source file will reference almost all the shared pages >> because they are mostly used to store already loaded modules. What I finally >> did not do is to actually check the hypothesis that most of the heap is >> filled by strings which are the identifiers in the loaded Python modules. My >> goal was to somehow make identifiers constants and just readonly-mmap them >> into the process (replace the pathetic .pyc loading mechanism). Note that my >> plan was just a little subset of the .jar -> .dex converter. >> >> Second, Python has a special memory manager which works with buckets so >> there are separate heaps for different object sizes. Somehow this special >> memory manager is turned off in release mode and it uses the standard C heap >> for some reason. Either it is a bug or just it turned out to be faster (more >> work was put into glibc) I do not know, but handling the linked free list >> can dirty shared pages as well or I am just mistaken... >> >> Third, the fact that Python is a dynamic language does not help any >> prefetching or memory sharing. I am not too convicted either that this >> dynamic nature is used at all in the Sugar codebase but you know I cannot >> program in Python and frankly I do not feel the need to learn another >> language. Just now, at my age of 34, I finally gave up and learned LISP >> (more specifically clojure) and I hope that it will be the last programming >> language I will have to learn (other than assembly languages of course)... >> :) Now this point is interesting because if you thought that the Dalvik VM >> could run the Sugar codebase via Jython then it just will not work. The >> Dalvik VM just cannot load .jar files and Jython just generates them on the >> fly because of the dynamic nature of Python. >> >> Fourth, moving Python (theoretically) to a GC environment (instead of >> reference counting) also would not work if the GC is compacting because it >> would also dirty the shared pages. So a mark and sweep nonmoving GC with >> separately stored "visited" bits is the only feasible solution. Now guess >> what the Dalvik VM does? >> For more info (45 min + questions): >> http://www.youtube.com/watch?v=ptjedOZEXPM >> >> So *my* conclusion is that solving this sharing problem is *very* hard. I am >> not sure that simply translating all activities from Python to Java would >> take more time. >> >> Another interesting thing is that meantime the unladen-swallow project >> progresses (just more slowly than planned). Their plan is to make it the >> default Python runtime so if it will happen (I cannot comment on that) then >> the Python VM will use even more memory (though it will be faster) so Sugar >> will be even less interesting on the myriad of low spec cheap ARM tablets >> which will flood the market soon. >> >> I think that is all I can say about this subject so I just finish it here. > > The PyPy project has a fully-featured python 2.5 interpreter that has > much lower memory usage and a proper GC (so less dirty pages). They > also have an x86 JIT which makes it much faster than CPython, at the > cost of a bit of memory (still less than CPython). The only issue > right now is extension support: ctypes is fully supported, but > C/Python extension support is not complete by far. FWIW I experimented with PyPy a month or so back to see how fast my self organising map code would run. Needed to make a some code/module changes to get it to work, but it ran about twice as fast. I didn't check if memory usage had improved. --Gary > As for Jython on Android, Jython has a Java bytecode JIT. It should be > entirely possible to write a dalvik backend to this JIT. > > So not only would rewriting everything to Java be a huge step > backwards, but it would also be more work. > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
On 8 Aug 2010, at 15:18, Jon Nettleton wrote: >> >> But the one of core ideas to not use only regular packaging systems >> (via PackageKit or directly) is having this, natural and desired, >> scenario for sugar ecosystem: >> >> * there is an activity, >> * several users might decide to experiment w/ this activity >> (i.e. change its code) and share this results >> * third user wants to try all these experiments (including pristine >> activity) >> >> This scenario is pretty undoable (by design) in native packaging systems >> but 0install is designed to support scenarios like that (all >> activity implementation are stored in separate directories in user's >> home and can be launched in any time and even at the same time). > > This doesn't sound like a package management system scenario. Really > this sounds like a revision control system is needed. Wouldn't it > make the most sense to integrate bzr or git into sugar to handle code > sharing like this? Then you could continue to have all the Activities > in a single directory with multiple branches to can be switched > between on the fly through a sugar interface. FWIW this is certainly the way I've worked on activities in Sugar for some time now, my ~/Activities is mainly git clones. --Gary > -Jon > ___ > olpc mailing list > o...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/olpc ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Killing activities when memory gets short
On 8 Aug 2010, at 01:37, Marco Pesenti Gritti wrote: > On 7 Aug 2010, at 21:08, Tiago Marques wrote: >> Just killing a random activity is a terrible idea becayse you don't want >> your product behaving like it's defective; the pop up idea is way more >> acceptable(and a lot better than having the system randomly behaving like >> it's crashed). Either way, this is the extremely important use of swap >> memory that doesn't exist here. I understand your engineering constraints on >> the hardware but randomly killing activities is poised to confuse users and >> cause people considering the hardware for deployment to think that you're >> selling them something defective/baddly manufactured. > > As long as activities are saving and restoring properly it could be made > pretty much transparent to the user. Of course that's easier said then done... +1, that would be an ideal solution. Minimal interface distinction between active and dormant activities; fast resume (perhaps some visual trickery using the thumbnail image to help cover any delay); improve activity UI state saving. --G > Marco > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Lazy Network Neighborhood updates
Hi Mikus, On 7 Aug 2010, at 20:01, Mikus Grinbergs wrote: >> We already readjust the network neighborhood layout on the fly when we >> switch view. It's funny to see the access points slide around :-) > > Haven't bothered to keep track of the appearance/disappearance of XO and > AP icons in Neighborhood View - it's hard to figure out whether their > presence on screen is determined by View updating or by radio reception. > > But something that needs attention is the handling of "invitation icons" > in Neighborhood view. I would like such an icon to mean "there exists > RIGHT NOW someone else with whom I can collaborate". Instead, these > icons seem to persist long after all invitors/invitees are gone. Nice observation. I'm afraid I seem to rarely use invitations when testing, though I do test Journal file transfers a reasonable amount — which falls into a similar situation. So is this as 'simple' as removing the notification when the activity id is no longer being shared? Or would you like the UI to still indicate that you had missed the event/s? --Gary > Thanks, mikus > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [support-gang] 10 things you should know about Sugar
Hi Mikus, On 3 Aug 2010, at 13:55, Mikus Grinbergs wrote: > Martin is revisiting whether 'Journal' should be considered a "View". > > I think how 'My Settings' is considered should also be revisited. My > problem is that occasionally, due to some situation (which I myself > might have caused), I am unable to bring up Home Circle View. Then, if > I need to change a 'My Settings' parameter, I can at best reboot - in > the hope that that will let me access 'My Settings' again. FWIW, the settings CP dialogue can be accessed from any of your own buddy icons (since Sugar 0.84 I think). So that's from the usual large home XO, your group XO, your neighbourhood XO, or your XO in the right frame. --Gary > I have the feeling that in tomorrow's versions there is an intent to > move control parameters out of 'My Settings' into the toolbar of the > Activity affected by that setting. While that solves the problem of > "easy access to a setting from an Activity", it results in dispersing > discovery of "What things in the system can the user change?". I myself > favor the centralizing of "control knobs", instead of dispersing them. > > But yes, there is a need for easy access to those "control knobs". Now > that (as a result of the High School keyboard) resources such as Journal > (for which there were dedicated keys on the membrane keyboard) are being > assigned to existing "Function Keys", I would like to see 'My Settings' > also be considered a "View", and be assigned its own invocation key. > > > Thanks, mikus > > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [support-gang] Fwd: Redesigning: Library, Read, Get-Books, and Content bundles
Hi Yioryos, Thanks for the extra feedback. You probably won't like my notes below ;) but I thought I'd reply just incase any ring true for you or others. On 22 Jul 2010, at 08:45, Yioryos Asprobounitis wrote: > cc olpc devel > > OK. I'll try to be "technical" but ignore things that are difficult or not > possible at the moment :-) :) > Step 1 is a Library kind of activity, lets all it "tutor" where the user will > be able to aggregate different journal entries from Read, Write, Browse, > Wikipedia, image, video, Physics activity, Pippy etc (you get the idea) and > order them at will. I really hope we can get some Journal tagging improvements in at some point. Seems like a lot of the tag functionality is there and working, but the user experience is not polished enough so it rarely gets used. I think easier Journal tagging workflow would cover this use case. > Step 2 is to embed this activity in the Read and Write activity and present > it optionally in a separate window. Clicking on individual entries > transposes you to the relevant point. I'm going to sound like a broken record ;) again this is just the task the Journal is meant to do in Sugar's design. > Step 3 is to introduce marks (hyperlinks?) in Read and Write where hovering > over you get the tag opened to tell you what is about, and clicking > transposes you to the relevant book/app-mark As noted already this would seem to break Sugars's security model, activities need to be sand-boxed from each other, one activity is not allowed to resume another. Yea, back to Journal, again! ;) > Step 4 is to be able to also write from any application to "tutor", eg when > you add a Journal bookmark to also have the option to add it into a specific > "tutor" and preferably to a specific (order) point. Walter is working on allowing the Journal details view / naming dialogue to be opened at any time from an activity (hopefully merging the two separate bits of code to reduce maintenance at some point). > Step 5 is to be able to "publish" or share your "tutor" the way kids share > class notes. I could bet is going to be a popular activity and actually > better cope with the multitude of learning styles that kids have. Yes, currently the Journal has a 'share with --> friend' feature that works pretty well (as long as an activity sets a mime type for its Journal entries). Requests for actions on multiple Journal entries have popped up rather frequently over the last few Sugar releases (usually for bulk deletions, or bulk copying to and from USB); this would also be ideal for sending multiple Journal entries to a friend. A workflow of something like 1) search Journal for the tags 'math class notes' 2) select all result entries 3) select 'share with --> friend', and bingo, your class mate gets all the notes from the class they had been skiving from all term ;) > Regarding PDF we know that there are applications that allow to highlight, > insert bookmarks, notes or hyperlinks in PDF documents. I do not know if > Envice can do all theses. I just know that is doable. The Mac OS X built in Preview application can do this type of thing, and obviously Adobe's Acrobat products also have similar functionality. I do occasionally use it when reviewing PDF based material, though it does have some limitations. Annotations seem to be rendered into the document, so once saved your annotations can not be removed/edited. I usually end up with a trail of separate documents saved just in case I need to revert. I'm digging around in Reads Epub support at the moment, I'll keep my eyes open for possible annotation support. Regards, --Gary > --- On Wed, 7/21/10, Gary Martin wrote: > >> From: Gary Martin >> Subject: Re: [support-gang] Fwd: Redesigning: Library, Read, Get-Books, and >> Content bundles >> To: "Community Support Volunteers -- who help respond to help AT laptop.org" >> >> Cc: "Andreas Gros" , "Support Gangsters" >> , "Community Support Volunteers -- who help respond >> to help AT laptop.org" >> Date: Wednesday, July 21, 2010, 5:59 PM >> Hi Yioryos, >> >> On 21 Jul 2010, at 18:26, Yioryos Asprobounitis >> wrote: >> >>> I think that he reader does not care if the format is >> this or that (with the exception of plain text that is >> totally unappealing to read, to say the least) or if it is >> this or that component, and not Read that fails. >>> For sure ETexts ability to highlight is OK but >> bookmarking-wise is rudimentary and cross-linking non >> existing. >>> Also whatever bookmarking and commenting the
Re: [IAEP] Redesigning: Library, Read, Get-Books, and Content bundles
On 20 Jul 2010, at 19:33, "Reuben K. Caron" wrote: > There has been a lot of great progress with the Read and Get-Books > (IA) activities. However, we have neglected to think about how we can > better fit all of these pieces together. For instance, consider > deployments that would like to install content bundles. They package > these files into .xol packages and these packages get installed into > the "Library," which is contained on the left hand side of the Browse > activity. Yes, you read that correctly..."the BROWSE activity," an > activity intended for online exploration is used to view offline > content. Every deployment that I have shown this to has found it very > unintuitive. Consider another example: You want to use Get-Books to > get a new book. So you open Get-Books search for a book and download > the book. But where did it go? I guess one could assume (correctly) > that it went to the journal. So you close Get-Books. Go to the > Journal. Find the book you downloaded. Open the book (in Read.) IMHO, > a series of needless steps. > > So what if we created a "Library Activity" > The activity would: > -Open a book from within the activity > -Highlight and annotate books > -List all of the books you have downloaded > -Allow you to search and download additional books from Feed Books, > Internet Archive, the XS, etc.. > -List the resources in /home/olpc/Library (so this can be removed from > Browse) > -Allow one to synchronously or asynchronously share a book to their > Neighborhood so anyone can download and read it. > > I have filed a bug here if anyone would like to follow it: > http://bugs.sugarlabs.org/ticket/2110 > > I look forward to hearing your thoughts. I'm all for keeping activities simple, and then trying to smooth the workflow path when you need to use several in conjunction; however Apple did much as you suggest for their iBooks, a single app that has an epub book shelf, a PDF book shelf, and a store mode for downloading commercial and free ebooks. Read could be extended with a book shelf grid view of all (supported format) books in the Journal, and perhaps integrate download code from one of the get book activities. Would need support from the community as this would make Read harder/larger to maintain... I'd lean towards improving the Journal with a grid view and background sharing, as it could provide much the same thing for _all_ activities not just books (Alekseys Library was along this vector, as are I think his plans for future Journal). Journal is really in need of love, and a plan, for so long now :) Regards, --Gary > Regards, > > Reuben > ___ > IAEP -- It's An Education Project (not a laptop project!) > i...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] behaviour of F-keys on XO HS
On 15 Jul 2010, at 23:59, Tim McNamara wrote: > On 16 July 2010 10:50, Daniel Drake wrote: > Under non-sugar environments (e.g. GNOME), myself and Paul are in > agreement that in order to change brightness and volume, you should > press e.g. Fn+F9 (to decrease brightness). > > This matches behaviour of "normal" laptops, including the Dell that > I'm writing on. Linux already has mechanisms (once through hal, now > through udev) so that when I press Fn+F8 on my Dell, X receives the > "volume down" key press (instead of the Fn+F8 key press), matching > what is printed on the keyboard. > > > This convention appears to be changing. My very recent HP notebook requires > th Fn button to be pushed to reach the function keys. Everything is reversed. +1 on Tim's observation, all three Apple laptops I've owned have brightness/volume/exposé/dashboard/etc mapped by default to a single key press, if you want an Fn key you need to hold the Fn button down. There is a system preference to toggle this behaviour, but the majority of Mac applications avoid the use of function keys (same as most Sugar Activities do). Regards, --Gary > While I don't have the empirical evidence to support a claim that users > prefer to have quick access to volume & brightness, I think this could be an > argument to say that whatever the path of least resistance (in terms of > developer cycles) is fine. > > Tim > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] UI experiments: pop-up menus and hot corners
On 6 Jul 2010, at 10:16, Tomeu Vizoso wrote: > On Tue, Jul 6, 2010 at 05:26, Gary Martin wrote: >> On 6 Jul 2010, at 03:33, Bernie Innocenti wrote: >> >>> On Mon, 2010-07-05 at 17:34 +0100, Gary Martin wrote: >>> >>>> Just showing the name under the pulsing icon might be a useful extra, >>>> but ideally the launch time should be as short as possible so might >>>> look odd briefly flashing up the text (the pulse animation is meant to >>>> be a transition, just unfortunate that most startups are still more >>>> than a second or three). >>> >>> Who would be interested in working on startup optimization? >> >> Well happy to help test, but seems above my technical water line. >> >> Wade experimented (and there are patches in trac I think) with a pulse >> animation effect that was quicker to transition but then paused slightly at >> max/min. Seem to remember it took another ~couple of seconds off startup, >> but never made it through to a release (was part of his work on the activity >> startup failure message that did thankfully land). >> >>> Besides Tomeu's ongoing work on PyGI, I think we could gain a lot by >>> shaving off huge modules such as numpy and sharing pre-rendered svg >>> icons in some memory-mappable cache file. >> >> I didn't think any of Glucose used numpy? I thought it was there for >> Fructose (Activities) only if they needed. FWIW I have a couple of Activity >> projects that would use numpy but I'm not there yet. >> >> Pre-rendering is tricky as both stroke/fill colour, and image size are >> variable. >> >> I was hopeful after seeing Mart Raudsepp's email a week ago to the dev list >> about Cairo's slow rendering on XO hardware (and possible future >> improvements), but Wade pointed out the pulsing animation is currently a >> Hipocanvas thing. > > It was the case some time ago that Hippo would decide to request a > full screen redraw at every pulse, but it was fixed to be smarter > about what needs being redrawn. Or are we talking about another bug in > Hippo? Activity start-up times are significantly better than they used to be, so no specific bug that I'm aware of, was just hopeful of any opportunities to further improve performance Regards, --Gary > Regards, > > Tomeu > >> Regards, >> --Gary >> >>> -- >>> // Bernie Innocenti - http://codewiz.org/ >>> \X/ Sugar Labs - http://sugarlabs.org/ >>> >> >> ___ >> Devel mailing list >> Devel@lists.laptop.org >> http://lists.laptop.org/listinfo/devel >> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] UI experiments: pop-up menus and hot corners
On 6 Jul 2010, at 03:33, Bernie Innocenti wrote: > On Mon, 2010-07-05 at 17:34 +0100, Gary Martin wrote: > >> Just showing the name under the pulsing icon might be a useful extra, >> but ideally the launch time should be as short as possible so might >> look odd briefly flashing up the text (the pulse animation is meant to >> be a transition, just unfortunate that most startups are still more >> than a second or three). > > Who would be interested in working on startup optimization? Well happy to help test, but seems above my technical water line. Wade experimented (and there are patches in trac I think) with a pulse animation effect that was quicker to transition but then paused slightly at max/min. Seem to remember it took another ~couple of seconds off startup, but never made it through to a release (was part of his work on the activity startup failure message that did thankfully land). > Besides Tomeu's ongoing work on PyGI, I think we could gain a lot by > shaving off huge modules such as numpy and sharing pre-rendered svg > icons in some memory-mappable cache file. I didn't think any of Glucose used numpy? I thought it was there for Fructose (Activities) only if they needed. FWIW I have a couple of Activity projects that would use numpy but I'm not there yet. Pre-rendering is tricky as both stroke/fill colour, and image size are variable. I was hopeful after seeing Mart Raudsepp's email a week ago to the dev list about Cairo's slow rendering on XO hardware (and possible future improvements), but Wade pointed out the pulsing animation is currently a Hipocanvas thing. Regards, --Gary > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] UI experiments: pop-up menus and hot corners
On 5 Jul 2010, at 14:13, Bernie Innocenti wrote: > On Mon, 2010-07-05 at 13:29 +0200, James Zaki wrote: > >> But could you add a message hint that then dissappear after some >> seconds ? >> For example, when you launch, and auto-resume last saved work, a >> discrete message appears and after some time dissappear (fade, or >> slide away), say 5 or so seconds. >> For example a title with a button (eg: "This is > title> ..." ["start new instead?"] >> ) that descends from the top just beneath the menu (like web browser >> notifications) Sorry, I couldn't quite follow this. Were you suggesting to use resume as the default behaviour (as it currently is in Sugar) then after your first click, have something else pop up to click on if you want to change your mind (i.e. if you actually wanted 'start new')? Hmm, sounds rather tricky, especially on slow laptops with jumpy mouse cursors and young users. Also technical issues I think as I'm sure when you click, the Activity is being launched with either an existing activity ID to resume, or a new activity ID for a new session — don't think you can pullout of that part way through launching. > Good idea. We could put the activity title in the startup window, below > the glowing icon. Just showing the name under the pulsing icon might be a useful extra, but ideally the launch time should be as short as possible so might look odd briefly flashing up the text (the pulse animation is meant to be a transition, just unfortunate that most startups are still more than a second or three). Regards, --Gary > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] UI experiments: pop-up menus and hot corners
Hi Mikus, On 4 Jul 2010, at 20:23, Mikus Grinbergs wrote: some current (ongoing) future design changes will remove this issue completely with a full screen screen dialogue for deciding new/resume. One click on a home view activity displays a gallery/journal like display of past work or a new blank template >> >> Users ended up launching new activities most of the time bringing the machine >> to it's knees, filling the Journal with junk entries, and then not being able >> to find what they want when they do look in the Journal to resume something. > > What this design change will do is deliberately introduce a 'pause' into > the process of launching an Activity -- to force the user to evaluate > "why am I launching?" What I am wondering is whether "force decision > before launching" is more user-friendly than simply "launch". > > If the problem is "users filling up the machine", No, sorry if I wasn't clear in my explanation, it's not users filling up their disk space that this design effort is trying to resolve (most Sugar activities have very small Journal entries). Having 'start new' as the default home behaviour leads to many concurrently open activities, often bringing the machine to a grinding halt due to OOM. The Journal also fills up with more junk entries (making it harder to search though and find work to resume from). > will making it more > difficult to launch a new instance be an adequate solution ? The new design strives to make resuming and 'start new' behaviours of equal priority in the UI. The current version of Sugar has resume as the default behaviour (since 0.84) in an attempt to resolve the flood of deployment feedback about the above mentioned lockups due to OOM and Journal spam. We now have feedback that 'start new' is too hidden and that kids are often resuming recent work and manually erasing the canvas to start something new (I've seen this happen first hand, child asks in Paint how to make a big brush, and then paints out their previous work with white; also I've started to see requests for activities to have a clear all tool button for much the same reason). So the new design work will make 'start new' more visible than with the currently released Sugar. > Will the > kid who wants to make a new drawing on Tuesday be content with resuming > the activity he used Monday -- thereby wiping his drawing from Monday ? She might want to paint some more on Mondays painting, or start something new. We're trying to put that choice equally up front for her before the activity launches, though I accept this adds an extra click/decision to every activity invocation. FWIW: We could leave in the alt-click 'start new' home short cut for those expert users who know they want a fresh activity session and no dialogue. > Forcing a decision on every launch may work -- but there still needs to > be a user-helpful way to address "I've filled up the machine" when that > happens -- for those who nevertheless persist in overusing "new launch". Yes, this is a separate design issue we are not trying to fix with this specific work. There are already a couple of features. One is that a warning dialogue pops up when you've filled N% of your flash, and switches you to the Journal and asks for you to remove things — it's better than nothing but I've not found it useful so far, it keeps dragging you back to the Journal view, usually I'm trying to get back to Terminal to stop a yum, a git clone, a file curl/wget :) The other is I think something new Bernie has been experimenting with, basically a last chance saloon script that auto deletes some activities, so that the machine can at least be booted. Regards, --Gary P.S. We keep slipping on a date/time for the next irc #sugar-meeting design meeting, folks are most welcome, Christian has some nice mockups he's been polishing up for publication. We're trying again for tomorrow/Monday, but no time confirmed just yet. > [Would an "ultimate" design propose to make the machine be the master > over the user -- and employ this full screen launch dialogue to refuse > launch whenever the machine approaches "being brought to its knees" ??] > > mikus > > > p.s. > The Journal user-interface was invented, with a "filter" capability. > Now a full screen dialogue user-interface would be duplicating what the > Journal can show. I myself am not comfortable with duplication. > > ___ > olpc mailing list > o...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/olpc ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] UI experiments: pop-up menus and hot corners
Hi Mikus, On 4 Jul 2010, at 06:45, Mikus Grinbergs wrote: >> The down side is that every activity start would be then be two clicks, one >> to bring >> up the large dialogue (I like to think of it as a one page gallery), and one >> for new >> or resume choice... But that was partly the point, no one here could agree >> on a new >> or resume default behaviour, so there needs to be an extra user end >> decision, just to >> settle the UI feud and allow us move on, to more gainful tasks. > > If the user needs to choose case-by-case whether to launch new or > resume, if he wants to "resume" he can go to Journal (one click) and > launch from there (second click) -- whereas if he wants to launch new he > can go to Home, hover, and (one click) 'Start' in the existing palette. That's how the Sugar UI used to be. Users ended up launching new activities most of the time bringing the machine to it's knees, filling the Journal with junk entries, and then not being able to find what they want when they do look in the Journal to resume something. > For those users who consistently "resume" all the time, provide a > setting within the control panel to override the directly_on_Home_icon > first-click behavior (perform "launch new" vs. "show menu of resumes"). > If "frame" behavior can be specified by user, so should "home" behaviour I think that choice needs to be much closer and explicit in the new/resume user action, it's a choice you make each time based on your current goal. Pushing that choice into the CP would be pushing the default choice to deployers making builds who would then be stuck in the same loop (default resume == kids often manually wipe past work; default new == kids often OOM machines and fill Journal with junk entries). Regards, --Gary > My $.02 mikus > > ___ > olpc mailing list > o...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/olpc ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] UI experiments: pop-up menus and hot corners
Hi Mikus, On 4 Jul 2010, at 04:32, Mikus Grinbergs wrote: >> some current (ongoing) future design changes will remove this issue >> completely with >> a full screen screen dialogue for deciding new/resume. One click on a home >> view activity >> displays a gallery/journal like display of past work or a new blank template > > My observation - on the XO, there is a VERY perceptible time lag between > when the user makes a click (on an existing screen) and when the > replacement screen gets presented to that user. [It would not be so bad > if the cursor changed shape to indicate "the system is working on your > input" -- but as it is, the XO display might "freeze", or even switch > (temporarily) to a completely unrelated session -- and the user must > mentally refrain (for up to a number of seconds) from doing anything > while waiting to see whether the expected screen will/will_not be shown. > > [This time lapse in preparing a new full screen display on the XO seems > to be worse with metacity than with matchbox. For instance, with > Paraguay's sugar 0.88 builds, the "activity being launched" screen > sometimes never gets to pulse -- apparently, to get it shown might take > as long as it does to prepare the actual activity session's screen !!] > > > A major advantage of the menu (palette) on the XO is that as soon as the > user clicks within that menu, the menu itself vanishes. This gives the > user IMMEDIATE visual feedback that "the system is working on your > input" - and removes the "what is it doing?" doubt from the user's mind. I do feel the pain... But the fullscreen dialogue should do no more than the current hover palette, there is no excuse for its code to being perceptibility slower. It's not starting up the activity or triggering an enema of module imports and dbus messages, it's just showing a full screen 'new or resume past instance' UI, with pretty much just the same content as the current 'weight and then fight with the cursor' mini palette. The down side is that every activity start would be then be two clicks, one to bring up the large dialogue (I like to think of it as a one page gallery), and one for new or resume choice... But that was partly the point, no one here could agree on a new or resume default behaviour, so there needs to be an extra user end decision, just to settle the UI feud and allow us move on, to more gainful tasks. Regards, --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Sugar with a virtual (onscreen) keyboard
On 30 Jun 2010, at 00:18, "C. Scott Ananian" wrote: > On Tue, Jun 22, 2010 at 4:28 PM, Sayamindu Dasgupta > wrote: >>> - Ideally something (Gnome I assume?) should trigger the keyboard overlay >>> when you focus on a text field, perhaps with some hints about what the >>> 'return' key behaviour should do (or expose a tab key as that is usually >>> the other common text field navigation method). Dismissing the keyboard >>> overlay when a text field is defocused would also be ideal. >> >> AFAIK, this requires a GTK+ module to be loaded. I'm still trying to >> write a proof of concept implementation of this - it seems that >> there's no documentation anywhere for writing GTK+ modules :-( > > Yeah, I gave up and just used LD_PRELOAD when I had this problem. If > you want to try the quick-and-dirty way for a proof of concept, this > might be handy: > http://dev.laptop.org/git/users/cscott/journal2/tree/ > > Do all of firefox/xulrunner/chrome use GTK widgets for text entry? > I'm nervous that some programs might not pop up the keyboard > appropriately. > > You could add a gesture to force the keyboard up even for badly > behaved applications. I think the iPad/iPhone gesture for that is > dragging your finger from the bottom of the screen to the top. FWIW: There is no global system gesture or button on the iPad for revealing the virtual keyboard. Selecting any text widget will reveal it; app developers can programatically reveal it (say if they have a custom canvas, our Labyrinth activity would fall in this category); a few individual apps from 3rd parties (none I can see from Apple) have added their own floating semi transparent keyboard icon usually in the far lower right screen corner, in one case (a text chat app) this just seems like poor design, in the others I can remember it's for cases where there is no sane way to know if the keyboard is needed (VNC, RDP clients). There are no keyboard only iOS devices, and all app developers knew from day 1 that devices were touch only, so we are in a slightly different position with needing to support both key and keyless devices, and activities that were written without touch input in mind... So I'm sure we will need a fallback button. Sayamindu device frame seems a good choice, once we have a touch gesture to reveal the frame that is ;) Anyone know what the planned physical buttons may be for the XO-3? If Sugar was native on iPad hardware, I'd certainly want the single home button to reveal the frame, with perhaps a double click of it switching to the Sugar favourites ring view. Regards, --Gary > --scott > > -- > ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Sugar with a virtual (onscreen) keyboard
Hi Sayamindu, On 29 Jun 2010, at 22:25, Sayamindu Dasgupta wrote: > On Wed, Jun 23, 2010 at 1:58 AM, Sayamindu Dasgupta > wrote: >> On Fri, Jun 18, 2010 at 9:04 AM, Gary Martin >> wrote: >>> Hi Sayamindu, >>> >>> On 17 Jun 2010, at 13:16, Sayamindu Dasgupta wrote: >>> >>>> [Apologies for the cross-posting] >>>> >>>> Hello, >>>> Thanks to the pointers provided by Peter Robinson, I got the Meego >>>> FVKBD (Free Virtual Keyboard)¹ running along with Sugar. >>>> A problem with the current FVKBD is that it supports only one base >>>> layout. Even "variants" of that layout (eg: CapsLock enabled, Symbols, >>>> etc) are treated as "temporary", which means that you press the "Caps" >>>> key, enter a capital letter, and immediately after that, it gets reset >>>> back to the base layout (lower case qwerty). >>>> I wanted something which would be similar to the existing physical >>>> keyboards that we ship with the XO machines - with a dedicated key to >>>> switch between different scripts in the same keyboard. I had to extend >>>> the code of FVKBD to implement that, and with the modified FVKBD, I >>>> have spun a live-cd ISO (based on the current SOAS). You can download >>>> it from >>>> http://dev.laptop.org/~sayamindu/sugar-vkbd-test/sugar-vkbd-test.iso >>> >>> Wow, big thanks for launching into this. For anyone not sure how to try the >>> iso, I'm on a Mac and just used Virtual Box to create a new empty Fedora >>> VM, no HD, and just point to the iso as the boot CD. Started up just fine, >>> keyboard is already open to type in your user name (of course this is all >>> read only, any changes you make will be gone after a reboot). >>> >> > > <...snip> > >>> >>> Sayamindu, what kind'a feedback/assistance would be most useful? Is it too >>> soon to start collating notes and screen shots on a wiki page somewhere? >> >> Yes - I think we should start putting all of this in a wiki. >> > > I have put in some of my thoughts and ideas into the wiki : > http://wiki.sugarlabs.org/go/Features/Onscreen_Keyboard Thanks, that's a good set of notes. I'll add some of my scrawl to the talk page. FWIW: My iPad testing using RDP has only been partially successful so far. Have been using the iTap RDP client to connect to the Virtual Box built in RDP support: Pros: Pretty fast for a remote session; no redraw or graphics issues; can run the VM headless from the host; sound is remotely relayed (half second delay so not too great for UI feedback testing); uses 100% fullscreen so a 1024x768 Sugar VM looks great on an iPad (iTap uses three finger gestures to invoke its local onscreen controls so you can pretend they don't exist). Cons: Mouse cursor for clicks are not aligned correctly most of the time (still trying to track this issue down, may be client vs. host pointer related); due to the cursor alignment issues you need to invoke a hold gesture to drag the visible cursor to where you want to make a click (slow and defeats the goal of touch screen testing); iPad main virtual keyboard not correctly communicating with the VM (all the custom iTap keys work, esc, function keys, ctrl, alt, cursors etc, but the main keyboard letters do not get through) — which makes using your fvkbd image a must have ;) Regards, --Gary > Thanks, > Sayamindu > > -- > Sayamindu Dasgupta > [http://sayamindu.randomink.org/ramblings] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Cairo's slow rendering on XO-1 (was: olpcgames - mainloop bug help)
Hi Wade, On 28 Jun 2010, at 15:10, Wade Brainerd wrote: > I developed a couple of activities using Cairo that I later ported to > other drawing solutions. The possible performance test candidate that sprang to mind when reading Mart's email was the work you put in on the pulsing activity icon animation. Can you recall if Cairo is the bottleneck there or was it something else? Regards, --Gary P.S. Great to see you about again on the list recently. > One is Bounce (a three dimensional Pong game). > > git://git.sugarlabs.org/bounce/mainline.git > > I didn't tag it, but commit 7b7abf5 was the last version using cairo. > I'll likely port this to Sugargame when I find time. > > > Another is Yay! Bee See, an alphabet program for younger children. > > git://dev.laptop.org/users/wadeb/yay-bee-see > > I've been working on porting this to Sugargame too, and adding editing > features (e.g. the ability to replace the images and sounds for each > letter, and to save to the journal) > > > For a time, Typing Turtle used cairo to render its keyboard with > overlaid hand SVGs. > > git://git.sugarlabs.org/typing-turtle/mainline.git > > The last version to use cairo was v5. I switched to caching bitmap > images of each key and the hand overlays to make the keyboard keep up > while typing at a reasonable pace. > > > All of these would probably make a pretty good cairo performance tests > on XO-1. > > > -Wade > > On Mon, Jun 28, 2010 at 5:17 AM, Peter Robinson wrote: >> On Mon, Jun 28, 2010 at 10:13 AM, Dov Grobgeld >> wrote: >>> Not sure this is relevant, but I have found that for software rendering >>> (without hardware acceleration) agg (anti-grain graphics) is a lot faster >>> than cairo. At least it was when I benchmarked them a couple of years ago. >>> See: http://www.antigrain.com/ . >> >> There's been a lot of changes and improvements in cairo using HW accel >> since then. >> >> Peter >> >>> On Mon, Jun 28, 2010 at 12:03, Bert Freudenberg >>> wrote: On 28.06.2010, at 09:21, Sascha Silbe wrote: > Excerpts from Mart Raudsepp's message of Mon Jun 28 06:37:31 +0200 2010: > >> Currently we (primarily two AMD employees, not so much me) are >> concentrating on fixing some of the awful bugs (many of which get >> triggered only by a newer xorg-server version), such as misrendering >> with HwAccel and rotation issues. After those are hopefully fixed soon, >> some attention will probably start to go on hardware acceleration >> performance, as the current situation is indeed rather sad: >> http://people.freedesktop.org/~leio/geode/perf/ > > Awesome (that somebody is going to work on it), thanks! > > Sascha Yay indeed! - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel >>> >>> >>> ___ >>> Devel mailing list >>> Devel@lists.laptop.org >>> http://lists.laptop.org/listinfo/devel >>> >>> >> ___ >> Devel mailing list >> Devel@lists.laptop.org >> http://lists.laptop.org/listinfo/devel >> > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Removing 'share' option from activites that don't know how to share
On 25 Jun 2010, at 20:27, Daniel Drake wrote: > Here is the list > > > - Implode (No comparte en ninguna version) > - Paint (No comparte en ninguna version) > - Labyrinth Oh joy, interesting, so it's just0.84 that's borked up, Labyrinth is correctly disabling the share feature under 0.82 and 0.88. Regards, --Gary > - Flipsticks > - Cuerpo Humano > - English for Fun > - JigsawPuzzle (no comparte en version 0.84 pero si en 0.82) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Removing 'share' option from activites that don't know how to share
On 24 Jun 2010, at 16:20, Martin Langhoff wrote: > Talking with the Perú team a few days ago about F11/S0.84 (both on > xo-1.5 and xo-1) > > Teachers and testers were very confused with the 'share' option in > activities where sharing does nothing, or is seriously buggy. To avoid > confusing users, they are looking into removing the 'share' option > from most activities. > > This is practical and executive for them short-term; of course the > right fix is for activities do call up the 'share' option only where > actual sharing code exists and is known to work... > > What is the right fix? Do we want a list of activities where it should > be removed, and prod the maintainers, and only file bugs for those > that don't respond soonish? Making a list of the offenders and posting would be a start, but remember to state the release you are targeting/testing. Here's a likely large chunk of the problem... For Sugar 0.86 and above the new toolbars will disable the sharing UI with: self.max_participants = 1 For Sugar 0.82 the trick was: activity_toolbar = toolbox.get_activity_toolbar() activity_toolbar.share.props.visible = False For Sugar 0.84 the trick seems to be: activity_toolbar = toolbox.get_activity_toolbar() activity_toolbar.share.hide() I've not noticed an elegant way to detect Sugar versions other than try: except: clauses around some newer modules, with fallback to 0.82 code. Anyone point to a specific activity doing this type of thing nicely? Regards, --Gary > (The above would be an informal copy of the "mass bug filing" protocol > @ Debian.) > > > 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-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Keep confusion -- round N+1
On 24 Jun 2010, at 09:45, NoiseEHC wrote: > >> After making tests [1] in deployments for "start new" >> vs. "resume" we concluded that the way activity starting works on the >> iPhone would probably work well in Sugar, too [2]. >> > > Hehe, this is exactly the thing you would get with per-activity > datastores. Guess what, Android does this too. :) Not to mention that an > object chooser for pictures could be totally different from an object > chooser for ftp sessions for example. Well, 'per-activity data stores' sounds like a large rewrite for the data-store, Journal, and every activity... i.e. not very likely. The 'start new vs. resume' design tries to provides a similar work flow but with minimal possible changes - it's pretty close to just moving the current hover palette functionality into a larger object chooser type dialogue. Hmmm, I wonder if we could/should augment the object chooser to also cover this case? Also worth taking note that the Apple iOS approach of letting the app deal 100% with the presentation of files/objects gives a real mixed bag of different attempts from each app developer, some do great work, others are rather confusing/weak, some don't bother at all. There is certainly little consistency when using one app vs. another, you have to re-learn what features are available and where the developer decided to place them. Regards, --Gary > > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Keep confusion -- round N+1
On 24 Jun 2010, at 00:07, Daniel Drake wrote: > On 23 June 2010 15:49, Martin Langhoff wrote: >> Continuing on the tradition of "Keep confusion, yet again" thread >> http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023440.html >> >> I was yesterday in a conf call with the Perú team, who had been >> working with teachers and were reporting a "keep" bug on F11/S0.84 >> images. >> >> What was very clear was that both technical team and teachers were >> confused about the keep button; and they were seeing a bug that >> increased their confusion. > > Yep, I'm here in peru and they are facing the same confusion as i've > seen all over the world. > This button needs to go away. +1, it's been a horrible confusing design call even assuming the Journal had version support implemented. FWIW the iPad UI deals with this just great (in at least iWorks apps to my knowledge), the regular undo just works between session if you happen to want to reverse or redo a change you did yesterday. There is no extra keep step, your edit sessions are presumed continuous in time. There's even a mind mapping app I use that goes the extra step and allows you to select past edit states by modification time, not something I'd see as a common need but still an interesting extra (only time I've made use of it is to revert a document right back to the original state). > Here in Peru they are modifying all of the 30 activities on the laptop > to remove the Keep button. (with a little care for the ones where it > has alternative functions such as Write -- thats why you can't just > take it out of the activity class altogether) Ouch :( But that is really good 'feedback', I was very glad when Keep moved into the activity sub menu for the new toolbar design, out of primary sight at last, at least... Perhaps we can get agreement to upstream such changes and save deployments such efforts. --Gary > > Daniel > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Sugar with a virtual (onscreen) keyboard
Hi Sayamindu, On 17 Jun 2010, at 13:16, Sayamindu Dasgupta wrote: > [Apologies for the cross-posting] > > Hello, > Thanks to the pointers provided by Peter Robinson, I got the Meego > FVKBD (Free Virtual Keyboard)¹ running along with Sugar. > A problem with the current FVKBD is that it supports only one base > layout. Even "variants" of that layout (eg: CapsLock enabled, Symbols, > etc) are treated as "temporary", which means that you press the "Caps" > key, enter a capital letter, and immediately after that, it gets reset > back to the base layout (lower case qwerty). > I wanted something which would be similar to the existing physical > keyboards that we ship with the XO machines - with a dedicated key to > switch between different scripts in the same keyboard. I had to extend > the code of FVKBD to implement that, and with the modified FVKBD, I > have spun a live-cd ISO (based on the current SOAS). You can download > it from http://dev.laptop.org/~sayamindu/sugar-vkbd-test/sugar-vkbd-test.iso Wow, big thanks for launching into this. For anyone not sure how to try the iso, I'm on a Mac and just used Virtual Box to create a new empty Fedora VM, no HD, and just point to the iso as the boot CD. Started up just fine, keyboard is already open to type in your user name (of course this is all read only, any changes you make will be gone after a reboot). I'll try and spend some time in the next few days using it via iPad HW and send some feedback, just been playing via mouse so far today. > Apart from the modified FVKBD, I have added a default keyboard > definition file which is for English + Bengali, and I've also included > a sugar device-icon on the frame to control the appearance of the > keyboard. > > I realize that more needs to be done to support non Latin scripts, and > here are some of the issues I faced while converting the existing XKB > Bengali layout: > > * Many scripts do not have a concept of upper case/lower case - so we > need some other script specific way to divide the characters > * In the current XKB configurations, non-symbol characters from other > scripts are often placed in the position of what normally is symbols > for QWERTY keyboards > * Numerals pose an interesting problem, since in some places, native > numerals/digits are quickly being obsoleted, and latin numerals > (1,2,3..) are becoming the de-facto standard. In these cases, it may > make sense to provide only _one_ layout/state for numerals, and allow > users to input native numerals by hovering (touch + hold) on the > virtual key for the latin digit. > > Among the general issues, I'm not sure how to deal with the keyboard > taking up half of the screen real estate - it may be worthwhile to see > if we can have a "split screen" sort of configuration while the > keyboard is active. It didn't bother me too much, and this was in an 800x600 session, though ideally we would want the text insertion point to be visible above the keyboard (FWIW various iPad apps have different success in dealing with this, all of Apple's are fine, but it seems 3rd parties do need to do some work on the app side to keep this behaviour working at all times). > Thoughts, feedback, etc would be appreciated :-). Yes, lot's of interesting items to cover :-) I'll try to start to put together a list. Some quick item that struck me right away: - the Meego keyboard design is clearly for casual typing/text entry, no way of typing commands or many symbols needed for basic programming work – diving into terminal to use vi, or worse emacs, is pretty much a dead end (unless ctrl and alt keys are hidden somewhere I couldn't find). Is it flexible enough to allow different activities to trigger different keyboards (or an extra row of custom keys)? Something like Pippy, or Terminal would need that kind of extra flexibility. - z layering issues with frame, should it be over, under, part of? Currently it can be a mix depending on the sequence things are triggered. - Ideally something (Gnome I assume?) should trigger the keyboard overlay when you focus on a text field, perhaps with some hints about what the 'return' key behaviour should do (or expose a tab key as that is usually the other common text field navigation method). Dismissing the keyboard overlay when a text field is defocused would also be ideal. - The 'grapes' icon particularly (and some others) could do with with some sugar-love ;) Do you think those should be upstreamed? Or do we have many other unique requirements (enough to fork) that the Meego platform isn't looking to support? OT: one thing I really miss on the iPad even after a few weeks solid use, is the omission of cursor keys for small adjustments in text cursor positions or text selections. Text editing, even on an iPad with its auto correction, and realtime frame redraw perfect tap and hold magnifying glass effect can be frustrating. I think cursors are still important keys to have if we expect children
Re: multi-touch
On 11 Jun 2010, at 04:14, Peter Robinson wrote: > On Tue, Jun 8, 2010 at 4:05 PM, Gary Martin wrote: >> On 8 Jun 2010, at 09:53, "C. Scott Ananian" wrote: >> >>> On Tue, Jun 8, 2010 at 4:20 AM, Carlos Nazareno wrote: >>>> If possible, go for a minimum of 5 touch points capability, which is >>>> what Apple has I think. >> >> Yes, it would be good to keep in mind a likely use case where two children >> interact with one device screen (example, the various split screen piano >> apps on the iPad where two people can play face to face). >> >> Regards, >> --Gary >> >> P.S. Anyone have RDP working on an iPad with Sugar in a VirtualBox? I have >> it working OK via VNC for UI testing, but RDP would allow passing over >> audio, and allow the Sugar VM to be run headless. > > I believe itap is a very good RDP client for the ipad. Thanks Peter. Quick update, it's either itap or Desktop Connect. I've emailed both about Virtual Box support. itap folks kindly/honestly say VB is not yet properly supported, with some users reporting success but others reporting severe graphical problems — say they will officially support VB in a future release. Desktop Connect folks gave me a slightly open response of 'yes this should work fine with Desktop Connect V 2.0, please let us know if you experience any issues.' [Damn, just been out for drinks with a whole swarm of iPad/iPhone developers, I knew there was something else I should have been picking their brains over] Regards, --Gary > Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Reason for the "one dot" hang found!
On 10 Jun 2010, at 20:53, Daniel Drake wrote:
> On 10 June 2010 10:58, Bernie Innocenti wrote:
>> Hello,
>>
>> with the serial cable Richard gave me, I figured out what's causing a
>> rare lockup during boot which has been riddling the XO-1 since when we
>> moved to F11.
>>
>> The /etc/rc.sysinit script contains this line:
>>
>> # Sync waiting for storage.
>> { rmmod scsi_wait_scan ; modprobe scsi_wait_scan ; rmmod scsi_wait_scan ;
>> } >/dev/null 2>&1
>>
>> It gets executed while udev is loading modules in parallel. Apparently,
>> something in the kernel ends up dead-locking on module load:
>>
>>
>> 1 tty1 Ss+0:02 /sbin/init
>> 945 ?Ss 0:00 /bin/sh -e -c ?runlevel --set S >/dev/null ||
>> true???/
>> 950 ?S 0:00 \_ /bin/bash /etc/rc.d/rc.sysinit
>> 1597 ?D 0:00 \_ modprobe scsi_wait_scan
>
> I strongly doubt this is the issue. This is a very simple module.
>
> Note your other blocked process:
>
>> 1035 ?D< 0:00 /sbin/modprobe -b
>> pci:v11ABd4102sv11ABsd00
>
> This one also has a lower process ID, suggesting that it was run first.
>
> I suspect there is a crash/hang within this module, and at this point,
> attempting to load any other module (scsi_wait_scan or otherwise) will
> hang. Due to contention on a lock, corruption, a dead kernel thread,
> or something like that.
>
> My suggested next steps in diagnosis:
> 1. Identify which device is pci:v11ABd4102
> Anyone can do this on any XO-1 with: lspci -vd 11ab:4102
> I'm pretty sure its a part of the CAFE chip but I don't have an XO to check.
00:0c.2 Multimedia video controller: Marvell Technology Group Ltd. Unknown
device 4102 (rev 10) (pro-if 01)
Subsystem: Marvell Technology Group Ltd. Unknown device 4100
Flags: bus master, 66MHz, medium, latency 32, IRQ 11
Memory at fe028000 (32-bit, non-prefetchable) [size=16K]
Capabilities:
Kernel driver in use: cafe1000-ccic
This is from an XO-1 running build 767, Sugar 0.82.1, firmware Q2E18.
Regards,
--Gary
> 2. Look at dmesg at point of crash
> Considering that you got a process tree I guess you can also run some
> other commands at point of hang?
> Run "dmesg" and capture output.
>
> 3. Capture kernel task dump at point of crash
> echo t > /proc/sysrq-trigger
> The task dump will appear in kernel logs (dmesg).
>
> Daniel
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: multi-touch
On 8 Jun 2010, at 09:53, "C. Scott Ananian" wrote: > On Tue, Jun 8, 2010 at 4:20 AM, Carlos Nazareno wrote: >> If possible, go for a minimum of 5 touch points capability, which is >> what Apple has I think. Yes, it would be good to keep in mind a likely use case where two children interact with one device screen (example, the various split screen piano apps on the iPad where two people can play face to face). Regards, --Gary P.S. Anyone have RDP working on an iPad with Sugar in a VirtualBox? I have it working OK via VNC for UI testing, but RDP would allow passing over audio, and allow the Sugar VM to be run headless. > Apple actually supports 11 on the iPad. Palm and the iPhone support 5. > http://daringfireball.net/linked/2010/05/10/gemmell-multitouch > --scott > > -- > ( http://cscott.net/ ) > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
