Re: [Sugar-devel] [GSoC] Sugar Browser
On Sun, Mar 21, 2010 at 23:25, Lucian Branescu lucian.brane...@gmail.com wrote: Some have expressed concern about Browse and its current xulrunner dependency (http://bugs.sugarlabs.org/ticket/1850). To make matters even worse for the future, Mozilla plans to get rid of XPCOM at some point in favour of better JavaScript interfacing to C++ and a JavaScript ffi similar to ctypes. The extent up to which xulrunner will be supported by Mozilla as an embeddable engine is the most important point, IMHO. But up to now we only have rumours and speculation. Could someone add a reference to a clear statement or ask someone at Mozilla? Ubuntu's position on this is explained here, though I would prefer something clearer: https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/ Surf is an existing browser activity that uses webkit (pywebkitgtk). It is not yet on par feature-wise with Browse, but it could be extended. I see a few possible ways forward, that I could work on for GSoC: 1) Get Browse into shape (with a bundled xulrunner?) 2) Update Surf to be on par with Browse I am inclined to choose the second for a few reasons. First, current webkit is much faster and uses less memory than current gecko, which has been especially visible on XOs. When comparing performance, we need to compare apples to apples, which can be a lot of work. One way to move forward regarding this is to make a simpler Browse comparable in functionality to the current Surf and measure that. While gecko has superior extendability (XUL extensions), Browse isn't compatible with Firefox extensions, so anything would need to be rewritten anyway. Google gears runs unmodified on Browse. Extensions that depend on Firefox interfaces will only run on Firefox, but there are lots of extensions that only use Xulrunner interfaces. Userscripts (Greasemonkey) serve most needs for now and if needed, an extension API akin to Mozilla's Jetpack or Chrome's extensions could be implemented. Second, webkit is being used by a lot of projects and has the backing of several companies. Furthermore, it is packaged more consistently across platforms/distributions. As pointed out above, I think the maintainability issue is the most important here. While we have reasons to fear about Mozilla in this regard, we should act on more final information. Third, pywebkitgtk and hulahop have a similar API (and pywebkitgtk tries not to diverge unless necessary) and it should be possible to not depend too much on any one of them. A thin abstraction layer could be written on top to handle most differences and it should only rarely be needed to go beneath this abstraction. While this would most likely not result in a browser than can switch engines at runtime, it should make any future porting much easier. Any thoughts on this? In summary, I think this is a very interesting proposal, thanks for bringing it up again. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal-like activities (was: Re: [ASLO] Release Read ETexts-19)
On Thu, Mar 18, 2010 at 16:07, Martin Langhoff martin.langh...@gmail.com wrote: Hi James, I am very glad people are exploring alternatives around the Journal. Not sure what your goals are -- would be interesting to hear. Comments - I don't know how pluggable the Journal is, but I'd encourage working on patches to the Journal itself. I don't think a proper activity can take the role of the Journal, as it is pretty special. I agree on this because of the deployability issues mentioned in another thread. The plan of record for the journal is to have an actions view similar to the one we have now. Every action would be linked to one or more objects. The object view could still be non-hierarchical for the internal journal, but when you were browsing an external device, it could display its hierarchy if there is any. Would be great if someone could finally work on it. Regards, Tomeu - There's been interesting discussions around teaching the Journal about it's backup, which is on the XS (if there is one). An exciting idea bandied about was to do something inspired by Apple's Time Machine. I am happy to improve things on the XS side if needed. Aleksey is the current maintainer, he'll probably have suggestions ;-) cheers, m On Thu, Mar 18, 2010 at 10:44 AM, James Simmons nices...@gmail.com wrote: Sascha, No need to apologize for a long email; this is interesting. I'm thinking I'll start working on an improved version of Gabriel's Leer Pen Drive and see where that takes me. I like the idea of the Journal very much, but the implementation of the Journal Activity (if it's correct to call it that) is not what I would like it to be. James Simmons On Thu, Mar 18, 2010 at 8:09 AM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: On Wed, Mar 17, 2010 at 05:08:08PM -0500, James Simmons wrote: I was looking at the code for Leer Pen Drive and thinking how I could improve on it, and in the process I ended up looking at git.sugarlabs.org at the code for Journal. Apparently that is not the most recent code, I guess you were looking at the journal project (don't have internet access right now, so cannot check the exact name). That's indeed rather old code; the Journal has been integrated into the sugar package. That wouldn't be too surprising except that the Journal Activity can write to a USB or thumb drive. I couldn't figure out how or even where it was doing it, [...] The journal project is part of 0.82. Back then the data store handled removable media. In 0.84+, the data store was rewritten from scratch [1] and only handles the on-disk, native Sugar objects. Handling of traditional (POSIX) file storage (USB sticks, hard disks, etc.) has been moved into the Journal. The code you're looking for is sugar/src/jarabe/journal/model.py. In there, the classes DatastoreResultSet and InplaceResultSet form an abstraction layer over the data store and mounted (POSIX) file systems. but it does seem that you could write an Activity that does everything the Journal does, from writing to mounted media to unmounting it. Almost everything the Journal does can be done in an activity as well. It all boils down to permissions; usually the permissions are based on security considerations. The following actions are implemented (source references are for 0.88): - show item in Journal (D-Bus API) - sugar/src/jarabe/journal/journalactivity.py - D-Bus doesn't allow a second process with the same service name, so not overridable - show object picker (D-Bus API) - sugar/src/jarabe/journal/journalactivity.py - again, D-Bus prevents activities from providing this - mounting/unmounting file systems (e.g. USB sticks) - show new mount points: sugar/src/jarabe/journal/volumestoolbar.py - unmounting: sugar/src/jarabe/view/palettes.py:VolumePalette - mounting (Frame, not Journal): sugar/extensions/deviceicon/volume.py - without Rainbow: - activities are able to mount and umount file systems using gio (resp. gvfs for older systems) - with Rainbow: - gio/gvfs probably refuses to unmount file systems mounted by the Frame from within activities (because the user ids are different) - browsing data store / file systems, reading all entries / files - sugar/src/jarabe/journal/model.py - without Rainbow: - unrestricted - with Rainbow: - currently: - data store access unrestricted - file system access prevented by gio/gvfs permission settings - future: - see P_DOCUMENT / P_DOCUMENT_RO Bitfrost [2] protections - reading a single data store entry / file via Object Picker - sugar-toolkit/src/sugar/graphics/objectchooser.py - unrestricted - writing a single data store entry / file (acquired via Object Picker) - without Rainbow: - unrestricted - with Rainbow: - currently: - data store access unrestricted - file system access prevented by gio/gvfs permission
Re: [Sugar-devel] Restoring journal backups created with 0.82 on 0.84
On Tue, Mar 16, 2010 at 20:13, Bernie Innocenti ber...@codewiz.org wrote: Martin, Rodolfo Aldo, one of the technicians in Caacupe, reported failure to restore backups created with Sugar 0.82 after the machine has been upgraded to Sugar 0.84. Frankly, I don't understand how the restore script is supposed to work: it rsyncs the files into ~/.ds-restore-tmp and then quits without moving them where the datastore is. I tried moving the files manually into ~/.sugar/default/datastore and restarting Sugar, but nothing shows up. How does the datastore detect an old format that needs updating? See http://git.sugarlabs.org/projects/sugar-datastore/repos/mainline/blobs/sucrose-0.84/src/carquinyol/datastore.py#line57 Besides this problem, it would be useful to add a control panel icon for listing available backups and restoring them. Is anyone working on this? Would be good if all deployments agreed on a common backup system and worked together on this. Regards, Tomeu -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hard code freeze exception request: 0.82 data store not detected / migrated [#1838]
On Wed, Mar 17, 2010 at 13:20, Aleksey Lim alsr...@member.fsf.org wrote: +1 +1 from me as well Thanks! Tomeu On Wed, Mar 17, 2010 at 12:59:38PM +0100, Sascha Silbe wrote: Hi! I hereby request a hard code freeze exception for SL#1838. [1] Migrating from a 0.82 data store has been broken since 0.86: the 0.82 data store contents are not recognized on first start-up and thus are never imported, leaving the user with an empty Journal instead. While the previous content is not gone is a technical sense, recovering from this bug requires issuing commands in the Terminal that can be dangerous if not done right (version file and index need to be deleted). The fix is trivial, see below. [1] https://bugs.sugarlabs.org/ticket/1838 CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ From: Sascha Silbe sascha-...@silbe.org Subject: [PATCH] fix migration from 0.82 data store (#1838) Upgrading directly from 0.82 to 0.86/0.88 didn't migrate the data store contents because LayoutManager._is_empty() doesn't check for 0.82 data store entries. This patch fixes _is_empty() to recognize 0.82 data store contents. Signed-off-by: Sascha Silbe sascha-...@silbe.org --- src/carquinyol/layoutmanager.py | 8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/src/carquinyol/layoutmanager.py b/src/carquinyol/layoutmanager.py index 0b0b91a..8402b6d 100644 --- a/src/carquinyol/layoutmanager.py +++ b/src/carquinyol/layoutmanager.py @@ -114,6 +114,14 @@ class LayoutManager(object): return uids def _is_empty(self): + Check if there is any existing entry. + + All data store layout versions are handled. Will err on the safe + side (i.e. return False if there might be any entry). + if os.path.exists(os.path.join(self._root_path, 'store')): + # unmigrated 0.82 data store + return False + for f in os.listdir(self._root_path): if os.path.isdir(os.path.join(self._root_path, f)) and len(f) == 2: for g in os.listdir(os.path.join(self._root_path, f)): -- tg: (0cffadc..) t/bug-1838 (depends on: upstream/master) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Children want Sugar 0.84, for the wrong reason
On Mon, 2010-03-15 at 16:03 -0500, Martin Langhoff wrote: Agreed. You can do what you are doing (run a school on newish sw, get a tight feedback bugfix loop) when someone like you is there. [...] Yes -- but we gotta remember that it's productive (specially for Sugar) because you are there. You can turn their frustration into valuable info (and bugfixes). Without you, it's just frustration. Indeed :-( I'm trying to get everyone on IRC and mailing lists before I leave. In Nepal it worked, but here the language barrier is higher. I told everyone that Spanish is welcome in bug reports, blog posts and for chatting on #sugar. Many of our core developers speak Spanish fluently, so they could bridge information to the others. Admittedly, it's not working: people come to IRC, they see that everyone speaks English, and shy away. I don't believe in breaking the community apart in many per-language ghettos, but Spanish probably has enough critical mass to justify a #sugar-es (or #olpc-es) channel. That's a good idea -- try to work in a school with latest Sugar late in the previous school year, to incorporate stuff for the wider deployment in the over-summer-holidas upgrade. (And actually we have a late-starting deployment in La Rioja, which is on-time to take advantage of that work.) Cool! A lot of stuff is moving forward here: * This Monday we'll have another meeting with the formadores to help them file complete and understandable bug reports without the need for us to go on-site. * We're now tracking the remaining bugs here: http://wiki.paraguayeduca.org/index.php/Devel/Builds/Todo * Two more developers of the Paraguay Educa technical team are learning to create OS builds. Next week, they'll start helping out with activities. * The formadores (teacher trainers) got used to the differences in the new software release and are no longer diffident. That's truly a good question. I'll say the teams closest to the deployments. Distant upstreams (kernel, udev, Fedora) don't care directly about our end users. OLPC/SLers are passionate about children learning. [...] Yep - that and combine it with working with a few schools on recent releases, with a developer on-site -- like you, Simon and others are doing. Yes, we definitely need more errant developers! Since there's a limited amount of core developers in OLPC and SL, in the future we may want to encourage deployments to exchange developers. The Paraguayan team now employs hackers with two years of experience. The same is probably true in Uruguay. It would be great if one of them could travel to the fledgling Argentinian deployment and help them build capacity locally. A decentralized model of international collaboration would solve the scalability problem. In practice, it probably means we'll be answering questions about any release for about 1.5 to 2 years after the release date. Interestingly, Mark Shuttleworth has recently argued for a 2 years cycle synchronized across all the enterprise distributions: http://www.markshuttleworth.com/archives/290 If his proposal acquires enough momentum within the community, it would make sense for us to synchronize with it, solving the issue of being left behind by the rest of the development community. N. I'm not so crazy. But we have to fit in the school's 1-year-cycle, have time to stabilise, etc. Small deployments have more flexibility, and when someone like you is literally on site you can go wild... (take advantage of that!) but for the thousands of other schools an LTS Testing and stabilize a new version of Fedora and Sugar on the XO could be done with as little as a few thousand students in a small town, with just 1-2 developers on site. After we're done with Sugar 0.84, I'll try to repeat the development cycle for Sugar 0.88 and Fedora 12, starting with few adventurous volunteers such as the Scratcheros. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hard code freeze exception request
On 03/16/2010 09:49 AM, Aleksey Lim wrote: On Tue, Mar 16, 2010 at 08:26:31AM +0100, Tomeu Vizoso wrote: On Mon, Mar 15, 2010 at 19:38, Aleksey Limalsr...@member.fsf.org wrote: Hi all, http://bugs.sugarlabs.org/ticket/1831 Revert copy to Journal palette item in journal details view. Could be considered as regression since 0.82 has this feature. Hi, could you explain what the problem is and specifically what is being reverted? May be better to do so in the ticket. In 0.82, Copy tool button in details view had Journal menu item to copy to journal (if current journal entry is on non-ds). Patch just reverts Journal menu item. http://thread.gmane.org/gmane.linux.laptop.olpc.sugar/21385/focus=21389 Yes, it looks like the option has been forgotten when moving the journal activity code into jarabe. There does not seem to be another reason the option is not there anymore. Aleksey's patch works fine here. It adds a string (Journal), but this one should be translated already. +1 from me. Thanks Aleksey for following the exception request and for your patch. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hard code freeze exception request: 0.82 data store not detected / migrated [#1838]
On 03/22/2010 11:33 AM, Tomeu Vizoso wrote: On Wed, Mar 17, 2010 at 13:20, Aleksey Limalsr...@member.fsf.org wrote: +1 +1 from me as well Thanks! Tomeu Looks good to me, too. What I would like to see here is TESTING!. It would be really nice to have some positive test results where prople migrate the DS from 0.82 to 0.88. Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Children want Sugar 0.84, for the wrong reason
On Mon, Mar 22, 2010 at 11:51, Bernie Innocenti ber...@codewiz.org wrote: On Mon, 2010-03-15 at 16:03 -0500, Martin Langhoff wrote: Agreed. You can do what you are doing (run a school on newish sw, get a tight feedback bugfix loop) when someone like you is there. [...] Yes -- but we gotta remember that it's productive (specially for Sugar) because you are there. You can turn their frustration into valuable info (and bugfixes). Without you, it's just frustration. Indeed :-( I'm trying to get everyone on IRC and mailing lists before I leave. In Nepal it worked, but here the language barrier is higher. I told everyone that Spanish is welcome in bug reports, blog posts and for chatting on #sugar. Many of our core developers speak Spanish fluently, so they could bridge information to the others. Admittedly, it's not working: people come to IRC, they see that everyone speaks English, and shy away. I don't believe in breaking the community apart in many per-language ghettos, but Spanish probably has enough critical mass to justify a #sugar-es (or #olpc-es) channel. I have invested efforts in the past in that direction, but they haven't taken off. We have sugar-desarrollo and we used to have a channel as well, but haven't seen much use. If we had a deployment team, we could try to make a push so that people from different deployments talk together in an open space... Regards, Tomeu That's a good idea -- try to work in a school with latest Sugar late in the previous school year, to incorporate stuff for the wider deployment in the over-summer-holidas upgrade. (And actually we have a late-starting deployment in La Rioja, which is on-time to take advantage of that work.) Cool! A lot of stuff is moving forward here: * This Monday we'll have another meeting with the formadores to help them file complete and understandable bug reports without the need for us to go on-site. * We're now tracking the remaining bugs here: http://wiki.paraguayeduca.org/index.php/Devel/Builds/Todo * Two more developers of the Paraguay Educa technical team are learning to create OS builds. Next week, they'll start helping out with activities. * The formadores (teacher trainers) got used to the differences in the new software release and are no longer diffident. That's truly a good question. I'll say the teams closest to the deployments. Distant upstreams (kernel, udev, Fedora) don't care directly about our end users. OLPC/SLers are passionate about children learning. [...] Yep - that and combine it with working with a few schools on recent releases, with a developer on-site -- like you, Simon and others are doing. Yes, we definitely need more errant developers! Since there's a limited amount of core developers in OLPC and SL, in the future we may want to encourage deployments to exchange developers. The Paraguayan team now employs hackers with two years of experience. The same is probably true in Uruguay. It would be great if one of them could travel to the fledgling Argentinian deployment and help them build capacity locally. A decentralized model of international collaboration would solve the scalability problem. In practice, it probably means we'll be answering questions about any release for about 1.5 to 2 years after the release date. Interestingly, Mark Shuttleworth has recently argued for a 2 years cycle synchronized across all the enterprise distributions: http://www.markshuttleworth.com/archives/290 If his proposal acquires enough momentum within the community, it would make sense for us to synchronize with it, solving the issue of being left behind by the rest of the development community. N. I'm not so crazy. But we have to fit in the school's 1-year-cycle, have time to stabilise, etc. Small deployments have more flexibility, and when someone like you is literally on site you can go wild... (take advantage of that!) but for the thousands of other schools an LTS Testing and stabilize a new version of Fedora and Sugar on the XO could be done with as little as a few thousand students in a small town, with just 1-2 developers on site. After we're done with Sugar 0.84, I'll try to repeat the development cycle for Sugar 0.88 and Fedora 12, starting with few adventurous volunteers such as the Scratcheros. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Children want Sugar 0.84, for the wrong reason
On Mon, Mar 22, 2010 at 7:38 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On Mon, Mar 22, 2010 at 11:51, Bernie Innocenti ber...@codewiz.org wrote: On Mon, 2010-03-15 at 16:03 -0500, Martin Langhoff wrote: Agreed. You can do what you are doing (run a school on newish sw, get a tight feedback bugfix loop) when someone like you is there. [...] Yes -- but we gotta remember that it's productive (specially for Sugar) because you are there. You can turn their frustration into valuable info (and bugfixes). Without you, it's just frustration. Indeed :-( I'm trying to get everyone on IRC and mailing lists before I leave. In Nepal it worked, but here the language barrier is higher. I told everyone that Spanish is welcome in bug reports, blog posts and for chatting on #sugar. Many of our core developers speak Spanish fluently, so they could bridge information to the others. Admittedly, it's not working: people come to IRC, they see that everyone speaks English, and shy away. I don't believe in breaking the community apart in many per-language ghettos, but Spanish probably has enough critical mass to justify a #sugar-es (or #olpc-es) channel. I have invested efforts in the past in that direction, but they haven't taken off. We have sugar-desarrollo and we used to have a channel as well, but haven't seen much use. #olpc-paraguay seems active because it has a tangible purpose. I imagine the same is true for whatever channel developers use in .uy. Maybe we should encourage more local foci for the initial engagement? Invite promising new contributors to use the same channel as the developers supporting their deployment. Naturally the interesting discussing on #olpc-paraguay seem to spill over into #sugar (well, the occasional deliberate push by Bernie or Raul helps). We will eventually figure this out :) -walter If we had a deployment team, we could try to make a push so that people from different deployments talk together in an open space... Regards, Tomeu That's a good idea -- try to work in a school with latest Sugar late in the previous school year, to incorporate stuff for the wider deployment in the over-summer-holidas upgrade. (And actually we have a late-starting deployment in La Rioja, which is on-time to take advantage of that work.) Cool! A lot of stuff is moving forward here: * This Monday we'll have another meeting with the formadores to help them file complete and understandable bug reports without the need for us to go on-site. * We're now tracking the remaining bugs here: http://wiki.paraguayeduca.org/index.php/Devel/Builds/Todo * Two more developers of the Paraguay Educa technical team are learning to create OS builds. Next week, they'll start helping out with activities. * The formadores (teacher trainers) got used to the differences in the new software release and are no longer diffident. That's truly a good question. I'll say the teams closest to the deployments. Distant upstreams (kernel, udev, Fedora) don't care directly about our end users. OLPC/SLers are passionate about children learning. [...] Yep - that and combine it with working with a few schools on recent releases, with a developer on-site -- like you, Simon and others are doing. Yes, we definitely need more errant developers! Since there's a limited amount of core developers in OLPC and SL, in the future we may want to encourage deployments to exchange developers. The Paraguayan team now employs hackers with two years of experience. The same is probably true in Uruguay. It would be great if one of them could travel to the fledgling Argentinian deployment and help them build capacity locally. A decentralized model of international collaboration would solve the scalability problem. In practice, it probably means we'll be answering questions about any release for about 1.5 to 2 years after the release date. Interestingly, Mark Shuttleworth has recently argued for a 2 years cycle synchronized across all the enterprise distributions: http://www.markshuttleworth.com/archives/290 If his proposal acquires enough momentum within the community, it would make sense for us to synchronize with it, solving the issue of being left behind by the rest of the development community. N. I'm not so crazy. But we have to fit in the school's 1-year-cycle, have time to stabilise, etc. Small deployments have more flexibility, and when someone like you is literally on site you can go wild... (take advantage of that!) but for the thousands of other schools an LTS Testing and stabilize a new version of Fedora and Sugar on the XO could be done with as little as a few thousand students in a small town, with just 1-2 developers on site. After we're done with Sugar 0.84, I'll try to repeat the development cycle for Sugar 0.88 and Fedora 12, starting with few adventurous volunteers such as the Scratcheros. -- // Bernie Innocenti -
[Sugar-devel] [ASLO] Release Jam2Jam-1
Activity Homepage: http://activities.sugarlabs.org/addon/4290 Sugar Platform: 0.82 - 0.88 Download Now: http://activities.sugarlabs.org/downloads/file/26839/jam2jam-1.xo Release notes: Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] Sugar-Toolkit 0.84.9
Hi, I just released sugar-toolkit 0.84.9 Changes: * Translation updates * Removes the use of O_SYNC on logs #1656 (James) * Changes to a Journal entries metadata are wiped if activity is still open (#1765) (Simon) * Do not fail while closing object less activities #1714 (Aleksey) * Check syntax of private key (#1568) (Sascha) * After using CP, the XO home palette is incorrectly scrolled (blank lines + missing item) #231 (Simon) Download: http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.84.9.tar.bz2 Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal-like activities (was: Re: [ASLO] Release Read ETexts-19)
Bert,
Thanks, that looks like what I needed.
James Simmons
On Mon, Mar 22, 2010 at 9:18 AM, Bert Freudenberg b...@freudenbergs.de wrote:
I just had the same problem working on Scratch. I needed to filter out the
USB files when listing Journal entries. I now do that by filtering on the
mountpoint.
To figure out the mountpoint of the Journal, I call the datastore's mounts
method, and take the one with an URI starting with /home. The USB ones
start with /media:
entries
self journalMountpoint ifNotNilDo: [:mountpoint |
Filter out USB entries on Sugar 0.82
query at: 'mountpoints' put: {mountpoint}].
^ self datastore find: query with: #('uid' 'title' 'mime_type'
'timestamp')].
journalMountpoint
If the datastore mounted multiple volumes (e.g. USB drive), answer
the id of the user's Journal, otherwise return nil.
| mounts uri |
mounts := [self datastore mounts] ifError: [^ nil].
mounts size 1 ifFalse: [^ nil].
mounts do: [:mount |
uri := mount at: 'uri' ifAbsent: ['/'].
(uri beginsWith: '/home')
ifTrue: [^ mount at: 'id' ifAbsent: [nil]]].
^ nil
See
http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API#Mount_Points
- Bert -
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] Sucrose 0.88.0 - Newstable Release - Tarballs Due
Dear Sucrose Maintainers, please provide source tarballs for the Sucrose 0.88.0 stable release [1] by the end of the 29th of March 2010 and announce them as explained at [2]. This will be our Newstable Release, make sure you wear your good shoes that day! Thanks, Simon [1] http://wiki.sugarlabs.org/go/0.88/Roadmap#Schedule [2] http://sugarlabs.org/go/Development_Team/Release#Module_release ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [GSoC] Sugar Browser
On Sun, Mar 21, 2010 at 10:25 PM, Lucian Branescu lucian.brane...@gmail.com wrote: Some have expressed concern about Browse and its current xulrunner dependency (http://bugs.sugarlabs.org/ticket/1850). To make matters even worse for the future, Mozilla plans to get rid of XPCOM at some point in favour of better JavaScript interfacing to C++ and a JavaScript ffi similar to ctypes. I think that is a long way in the future. A lot of interfaces use xulrunner and as far as I'm aware its not going anywhere. The XPCom bit I'm not so sure about. At the moment the only thing that's been dropped out is pyxpcom which is still supported and developed as an external package. It works fine and is packaged as part of Fedora 13. Surf is an existing browser activity that uses webkit (pywebkitgtk). It is not yet on par feature-wise with Browse, but it could be extended. I see a few possible ways forward, that I could work on for GSoC: 1) Get Browse into shape (with a bundled xulrunner?) Bundling xulrunner isn't an option that will be support in Fedora or SOAS. In Fedora xulrunner is well maintained with an active team of people fixing issues. 2) Update Surf to be on par with Browse I am inclined to choose the second for a few reasons. First, current webkit is much faster and uses less memory than current gecko, which has been especially visible on XOs. While gecko has superior extendability (XUL extensions), Browse isn't compatible with Firefox extensions, so anything would need to be rewritten anyway. Userscripts (Greasemonkey) serve most needs for now and if needed, an extension API akin to Mozilla's Jetpack or Chrome's extensions could be implemented. While the current webkit is faster its no where near as capable and has issues on numerous sites the current firefox is also a lot fast than its predecessors. The 3.6.3 release of firefox (and corresponding release of xulrunner) will have support for OOPP (Out of Process Plugins) which will also make it more stable and fast. There's also massive improvements being made on I/O which will speed things up on the XO. In SOAS-2 when I upgraded my XO from the previous official olpc release i saw massive improvements in the speed on Browse. Second, webkit is being used by a lot of projects and has the backing of several companies. Furthermore, it is packaged more consistently across platforms/distributions. So does firefox and xulrunner. It has the backing of both Nokia and Intel in their mobile devices and is being actively ported to Android and other mobile platforms so it shows there's a commitment to speed. I don't think the point above is really relevant to the discussion. Third, pywebkitgtk and hulahop have a similar API (and pywebkitgtk tries not to diverge unless necessary) and it should be possible to not depend too much on any one of them. A thin abstraction layer could be written on top to handle most differences and it should only rarely be needed to go beneath this abstraction. While this would most likely not result in a browser than can switch engines at runtime, it should make any future porting much easier. I'm not really one to comment on APIs. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [MINUTES] Development team meeting --- 22. Mar 2010 (14:00 UTC)
Hi, the development team has had one more meeting, minutes and logs: * http://me.etin.gs/sugar-meeting/sugar-meeting.minutes.20100322_1010.html * http://me.etin.gs/sugar-meeting/sugar-meeting.log.20100322_1010.html Cheers, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC] Sugar Browser
I found this wiki page so far https://wiki.mozilla.org/Mozilla_2/XPCOM_and_Binary_Embedding I should have a chat with the Mozilla people anyway, that page may not be entirely up to date. From this discussion: 1) Performance tests of recent webkit and xulrunner on XOs and other hardware SoaS runs on would be useful, paying close attention to real-world relevance. 2) Regardless of the results of the benchmark, it would be useful to write an abstraction layer over hulahop/pywebkitgtk/whatever would be used for embedding Mozilla 2. It should allow the Sugar browser the ability to switch between engines, if not at runtime at least with very little effort. On 22 March 2010 08:39, Tomeu Vizoso to...@tomeuvizoso.net wrote: On Sun, Mar 21, 2010 at 23:25, Lucian Branescu lucian.brane...@gmail.com wrote: Some have expressed concern about Browse and its current xulrunner dependency (http://bugs.sugarlabs.org/ticket/1850). To make matters even worse for the future, Mozilla plans to get rid of XPCOM at some point in favour of better JavaScript interfacing to C++ and a JavaScript ffi similar to ctypes. The extent up to which xulrunner will be supported by Mozilla as an embeddable engine is the most important point, IMHO. But up to now we only have rumours and speculation. Could someone add a reference to a clear statement or ask someone at Mozilla? Ubuntu's position on this is explained here, though I would prefer something clearer: https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/ Surf is an existing browser activity that uses webkit (pywebkitgtk). It is not yet on par feature-wise with Browse, but it could be extended. I see a few possible ways forward, that I could work on for GSoC: 1) Get Browse into shape (with a bundled xulrunner?) 2) Update Surf to be on par with Browse I am inclined to choose the second for a few reasons. First, current webkit is much faster and uses less memory than current gecko, which has been especially visible on XOs. When comparing performance, we need to compare apples to apples, which can be a lot of work. One way to move forward regarding this is to make a simpler Browse comparable in functionality to the current Surf and measure that. While gecko has superior extendability (XUL extensions), Browse isn't compatible with Firefox extensions, so anything would need to be rewritten anyway. Google gears runs unmodified on Browse. Extensions that depend on Firefox interfaces will only run on Firefox, but there are lots of extensions that only use Xulrunner interfaces. Userscripts (Greasemonkey) serve most needs for now and if needed, an extension API akin to Mozilla's Jetpack or Chrome's extensions could be implemented. Second, webkit is being used by a lot of projects and has the backing of several companies. Furthermore, it is packaged more consistently across platforms/distributions. As pointed out above, I think the maintainability issue is the most important here. While we have reasons to fear about Mozilla in this regard, we should act on more final information. Third, pywebkitgtk and hulahop have a similar API (and pywebkitgtk tries not to diverge unless necessary) and it should be possible to not depend too much on any one of them. A thin abstraction layer could be written on top to handle most differences and it should only rarely be needed to go beneath this abstraction. While this would most likely not result in a browser than can switch engines at runtime, it should make any future porting much easier. Any thoughts on this? In summary, I think this is a very interesting proposal, thanks for bringing it up again. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [GSoC] Sugar Browser
FWIW, at litl we are switching from a xulrunner-based brower to a chromium-based browser. We are seeing a big performance improvement, plus it's making it easier for us to implement plugin isolation and better memory management (unloading pages which are not foregrounded, etc). YMMV, and it's been about 3 person-months of work, but I can suggest from experience that it may be worth it. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [GSoC] Sugar Browser
On Mon, Mar 22, 2010 at 5:42 PM, C. Scott Ananian csc...@cscott.net wrote: FWIW, at litl we are switching from a xulrunner-based brower to a chromium-based browser. We are seeing a big performance improvement, plus it's making it easier for us to implement plugin isolation and better memory management (unloading pages which are not foregrounded, etc). YMMV, and it's been about 3 person-months of work, but I can suggest from experience that it may be worth it. The two main issues with chromium is its upstreamability, which becomes a problem for at least Fedora and Debian, and actually having the resources to dedicated to it. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hard code freeze exception request: 0.82 data store not detected / migrated [#1838]
On Tue, Mar 23, 2010 at 11:15:02AM +1100, James Cameron wrote: Looks good to me, too. What I would like to see here is TESTING!. It would be really nice to have some positive test results where prople migrate the DS from 0.82 to 0.88. How would you migrate the DS from 0.82 to 0.88? Just run 0.88 on a system that ran 0.82 previously. For testing you can simply copy over ~/.sugar/default/datastore. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
