Re: [Sugar-devel] Activity Central's Sugar related priorities.
Excuse the top post: FWIW, I have most of a Sugar authentication with Google Drive working. (For the almost finished Gdrive webservice.) -walter On Wed, Oct 9, 2013 at 8:04 PM, Daniel Narvaez wrote: > On 10 October 2013 00:22, Daniel Narvaez wrote: >> >> 1 Inability to do OAuth >> >> This has been discussed for Firefox OS too and as far as I know there is >> no good solution for it yet. I won't claim to understand all the security >> implications, tough the basic issue seems to run content from the web inside >> an higher privileged application. In our case it's worst because we don't >> support hosted web applications at all. > > > I don't fully understand the problems involved yet but mozilla seems to > have a found a solution to this > > https://bugzilla.mozilla.org/show_bug.cgi?id=852720 > > We do have a stable origin already given by the app:// protocol we are > using. Though I'm not sure that's the only requirement (the discussion on > the bug report is long and a bit confusing). > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On 10 October 2013 00:22, Daniel Narvaez wrote: > 1 Inability to do OAuth > > This has been discussed for Firefox OS too and as far as I know there is > no good solution for it yet. I won't claim to understand all the security > implications, tough the basic issue seems to run content from the web > inside an higher privileged application. In our case it's worst because we > don't support hosted web applications at all. > I don't fully understand the problems involved yet but mozilla seems to have a found a solution to this https://bugzilla.mozilla.org/show_bug.cgi?id=852720 We do have a stable origin already given by the app:// protocol we are using. Though I'm not sure that's the only requirement (the discussion on the bug report is long and a bit confusing). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Arch Linux XO image and Sugar packages
On Wed, Oct 09, 2013 at 02:56:55PM +0200, Daniel Narvaez wrote: > On Wednesday, 9 October 2013, James Cameron wrote: > > On Tue, Oct 08, 2013 at 09:32:34PM -0500, Sebastian Silva wrote: > > > dir u:\ > > > > > > clears the screen and shows some garbled text. > > > On my laptop the usb drive mounts fine. > > > Strange, no ? > > > Looking into it further, it may relate to how Daniel advises you > > to effectively destroy the device partition table by making the > > filesystem on /dev/sdb rather than the usual methods. The result > > may depend on what is already on the USB drive, and so is less > > predictable > > Can you explain why the result depends on what is already on the > drive? Sure. Summary: initially it was because I thought mkfs.ext4 does not erase GPT, but as it turns out, it kindly does so. The situation has changed since I last looked into this. It remains less predictable, but only if older versions of mke2fs are used. The firmware of an XO, and other firmware, and various operating systems, read blocks on the device to assess the partition table type. There are several different types of partition table, the most common is the MBR [1], less common is the GPT [2]. Open Firmware supports both types of partition table, as well as devices without any table. (It is difficult to code for every eventuality, and it isn't clear what should be trusted first when there is multiple evidence of data; an MBR, a GPT, or an ext2 filesystem signature.) In the following tests, a 128MB flash drive was used, the drive was erased between each test. Blocks are 512 bytes long. Using gparted to create a new MBR partition table writes to the first block [3]. Using gparted to create a new GPT partition table writes to the first block a protective MBR, followed by a primary GPT header and entries, and a secondary GPT header near the end of the disk [4]. Using mkfs.ext4 to create a filesystem overwrites the first block with zeroes, and metadata begins at the second block [5]. If the device contains a GPT at the time, mkfs.ext4 also overwrites the secondary GPT header [6]. There is no obvious requirement for mkfs.ext4 to do this. The code can be found in mke2fs.c in the function main [7], with the comment: /* * Wipe out any old MD RAID (or other) metadata at the end * of the device. This will also verify that the device is * as large as we think. Be careful with very small devices. */ The code erases 64kB at the end of the device. 1. http://en.wikipedia.org/wiki/Master_Boot_Record 2. http://en.wikipedia.org/wiki/GUID_Partition_Table 3. http://dev.laptop.org/~quozl/2013-10-10-mkfs.ext4-vs-gpt/dd.mbr.txt 4. http://dev.laptop.org/~quozl/2013-10-10-mkfs.ext4-vs-gpt/dd.gpt.txt 5. http://dev.laptop.org/~quozl/2013-10-10-mkfs.ext4-vs-gpt/dd.ext4.txt 6. http://dev.laptop.org/~quozl/2013-10-10-mkfs.ext4-vs-gpt/dd.gpt.ext4.txt 7. http://dev.laptop.org/~quozl/2013-10-10-mkfs.ext4-vs-gpt/mke2fs.c.html.gz#splat -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Web activities canvas element
Thanks, I'll watch at ClockWeb activity. Regards 2013/10/10 Manuel Quiñones > 2013/10/9 laurent bernabe : > > Hello, > > > > *) I am wondering whether I can safely replace, in an index.html file of > a > > web activity, the > > ? > > > > Because the library I am using need a real canvas element. > > You just put your inside that . > > > *) Also, if I can use a real canvas element, how can set its size to the > > remaining size of the screen ? (As my laptop has a wider screen than XO > > ones). > > It's possible by connecting to the window resize event in JS. You can > see an example in Clock Web activity. > > https://github.com/manuq/clock-web > http://manuq.github.io/clock-web/ > > -- > .. manuq .. > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Web activities canvas element
2013/10/9 laurent bernabe : > Hello, > > *) I am wondering whether I can safely replace, in an index.html file of a > web activity, the > ? > > Because the library I am using need a real canvas element. You just put your inside that . > *) Also, if I can use a real canvas element, how can set its size to the > remaining size of the screen ? (As my laptop has a wider screen than XO > ones). It's possible by connecting to the window resize event in JS. You can see an example in Clock Web activity. https://github.com/manuq/clock-web http://manuq.github.io/clock-web/ -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On 9 October 2013 22:51, NoiseEHC wrote: > Now I will not give you constructive criticism as that would allow > answering that "I should not tell others what to do" and it would be > getting old... Instead here is some nonconstructive criticism: > I don't know if it's constructive or not, but I'd say it's certainly useful. You are identifying the major limitations of the current sugar-web framework. Just some notes about them. 1 Inability to do OAuth This has been discussed for Firefox OS too and as far as I know there is no good solution for it yet. I won't claim to understand all the security implications, tough the basic issue seems to run content from the web inside an higher privileged application. In our case it's worst because we don't support hosted web applications at all. 2 Journal This is probably the issue we have been most aware of. I've been thinking in the per activity datastore direction too and I think it's probably the best one. Though as you say that involves UI redesign and we would need to figure out compatibility with existing activities. (Please share the webkit code, I don't know if I'll have time to hack on it but I did think to write something like that at some point, it would be interesting to look at it if nothing else). 3 Collaboration One of the reasons we haven't tackled it yet is that we think something like what you proposed might be a better solution than trying to wrap the current native framework (which is also known to be very unreliable). So as I see you either create a framework which mimics Sugar and no web > developer will use it or create a framework which implements what a web > developer is already using or at least tries to somehow emulate it. So the > web developer does not have to modify his/her code and will consider > porting his/her application for a smaller platform. > We probably all agree that it would be awesome to have something that integrates well with Sugar and works transparently by reusing existing web technologies. I don't think that's easy to achieve though. It has been said in previous discussions that without the close integration between activities and system, Sugar would be just yet another suite of educational applications (and likely not the best of them). I very much agree and I think it's tricky to preserve that while moving to frameworks which are supposed to work everywhere. We could have started with something more web developer friendly and incrementally integrated it into the native Sugar platform, for example by redesigning the Journal in the way you described, and somehow adapting native activities to the new design. Instead we went for something targeted at the current Sugar developers with the idea of making it incrementally more web friendly. I have been on the fence on what was the best approach and I still am. Something to consider is that we barely have the resources to maintain the existing native code. I doubt, for example, that we would be able to ship a redesigned Journal. Consider also that the people most involved with this work has all a good knowledge of the Sugar platform but are not really web developers. Just my $0.02. Manuel might want to post his perspective too. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Web activities canvas element
Hello, *) I am wondering whether I can safely replace, in an index.html file of a web activity, the ? Because the library I am using need a real canvas element. *) Also, if I can use a real canvas element, how can set its size to the remaining size of the screen ? (As my laptop has a wider screen than XO ones). Regards ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On 07/10/2013 18:41, David Farning wrote: Activity Central supports the recent HTML5 + JS work that is going into sugar .100. It has the potential to take the OLPC vision to any device which runs a browser while simultaneously *increasing* the potential activity *developer* *pool* by several orders of magnitude. This is an excellent area for community lead research. Activity Central will be doing activity side work to test the viability of the framework for client deployments. No, it won't... It already happened when Bryan Berry moved OLPC Nepal's lessons from EToys to Flash, then to HTML5 and there were not any more contributors. I mean, there are much more JS developers, so if you pay them you can get cheaper talent, but there will be not too much more contributors IMHO. The problem is that the current HTML5 work goes into a direction which I am not sure that needed by anyone other than existing Sugar developers. It all boils down to this simple question: If you are a potential contributor wanting to develop some educational activity (not a framework but some concrete lesson or stuff usable in a lesson!!!) then which one would you use? 1. A HTML5 + JavaScript activity model called Sugar Web Activity, which reaches 2-3 million children? (lets call it SWA) 2. A HTML5 + JavaScript activity model called HTML5 + JavaScript, which reaches 1 billion children? (lets call it WEB) I have not seen any compelling reason why would a potential contributor (software developer from a developed country who has/likes children) choose option 1 instead of 2... Now I will not give you constructive criticism as that would allow answering that "I should not tell others what to do" and it would be getting old... Instead here is some nonconstructive criticism: Some months ago I wanted to create a sample activity to present my point but I have run out of time so unfortunately I cannot show it to you. It would have been a Google Drive backed game with shared state (so the same as a typical shared activity in Sugar) called Scrabble what I try to port to SWA. It uses the following things which are trivial to use on the WEB but cannot be found in SWA: 1. Sign in. There is no authorization API in SWA so using anything than the local journal is problematic. Using Google's OAuth authentication from a file:// protocol is impossible so if you want to support existing code then you have to serve the activity from http://localhost... https://developers.google.com/drive/about-auth 2. Datastore. There is no way to access the Google Drive if you cannot authenticate. I do not see why would anyone use a new JavaScript lib which accesses only the journal when they are already familiar with some WEB technology. Like WEBDAV or the OpenStack's SWIFT API. http://docs.openstack.org/api/openstack-object-storage/1.0/content/storage-object-services.html Or simply using POST for uploading: https://developers.google.com/drive/manage-uploads 3. Collaboration. Using the Google Drive Realtime API is dead simple. It is the most missing feature from SWA BTW. https://developers.google.com/drive/realtime/ I have looked at several open source Operational Transformations libraries but did not have time to test their performance on an XO... 4. Using WebSockets for simple tasks. The autosaving can be implemented by the almost standard "webkitvisibilitychange" event (but you have to compile webkit with the appropriate parameters) and standard timers. Activity startup is simplified with per activity data store (POST-ing to the same server is the default on the WEB). I think it eliminates the communication with Sugar so no need for WebSockets... 5. Android port. There already exists a multi-platform technology called PhoneGap. It can target 100-200 million children so it can be called option 3 if you want... It can become obsolete as HTML5 provides more and more of its features though. http://phonegap.com/ So as I see you either create a framework which mimics Sugar and no web developer will use it or create a framework which implements what a web developer is already using or at least tries to somehow emulate it. So the web developer does not have to modify his/her code and will consider porting his/her application for a smaller platform. Of course that would require OLPC/Sugarlabs to run free OpenStack/OAuth/OT servers for contributors otherwise everybody will go with Google APIs which cannot easily be emulated on an XO machine... But as this discussion already happened and I have already written enough now, I just finish here. (In the following link you can replace the phrase "Per Activity Data Store" with "Standard WEB Storage" to be relevant...) http://lists.sugarlabs.org/archive/sugar-devel/2010-June/024589.html Thank you for your attention! Andrew ps: Now to say something constructive as well, some more words about the Journal. Recently I was watching one of Walter Bender's talks where he
Re: [Sugar-devel] Translating etoys home screen
The POT in the zip has been uploaded to Templates and propagated across langs. Project-Home.pot The following langs have been populated with the provided strings: de, es, fr, ja, pt, pt_BR, zh_CN I will also do the three English variants (en, en_US, en_GB). So at least now there is a means of capturing the strings in Pootle via translating the Project-Home.po for a given language. Building the .pr is left as a manual process for the moment. Daniel, ask the Armenian team translate these few words: http://translate.sugarlabs.org/hy/etoys_new/ On Wed, Oct 9, 2013 at 7:52 AM, Bert Freudenberg wrote: > On 09.10.2013, at 12:31, Chris Leonard wrote: > >> Bert, >> >> Would this POT capture everything that is needed? >> >> I can add it to Templates in Etoys and propagate it across langs. >> >> If you set it up in an SVN directory, we could even work on pushing it >> to your repo, in the meantime, it would at least be in Pootle. > > > I'm attaching a zip resulting from running the snippet below which exports > all translated strings from a project. In theory that could be used to > automate project translations in the future. And if someone makes the gallery > and tutorial projects translatable (by turning on the "translatable" property > on the right strings and providing one translation at least) we could use the > snippet to gather those strings, too. > > - Bert - > > | original translations msgids msgid msgstr ext | > original := LocaleID isoString: 'en'. > translations := Dictionary new. > msgids := Dictionary new. > World allMorphs do: [:m | (m isTextMorph and: [m translatable]) ifTrue: [ > msgid := (m translations at: original) asString. > msgids at: m externalName put: msgid. > m translations keysAndValuesDo: [:k :v | > (translations at: k ifAbsentPut: [Dictionary new]) > at: msgid put: v asString]]]. > translations keysAndValuesDo: [:locale :trans | > ext := locale = original ifTrue: ['.pot'] ifFalse: ['-', locale > asString,'.po']. > FileStream fileNamed: 'Project-', Project current name, ext do: [:f | > f lineEndConvention: #lf. > msgids keys asSortedCollection do: [:name | > msgid := msgids at: name. > msgstr := trans at: msgid. > locale = original ifTrue: [msgstr := '']. > f nextPutAll: '#: ', Project current name, '.pr ', > name; cr. > f nextPutAll: 'msgid "', (msgid copyReplaceAll: > String cr with: '\n'), '"'; cr. > f nextPutAll: 'msgstr "', (msgstr copyReplaceAll: > String cr with: '\n'), '"'; cr. > f cr.]]] > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Arch Linux XO image and Sugar packages
On Wednesday, 9 October 2013, James Cameron wrote: > On Tue, Oct 08, 2013 at 09:32:34PM -0500, Sebastian Silva wrote: > > dir u:\ > > > > clears the screen and shows some garbled text. > > On my laptop the usb drive mounts fine. > > Strange, no ? > > Looking into it further, it may relate to how Daniel advises you to > effectively destroy the device partition table by making the > filesystem on /dev/sdb rather than the usual methods. The result may > depend on what is already on the USB drive, and so is less > predictable > Can you explain why the result depends on what is already on the drive? Thanks -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Translating etoys home screen
Bert, Would this POT capture everything that is needed? I can add it to Templates in Etoys and propagate it across langs. If you set it up in an SVN directory, we could even work on pushing it to your repo, in the meantime, it would at least be in Pootle. On Wed, Oct 9, 2013 at 5:31 AM, Bert Freudenberg wrote: > On 08.10.2013, at 22:56, Daniel Drake wrote: > >> Hi Bert, >> >> Could you advise on how we could translate the etoys home screen to Armenian? >> >> I see: >> >> http://forum.world.st/How-to-translate-strings-in-Home-pr-td3527757.html >> >> However the crucial "how to translate" link there is broken. > > Ah, that's on the old wiki: > http://oldwiki.squeakland.org/display/sq/How+to+translate+Projects > > Would be great if someone could make a more thorough step-by-step guide, like > the one for the help system: > > http://oldwiki.squeakland.org/display/sq/How+to+translate+the+Quick+Guides > > However, these are different in that a separate project is used per language > and loaded on demand, whereas for the home-screen (and projects in general) > all the translations live in a single project together. > >> The first step in this translation would be to generate a list of >> strings so that I can pass them on for translation. > > > Yes. Unfortunately our in-project translation is not set up for gettext, and > the home screen is just a project as far as the system is concerned. > > Once you have changed the home screen project, you need to switch to the > hidden "Unnamed1" project (via ctrl-shift-w) and save the etoys image. > > - Bert - > > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel Home.pot Description: Binary data ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Translating etoys home screen
On Wed, Oct 9, 2013 at 5:31 AM, Bert Freudenberg wrote: > On 08.10.2013, at 22:56, Daniel Drake wrote: > >> Hi Bert, >> >> Could you advise on how we could translate the etoys home screen to Armenian? >> >> I see: >> >> http://forum.world.st/How-to-translate-strings-in-Home-pr-td3527757.html >> >> However the crucial "how to translate" link there is broken. > > Ah, that's on the old wiki: > http://oldwiki.squeakland.org/display/sq/How+to+translate+Projects > > Would be great if someone could make a more thorough step-by-step guide, like > the one for the help system: > > http://oldwiki.squeakland.org/display/sq/How+to+translate+the+Quick+Guides > > However, these are different in that a separate project is used per language > and loaded on demand, whereas for the home-screen (and projects in general) > all the translations live in a single project together. > >> The first step in this translation would be to generate a list of >> strings so that I can pass them on for translation. > > > Yes. Unfortunately our in-project translation is not set up for gettext, and > the home screen is just a project as far as the system is concerned. > > Once you have changed the home screen project, you need to switch to the > hidden "Unnamed1" project (via ctrl-shift-w) and save the etoys image. > > - Bert - > Just a thought, Since I think it is only three strings (that don't change often) , it would be very easy to dummy up a POT file for posting in Poolte. Admittedly, that translated PO would need to be manually transferred into individual .pr files by language; but at least the strings would be collected. cjl ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Translating etoys home screen
On 08.10.2013, at 22:56, Daniel Drake wrote: > Hi Bert, > > Could you advise on how we could translate the etoys home screen to Armenian? > > I see: > > http://forum.world.st/How-to-translate-strings-in-Home-pr-td3527757.html > > However the crucial "how to translate" link there is broken. Ah, that's on the old wiki: http://oldwiki.squeakland.org/display/sq/How+to+translate+Projects Would be great if someone could make a more thorough step-by-step guide, like the one for the help system: http://oldwiki.squeakland.org/display/sq/How+to+translate+the+Quick+Guides However, these are different in that a separate project is used per language and loaded on demand, whereas for the home-screen (and projects in general) all the translations live in a single project together. > The first step in this translation would be to generate a list of > strings so that I can pass them on for translation. Yes. Unfortunately our in-project translation is not set up for gettext, and the home screen is just a project as far as the system is concerned. Once you have changed the home screen project, you need to switch to the hidden "Unnamed1" project (via ctrl-shift-w) and save the etoys image. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
