Re: [Sugar-devel] seeking help to enable nepali keyboard input for XO-4
On 8 Nov 2013, at 14:24, Chris Leonard cjlhomeaddr...@gmail.com 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 basanta.shres...@olenepal.org 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 walter.ben...@gmail.com 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 basanta.shres...@olenepal.org 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 w...@laptop.org 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 t...@carrott.org 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. powerlogs.tar.bz2___ 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 a...@activitycentral.com 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', do
something interesting) 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 jon.nettle...@gmail.com wrote: On Feb 12, 2013 2:43 PM, Walter Bender walter.ben...@gmail.com wrote: On Tue, Feb 12, 2013 at 8:41 AM, Simon Schampijer si...@schampijer.de 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 p...@laptop.org 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 christoph.derndor...@gmail.com 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 a...@activitycentral.com 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 garycmar...@googlemail.com
wrote:
On 28 Jan 2013, at 18:33, Gonzalo Odiard gonz...@laptop.org wrote:
On Mon, Jan 28, 2013 at 2:50 PM, Ajay Garg a...@activitycentral.com wrote:
On Mon, Jan 28, 2013 at 11:01 PM, Paul Fox p...@laptop.org 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 p...@laptop.org 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
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
On 28 Jan 2013, at 18:33, Gonzalo Odiard gonz...@laptop.org wrote:
On Mon, Jan 28, 2013 at 2:50 PM, Ajay Garg a...@activitycentral.com wrote:
On Mon, Jan 28, 2013 at 11:01 PM, Paul Fox p...@laptop.org 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 p...@laptop.org 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 (test_bit(keycode, state))
return 10; /* different from EXIT_FAILURE */
else
return 0;
}
paul
Gonzalo
On Thu, Jan 24, 2013 at 12:16 PM, Martin Langhoff
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
On 23 Jan 2013, at 15:29, Walter Bender walter.ben...@gmail.com wrote: On Wed, Jan 23, 2013 at 1:20 AM, Ajay Garg a...@activitycentral.com 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 walter.ben...@gmail.com wrote: On Thu, Jan 10, 2013 at 2:04 PM, Anish Mangal an...@sugarlabs.org 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 ber...@codewiz.org 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 lionaneesh-andro bernie: Could you help me takeover maintainership of an inactive activity? bernie lionaneesh-andro: ask alsroot, he maintains aslo * alsroot only maintains aslo, dirakx was taking care about aslo content bernie lionaneesh-andro: gonzalo_odiard and garycmartin are the activity team coordinators. bernie 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 bernie lionaneesh-andro: please, write to sugar-devel@ and cc me, alsroot, gonzalo and gary. lionaneesh-andro 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 ___ 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 22:41, Daniel Drake d...@laptop.org wrote: On Sun, Dec 16, 2012 at 8:58 PM, Gary Martin garycmar...@googlemail.com wrote: Hi Daniel, On 16 Dec 2012, at 20:49, Anna ascho...@gmail.com 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 ascho...@gmail.com 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 d...@laptop.org 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 jv.ravichand...@gmail.com 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 si...@schampijer.de wrote: Am 20.11.2012 um 06:23 schrieb Martin Langhoff martin.langh...@gmail.com: On Mon, Nov 19, 2012 at 11:58 PM, Chris Leonard cjlhomeaddr...@gmail.com 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 b...@freudenbergs.de 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: 13.1.0 development build 9 released
On 4 Nov 2012, at 11:08, Peter Robinson pbrobin...@gmail.com 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: Maliit ticket location
Hi Daniel, On 5 Nov 2012, at 19:29, Daniel Drake d...@laptop.org 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: Opportunities to slim down 13.1.0 build file cruft
Hi Peter, On 17 Oct 2012, at 19:40, Peter Robinson pbrobin...@gmail.com wrote: On Wed, Oct 17, 2012 at 7:17 PM, Gary C Martin garycmar...@googlelibgweathermail.com 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 gonz...@laptop.org 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 hmur...@megapathdsl.net 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: Testing Summary - Auckland 13 October 2012
Hi Tabitha, On 13 Oct 2012, at 08:52, Tabitha Roder tabi...@tabitha.net.nz 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 started to progress but it didn't Maze works Browse works but clicking in the
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 pbrobin...@gmail.com wrote: On 8 Oct 2012 00:41, Gary Martin garycmar...@googlemail.com wrote: On 7 Oct 2012, at 23:56, Peter Robinson pbrobin...@gmail.com wrote: On 7 Oct 2012 23:17, Martin Langhoff mar...@laptop.org wrote: On Sun, Oct 7, 2012 at 5:22 PM, Peter Robinson pbrobin...@gmail.com 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: F18/os4 on XO-1 [Devel Digest, Vol 79, Issue 37]
Hi Gonzalo, On 1 Oct 2012, at 06:55, Gonzalo Odiard gonz...@laptop.org 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
Re: 13.1.0 feature freeze reminder
Hi Walter, On 28 Sep 2012, at 01:18, Walter Bender walter.ben...@gmail.com wrote: On Thu, Sep 27, 2012 at 5:46 PM, Daniel Drake d...@laptop.org 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 launch-time.patch___ 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 Summary, Auckland - 23 June 2012
On 14 Jul 2012, at 23:52, Daniel Drake d...@laptop.org wrote: On Sat, Jul 14, 2012 at 2:43 AM, Tom Parker t...@carrott.org 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 div class=”rellink relarticle mainarticle” 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: [Testing] Testing Summary, Auckland 14 July 2012
Hi Tom, On 15 Jul 2012, at 12:27, Tom Parker t...@carrott.org 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. powerlogs.tar.bz2 ___ 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: 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 walter.ben...@gmail.com wrote: On Mon, May 21, 2012 at 6:44 AM, Sascha Silbe si...@activitycentral.com wrote: Walter Bender walter.ben...@gmail.com 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 d...@laptop.org wrote: On Sat, Mar 24, 2012 at 4:56 PM, Peter Robinson pbrobin...@gmail.com 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 d...@laptop.org wrote: On Sat, Mar 24, 2012 at 4:56 PM, Peter Robinson pbrobin...@gmail.com 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 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 mar...@laptop.org 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: 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: 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 srid...@laptop.org.au 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: - OFWEC 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 kgordon...@gmail.com 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
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 pbrobin...@gmail.com 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: 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: [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 garycmar...@googlemail.com 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: XO 1.75 os4 display
Hi Sameer, On 11 Sep 2011, at 02:32, Sameer Verma sve...@sfsu.edu 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: [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 mar...@laptop.org wrote: On Thu, Jul 28, 2011 at 4:03 PM, Martin Langhoff mar...@laptop.org 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 d...@laptop.org 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(knowing that no labels are used). In addition, save the entries as a record of what thechild
Re: 11.2.0 release notes ready for review
Hi Alan, On 21 Jul 2011, at 00:37, Alan Jhonn Aguiar Schwyn alan...@hotmail.com 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 alan...@hotmail.com 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, 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: [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: 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: XO-1 touchpad once more
On 13 Jun 2011, at 20:36, Yioryos Asprobounitis mavrot...@yahoo.com 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 satel...@bendbroadband.com 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 XO-1.5-Activity Tests.ods ___ 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 qu...@laptop.org 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 pbrobin...@gmail.com 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 e...@laptop.org 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 garycmar...@googlemail.com
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/G1G1action=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 mi...@bga.com 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
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 18:42, Paul Fox p...@laptop.org 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
On 11 Aug 2010, at 01:56, Lucian Branescu lucian.brane...@gmail.com wrote: 2010/8/10 NoiseEHC noise...@freemail.hu: 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 ___ 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 ma...@marcopg.org wrote: On 7 Aug 2010, at 21:08, Tiago Marques tiago...@gmail.com 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] Activity packaging
On 8 Aug 2010, at 15:18, Jon Nettleton jon.nettle...@gmail.com 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] Lazy Network Neighborhood updates
Hi Mikus, On 7 Aug 2010, at 20:01, Mikus Grinbergs mi...@bga.com 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 mi...@bga.com 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 mavrot...@yahoo.com 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 garycmar...@googlemail.com wrote: From: Gary Martin garycmar...@googlemail.com 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 support-g...@lists.laptop.org Cc: Andreas Gros andigro...@googlemail.com, Support Gangsters support-g...@laptop.org, Community Support Volunteers -- who help respond to help AT laptop.org support-g...@lists.laptop.org Date: Wednesday, July 21, 2010, 5:59 PM Hi Yioryos, On 21 Jul 2010, at 18:26, Yioryos Asprobounitis mavrot...@yahoo.com 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 there is it goes through individual journal entries, instead of your private index within the book (unless I miss something) which is much more usefull. It is clearly an improvement over Read in that front but hardly sufficient. Could you expand a little more on this idea, I'm not sure I
Re: [IAEP] Redesigning: Library, Read, Get-Books, and Content bundles
On 20 Jul 2010, at 19:33, Reuben K. Caron reu...@laptop.org 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 paperl...@timmcnamara.co.nz wrote: On 16 July 2010 10:50, Daniel Drake d...@laptop.org 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 to...@sugarlabs.org wrote: On Tue, Jul 6, 2010 at 05:26, Gary Martin garycmar...@googlemail.com 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 5 Jul 2010, at 14:13, Bernie Innocenti ber...@codewiz.org 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 journal 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 06:45, Mikus Grinbergs mi...@bga.com 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 20:23, Mikus Grinbergs mi...@bga.com 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 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
Hi Sayamindu, On 29 Jun 2010, at 22:25, Sayamindu Dasgupta sayami...@gmail.com wrote: On Wed, Jun 23, 2010 at 1:58 AM, Sayamindu Dasgupta sayami...@gmail.com wrote: On Fri, Jun 18, 2010 at 9:04 AM, Gary Martin garycmar...@googlemail.com 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: [Sugar-devel] Sugar with a virtual (onscreen) keyboard
On 30 Jun 2010, at 00:18, C. Scott Ananian csc...@laptop.org wrote: On Tue, Jun 22, 2010 at 4:28 PM, Sayamindu Dasgupta sayami...@gmail.com 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: Cairo's slow rendering on XO-1 (was: olpcgames - mainloop bug help)
Hi Wade, On 28 Jun 2010, at 15:10, Wade Brainerd wad...@gmail.com 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 pbrobin...@gmail.com wrote: On Mon, Jun 28, 2010 at 10:13 AM, Dov Grobgeld dov.grobg...@gmail.com 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 b...@freudenbergs.de 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 d...@laptop.org 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] Keep confusion -- round N+1
On 24 Jun 2010, at 09:45, NoiseEHC noise...@freemail.hu 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] Removing 'share' option from activites that don't know how to share
On 24 Jun 2010, at 16:20, Martin Langhoff martin.langh...@gmail.com 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 00:07, Daniel Drake d...@laptop.org wrote: On 23 June 2010 15:49, Martin Langhoff martin.langh...@gmail.com 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 to write more than minimal text in this
Re: multi-touch
On 8 Jun 2010, at 09:53, C. Scott Ananian csc...@laptop.org wrote: On Tue, Jun 8, 2010 at 4:20 AM, Carlos Nazareno object...@gmail.com 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
Re: Reason for the one dot hang found!
On 10 Jun 2010, at 20:53, Daniel Drake d...@laptop.org wrote:
On 10 June 2010 10:58, Bernie Innocenti ber...@codewiz.org 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 21
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: access denied
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 11 Jun 2010, at 04:14, Peter Robinson pbrobin...@gmail.com wrote: On Tue, Jun 8, 2010 at 4:05 PM, Gary Martin garycmar...@gmail.com wrote: On 8 Jun 2010, at 09:53, C. Scott Ananian csc...@laptop.org wrote: On Tue, Jun 8, 2010 at 4:20 AM, Carlos Nazareno object...@gmail.com 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
