Re: [Sugar-devel] [API proposal] Source editor and widget
We could start with just expanding 'document' view source to allow activities to offer files to be edited, like user CSS or TurtleArt code blocks. This way, we don't have to worry about bundles (yet). 2009/7/17 Tomeu Vizoso : > On Thu, Jul 16, 2009 at 09:15, Simon Schampijer wrote: >> On 07/16/2009 12:06 AM, Gary C Martin wrote: >>> On 15 Jul 2009, at 17:07, Lucian Branescu wrote: >>> >>>> Here it is >>>> http://wiki.sugarlabs.org/go/Development_Team/Almanac#How_do_I_create_a_text_box_for_code_editing.3F >>> >>> Thanks Lucian, I've been watching this thread from the sidelines. I >>> for one would LOVE the current 'view source' view to become an 'edit >>> source' view... Perhaps a lock button to prevent initial accidental >>> editing, and a revert to original (and/or undo if feasible). >>> >>> I guess even without revert/undo features, if installed Activities are >>> always accessible as bundles via the Journal (++), the original >>> version can always be resumed to overwrite some screwed up edits and >>> get back to a working state. The extra sugar coating for view/edit >>> source would then be an extra button for "Make Journal Activity >>> bundle" so that folks could turn edited source into something they >>> could perhaps share, 'send to -> friend', or restore at a later date >>> for further work (after using some official version). >>> >>> Regards, >>> --Gary >> >> Hi Gary, >> >> as you know - I am interested into the "edit view" as well. I think it >> is another little step towards our original goal to make modifying and >> hacking on Sugar as easy as possible - a first class user interaction. >> >> Making the current view editable are just a few lines. The main problem >> I see is: How do you store the new version of the activity? After >> editing I hit "make journal activity bundle" and get a copy of the >> original activity with my edits and the version number++? Actualy how >> about: You can edit, and as long as you do not hit the "make new bundle" >> button nothing in the original code will be changed. You end up with the >> new version of the activity once the button is hit. That way you do not >> need the undo and lock options. >> >> Can we phrase out the whole user interaction and the UI? We can use 803 >> for now - and turn it into a feature then. >> >> Regards, >> Simon >> >> PS: I remember that we wanted to change the versions of activities to >> have minor numbers as well in this release cycle. We should look into that. > > Yeah, I think this is a very big issue with lots of ramifications. I > would favour small steps forward than risk stalling again. > > Regards, > > Tomeu > >> >> >> ___ >> 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] menustage becomes karmaplatz.html
I'd still go for karmaindex.html :) 2009/7/21 Bryan Berry : > unless u have any strong objections, let's rename it to karmaplatz.html > > platz means plaza in German. > > karmaplatz sounds so odd that it is both memorable while at the same > time easy to spell. > > > -- > Bryan W. Berry > Technology Director > OLE Nepal, http://www.olenepal.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] question about: Main Karma Package
Now that I'm actually looking at the layout, I realise that you MUST
rename chakra.html/karmaplatz.html to index.html.
If you host the karma bundle somewhere on a web server, when you go to
the bundle ROOT path the server will try to serve index.html, because
that's the default. Since it's not there, it will 403.
Furthermore, if a random web developer with no knowledge of karma
looks inside the karma bundle, they will instinctively look for
index.html. Web devs also expect english, so chakra or karmaplatz will
not tell them anything.
]karmaindex.html might be alright for devs, but it still confuses web
servers and there's no reason to deviate from the de-facto standard of
index.html.
Sorry for the rant, but I really believe you're making a mistake by
not naming the file index.html. You may call the interface element
'karma index' if you like, because that's what it is.
2009/7/22 Bryan Berry :
> On Tue, 2009-07-21 at 17:49 -0500, Felipe López Toledo wrote:
>> Hi Bryan.
>>
>> I have one question about
>> http://wiki.sugarlabs.org/go/Karma/Bundle_layout
>> I'm working with our new layout ;)
>>
>> until yesterday, each lesson could work independently. each lesson had
>> their own js files.
>> The beauty of that way, was that you could take a specific lesson
>> folder and put it everywhere and it would work.
>>
>> if we want to do that with the new arrangement, it would be necessary
>> to carry:
>> The specific Lesson folder + Karma lesson bundle folder
>
> Exactly. the stuff common to all the lessons, like karma.css, jquery.js,
> goes in the top-level directory
>
> so ROOT > js/ , css/ , karmaplatz.html, lessons/
> lessons > js/, css/
>
> Does it seems like too much overhead to carry around the karmaplatz? I
> figure that most of the time devs will want the karmaplatz to accompany
> their lessons.
>
>> I would suggest to merge Karma lesson bundle / js with Lesson / js.
>> The problem is that we will have repeated files.
>
> Yeah. my best solution is just to separate them as specified before
>
>> also, the Main Karma Package has its own js folder ("..contain the
>> code common to all examples.."), I suppose it is not necessary since
>> we have the examples folder that will be (I suppose) a Karma Lesson
>> bundle folder.
>> or maybe I'm misunderstanding things.
>
> I want the examples to use the same common js/ and css/ folders as
> lessons/ . By default, the links to the examples will appear in
> karmaplatz.html . I want the paths used in the examples to be the same
> ones that can be used by the new user-created lessons in lessons/ .
> Using the same file directory layout makes this easier.
>
> So, I want the examples to look at root > css/, js/ for their common
> files just as the new "lessons" in lessons/ will
>
>>
>> felipe
>>
> --
> Bryan W. Berry
> Technology Director
> OLE Nepal, http://www.olenepal.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] Karma: geometry functions
Could this help? http://sylvester.jcoglan.com/ 2009/7/22 Felipe López Toledo : > Hi guys. > > I've been working on re-making some OLE Nepal lessons using javaScript, each > time I found new things to do, most of them related to geometry. > I think it's necessary to write some "geometry class" in order to expedite > the activities development. > > currently supported: > (draw) : rectangle, circle, > (numeric): distance between 2 points > > working on: > (draw) : polygon, ellipse > > could you suggest me some more functions? > > thanks in advance > > felipe > > ___ > 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] status of "adding up to 10"?
Crockford doesn't like it because if you forget to put new for a class declaration that otherwise needs it, all the attributes in the class are set on the global namespace. Hence, dangerous to forget. He suggests using factory functions, that create and return objects instead. Either way is fine, as long as your framework code is non-invasive. 2009/7/23 Bryan Berry : > it is fine w/ me > > I can't remember exactly why crockford doesn't like it > > On Wed, 2009-07-22 at 22:37 -0500, Felipe López Toledo wrote: >> Hi. >> >> I know, you've been playing around JS, maybe you have noticed about >> the *new* reserved word and its role. >> according to "Douglas Crockford, JavaScript: The Good Parts", "new" is >> dangerous (I'm agree) and the "Use of this style of constructor >> functions is not recommended". >> >> others, like "Jhon Resig, Pro JavaScript Techniques" just use it. >> >> I have found it's really normal to use "new" with JS (prototypal >> inheritance), so I'm using it. If someone wants me to change it. It's >> a really good moment to raise the hand. >> >> example: >> var p=new Point(1,2); >> >> also, the OOP style exists "getters" and "setters". >> var xval = p.getX( ) >> p.setX( 2 ); >> >> I prefer >> var xval = p.x; >> p.x = 2; >> >> jQuery works in the second way (or at least it's closer) >> >> felipe >> 2009/7/22 Felipe López Toledo >> working on >> >> I think you're going to present "karma", so I'm coding the >> plugin: >> jquery.karma.js >> >> >> 2009/7/22 Bryan Berry >> >> >> hey dude, what is the status? >> >> -- >> Bryan W. Berry >> Technology Director >> OLE Nepal, http://www.olenepal.org >> >> >> > -- > Bryan W. Berry > Technology Director > OLE Nepal, http://www.olenepal.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] status of "adding up to 10"?
http://www.jslint.com/, made by Crockford himself. There are others as well. 2009/7/24 Tomeu Vizoso : > On Thu, Jul 23, 2009 at 14:20, Lucian Branescu > wrote: >> Crockford doesn't like it because if you forget to put new for a class >> declaration that otherwise needs it, all the attributes in the class >> are set on the global namespace. Hence, dangerous to forget. >> >> He suggests using factory functions, that create and return objects instead. > > Are there static analysis tools such as pylint for JS? Might help > catching up these situations. > > Regards, > > Tomeu > >> Either way is fine, as long as your framework code is non-invasive. >> >> 2009/7/23 Bryan Berry : >>> it is fine w/ me >>> >>> I can't remember exactly why crockford doesn't like it >>> >>> On Wed, 2009-07-22 at 22:37 -0500, Felipe López Toledo wrote: >>>> Hi. >>>> >>>> I know, you've been playing around JS, maybe you have noticed about >>>> the *new* reserved word and its role. >>>> according to "Douglas Crockford, JavaScript: The Good Parts", "new" is >>>> dangerous (I'm agree) and the "Use of this style of constructor >>>> functions is not recommended". >>>> >>>> others, like "Jhon Resig, Pro JavaScript Techniques" just use it. >>>> >>>> I have found it's really normal to use "new" with JS (prototypal >>>> inheritance), so I'm using it. If someone wants me to change it. It's >>>> a really good moment to raise the hand. >>>> >>>> example: >>>> var p=new Point(1,2); >>>> >>>> also, the OOP style exists "getters" and "setters". >>>> var xval = p.getX( ) >>>> p.setX( 2 ); >>>> >>>> I prefer >>>> var xval = p.x; >>>> p.x = 2; >>>> >>>> jQuery works in the second way (or at least it's closer) >>>> >>>> felipe >>>> 2009/7/22 Felipe López Toledo >>>> working on >>>> >>>> I think you're going to present "karma", so I'm coding the >>>> plugin: >>>> jquery.karma.js >>>> >>>> >>>> 2009/7/22 Bryan Berry >>>> >>>> >>>> hey dude, what is the status? >>>> >>>> -- >>>> Bryan W. Berry >>>> Technology Director >>>> OLE Nepal, http://www.olenepal.org >>>> >>>> >>>> >>> -- >>> Bryan W. Berry >>> Technology Director >>> OLE Nepal, http://www.olenepal.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 >> > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] anybody working on qt integration in Sugar?
I've only went as far as trying a PyQt4 hello world. With qgtkstyle, it picks up the Sugar style and works nicely. 2009/7/24 Tomeu Vizoso : > If so, please share the state of things because I'm going to dedicate > a day to it during this weekend. > > Thanks, > > Tomeu > ___ > 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] python hulahop article
I've even heard that the mozilla folks want to deprecate XPCOM, in favour of more JavaScript usage in Firefox et all. 2009/7/26 Luke Kenneth Casson Leighton : > what would be _especially_ good would be for xpcom to be "broken out > of" xulrunner both in peoples' minds and also in actual real code. > xpcom is a dumbed-down version of DCOM (i.e. with the D removed and > many other features) and so i _know_ just how powerful it really is, > but very few other people - outside of the mozilla community - are. > which is a real surprise. > > you can register services as objects, and have them seamlessly > communicate across programming language barriers... that kind of > technology is just... gold dust! the mozilla community should be > raving their tits off about that! and it's just weird that they're > not doing that, whilst gobject is struggling to make ends meet. > > l. > ___ > 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
[Sugar-devel] Downloading data: URIs
There's a bug in Browse preventing it to save data: URIs. http://trac.sugarlabs.org/ticket/1029 I've implemented a workaround. You can either get that patch or my Browse branch http://git.sugarlabs.org/projects/browse/repos/webified to try it out. With data: URIs, web apps can create files and get them into the Journal. This works on all browsers (in Firefox, you are prompted to download a file), but it has its limitations. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Downloading data: URIs
Here's how using data URIs would work to create files or get things into the Journal. http://files.getdropbox.com/u/317039/datauridemo.html There's no way do read files or Journal objects, though. Gears should help with this, as offers a way to read files from JavaScript. I think Firefox has some APIs for manipulating files as well, that's how TiddlyWiki does itl. http://www.tiddlywiki.com/ 2009/7/29 Lucian Branescu : > There's a bug in Browse preventing it to save data: URIs. > http://trac.sugarlabs.org/ticket/1029 > I've implemented a workaround. You can either get that patch or my > Browse branch http://git.sugarlabs.org/projects/browse/repos/webified > to try it out. > > With data: URIs, web apps can create files and get them into the > Journal. This works on all browsers (in Firefox, you are prompted to > download a file), but it has its limitations. > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] logo for hulahop? https://bugzilla.mozilla.org/show_bug.cgi?id=507499
This is the browser's (called Browse actually) icon. http://git.sugarlabs.org/projects/browse/repos/mainline/blobs/master/activity/activity-web.svg 2009/7/31 Luke Kenneth Casson Leighton : > On 7/31/09, Tomeu Vizoso wrote: >> On Fri, Jul 31, 2009 at 13:01, Luke Kenneth Casson >> Leighton wrote: >> > hi folks if you'd like hulahop to have a chance of getting onto the >> > featured apps page a logo / icon would be needed. as this is a chance >> > for promotion of OLPC, sugarlabs as well as hulahop, could someone >> > consider logging in to the mozilla bugtracker and provide a link? >> >> >> We don't have such a logo AFAIK. In case someone is available to draw >> one and would like some suggestions, what about a python snake or a >> cute godzilla playing hula-hoop? > > :) > > is there an icon for the browser when it's started up? > > i'm doing a simple logo for pyjamas, a happy person made out of a > circle and two half-circles, one upside down (legs), hmmm, i know it's > like the XO thing except that's an X not circles, but hey :) > ___ > 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] [Karma] Resolution considerations
Those are in the right ballpark, but you should try to make the layout fluid if possible :) 2009/8/3 Christoph Derndorfer : > Hi, > after looking around a bit I think it makes sense to design Karma's Chakra > and lesson menu around a baseline resolution of 1024*600 or > 1024*768 since these values seem to be a good estimation for what to expect > in both regular PCs and especially netbooks. > > What do you think? > Christoph > -- > Christoph Derndorfer > co-editor, olpcnews > url: www.olpcnews.com > e-mail: christ...@olpcnews.com > > ___ > 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] A security vs. functionality question
Could you let the invited user in a chroot by default and only allow full access if the inviting user explicitly allows it? 2009/8/6 Benjamin M. Schwartz : > Gary C Martin wrote: >> How are two (or more!) remote individuals expected to co-operate and >> share the same command line and not mess up? > > 1. Out of band. > 1a. That can mean, for example, a pre-existing understanding of the > purpose of the session. If it's an "expert" connecting to perform an > operation, then you've already agreed about who's going to be doing most > of the typing. > 1b. Via a live chat. That can be as simple as a Chat activity instance. > Eventually, I am counting on overlay chat [1] and push-to-talk [2] to > solve the out of band communication problems. > > 2. Multiple windows > ShareTerm is built on GNU Screen, which supports multiple independent > windows not unlike what you describe. (It sometimes calls itself a "text > only window manager".) In "pair programming", for example, users could > type in separate buffers, looking over each other's shoulders periodically. > > [1] http://dev.laptop.org/attachment/ticket/3310/activity_chat_sketch.png > [2] http://wiki.laptop.org/go/Push_to_Talk > > > ___ > 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] A security vs. functionality question
Share with: My Neighborhood is too broad to allow full access. But Share with: John should be enough to assume that you trust John. Or instead have a separate option Share with: John (full acces). A chroot because afaik rainbow doesn't really work outside the XO distro My impression may be wrong, though. I had assumed everyone has root access, it is such a basic need for a machine you own. 2009/8/7 Benjamin M. Schwartz : > Lucian Branescu wrote: >> Could you let the invited user in a chroot by default and only allow >> full access if the inviting user explicitly allows it? > > 1. What sort of interface do you have in mind? What is more explicit than > "Share with: My Neighborhood"? > > 2. Why a chroot, and not Rainbow? > > 3. How do we create a chroot without requiring root privileges? (It seems > many Sugar users, such as those in Uruguay or on LTSP, will not have root.) > > --Ben > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Design help needed for web applications within Sugar
This a bit long-winded, but please bear with me. If you know my project, skip to the end. I've been working on Browse in the context of GSoC. http://wiki.sugarlabs.org/go/Webified Here's my blog http://honeyweb.wordpress.com and you can get the code from here http://git.sugarlabs.org/projects/browse/repos/webified. I can prepare an .xo bundle if needed. I've implemented Site Specific Browser creation and 'save complete page' functionality for Browse. An example of SSB is Mozilla Prism; Firefox has the option to save a page, complete with resources. Site Specific Browsers in Sugar are instances of Browse with a static home-page and a few extra capabilities, like bookmarklets, userscripts and userstyles (http://honeyweb.wordpress.com/2009/07/06/bookmarklets-userstyles-userscriptssort-of/). The web site loaded inside an SSB works just like it would normally, but it happens to be the default and it can be (easily) customised. This works very well for GMail, for example. In fact, I use GMail inside an SSB all the time (http://fluidapp.com). With Gears, you can even work with GMail offline. Saving a complete web page is useful for keeping a web page for offline viewing, of course. But for web apps with behaviour that does not depend on a having a network, they are similar in a way to SSBs. This would work very well for things like Karma lessons (see Felipe and Bryan's project http://karmaproject.wordpress.com/) and Paint Web http://code.google.com/p/paintweb/. Both ways produce a Journal object that can be run and opens a Browse instance with the desired web page, but they are very different technically. Both would be very useful and for different purposes, but they have some overlapping usage. How should these features be presented to the user? The screenshots on my blog show the current situation. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design help needed for web applications within Sugar
Sorry, I should have pointed that out more clearly. In this image (http://files.getdropbox.com/u/317039/userscript%20hello%20world.png), the button in the top right, next to the bookmark button, is the button used for creating SSBs. Here (http://dl.getdropbox.com/u/317039/create%20ssb.png) is an even better screenshot. 2009/8/10 Benjamin M. Schwartz : > Lucian Branescu wrote: >> How should these features be presented to the user? The screenshots on >> my blog show the current situation. > > They do? I don't see anything there that shows the current SSB creation > or site-zip-saving UI. > > --Ben > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design help needed for web applications within Sugar
In fact, there is the option to install the SSB activity as well, http://dl.getdropbox.com/u/317039/create%20ssb.png rgs on IRC suggested that the 'Keep in Journal' button could either save an offline version by itself or there could be a drop down with several options. About modifying SSBs, right now all the tools for modification are inside the actul activity. I'd like to see modification of userscripts and userstyles done in 'View Source' (as well). 2009/8/11 Simon Schampijer : > On 08/10/2009 11:56 PM, Lucian Branescu wrote: >> >> This a bit long-winded, but please bear with me. If you know my >> project, skip to the end. >> >> I've been working on Browse in the context of GSoC. >> http://wiki.sugarlabs.org/go/Webified >> Here's my blog http://honeyweb.wordpress.com and you can get the code >> from here http://git.sugarlabs.org/projects/browse/repos/webified. I >> can prepare an .xo bundle if needed. I've implemented Site Specific >> Browser creation and 'save complete page' functionality for Browse. An >> example of SSB is Mozilla Prism; Firefox has the option to save a >> page, complete with resources. >> >> >> Site Specific Browsers in Sugar are instances of Browse with a static >> home-page and a few extra capabilities, like bookmarklets, userscripts >> and userstyles >> (http://honeyweb.wordpress.com/2009/07/06/bookmarklets-userstyles-userscriptssort-of/). >> The web site loaded inside an SSB works just like it would normally, >> but it happens to be the default and it can be (easily) customised. >> This works very well for GMail, for example. In fact, I use GMail >> inside an SSB all the time (http://fluidapp.com). With Gears, you can >> even work with GMail offline. >> >> Saving a complete web page is useful for keeping a web page for >> offline viewing, of course. But for web apps with behaviour that does >> not depend on a having a network, they are similar in a way to SSBs. >> This would work very well for things like Karma lessons (see Felipe >> and Bryan's project http://karmaproject.wordpress.com/) and Paint Web >> http://code.google.com/p/paintweb/. >> >> >> >> Both ways produce a Journal object that can be run and opens a Browse >> instance with the desired web page, but they are very different >> technically. Both would be very useful and for different purposes, but >> they have some overlapping usage. >> >> How should these features be presented to the user? The screenshots on >> my blog show the current situation. > > So saving the current page, could be a button, like shown in the screenshot > now. If we want to special case the SSB creation, it could be an option in > the button palette. > > The SSB can be installed to the system as well. We want maybe an install > option in the alert. And maybe there should be an install option from the > journal as well. Activities we install directly when downloaded, we could > handle it the same way, with the SSB as well. > > The entries could have a badged browse icon. To distinguish them from the > rest of the Browse activity entries. When you click on an 'offline webpage' > entry a Browse instance could be opened showing that entry. One could think > about opening it in a new tab, when a Browse instance is already running, in > the future. > > One thing that needs thinking as well is the modifying of the SSB (other > icon etc). Maybe an activity could handle that? Maybe an option in a develop > activity? > > Regards, > Simon > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML 5 article and validator
There's realStorage (http://code.google.com/p/realstorage/), but I don't know if it's mature enough. You could always use one of the various JS ORMs, that usually have several backends, as varied as html5, gears, cookie, flash cookie, activex, etc. 2009/8/11 Bryan Berry : > On Tue, 2009-08-11 at 17:04 +0545, Christoph Derndorfer wrote: >> Finally had a chance to read a quick intro article to HTML 5 >> (http://www.smashingmagazine.com/2009/07/16/html5-and-the-future-of-the-web/) >> which also linked to an (experimental) HTML 5 validator >> (http://html5.validator.nu/). >> >> >> I'm thinking especially the validator could come in quite handy for >> Karma development work. > > I agree and it should be bundled w/ the utilities in utils/ > > >> >> BTW, let me know if you stumble across other HTML 5 articles and >> tutorials, I'm particularly interested in information and how-tos on >> how to use the offline storage functionality. > > will do. The only ones I have seen so far seem to be for mozilla like > this one > > https://developer.mozilla.org/En/Offline_resources_in_Firefox > > it appears to be very specific to firefox > > > http://dev.w3.org/html5/webstorage/ > > It sounds like some browser storage solutions use SQL, which I want to > avoid. SQL is really overkill for our purposes. I would prefer a simple > key/pair storage that you could read and write to w/ js. > > I like this guy's implementation but I have no idea where is has gone > since he wrote this blog entry > http://labs.mozilla.com/2009/04/towards-better-browser-storage/ > > >> >> Thanks, >> Christoph >> >> -- >> Christoph Derndorfer >> co-editor, olpcnews >> url: www.olpcnews.com >> e-mail: christ...@olpcnews.com >> > -- > Bryan W. Berry > Technology Director > OLE Nepal, http://www.olenepal.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] Design help needed for web applications within Sugar
Silly me. Here's the proper link http://en.wikipedia.org/wiki/Site-specific_browser 2009/8/11 Lucian Branescu : > Sorry, it's my fault. Here http://en.wikipedia.org/wiki/SSB > > It's a specialised Browser that runs a single web site. It may be > customised for that certain web site. An example is Mozilla Prism. > > If you want more info, read the webified wiki page and my blog, but > it's a lot to read. > > 2009/8/11 Christian Marc Schmidt : >> Hi Lucian >> >> Can you explain to me what SSB means? Sorry for my naivete, it's probably >> perfectly clear to everyone else. >> >> Generally these look fine, but I think we could probably clarify the >> interaction a bit after you give me a few pointers on what you are trying to >> do. >> >> Thanks! >> >> Christian >> >> On Mon, Aug 10, 2009 at 6:21 PM, Lucian Branescu >> wrote: >>> >>> Sorry, I should have pointed that out more clearly. In this image >>> (http://files.getdropbox.com/u/317039/userscript%20hello%20world.png), >>> the button in the top right, next to the bookmark button, is the >>> button used for creating SSBs. >>> >>> Here (http://dl.getdropbox.com/u/317039/create%20ssb.png) is an even >>> better screenshot. >>> >>> 2009/8/10 Benjamin M. Schwartz : >>> > Lucian Branescu wrote: >>> >> How should these features be presented to the user? The screenshots on >>> >> my blog show the current situation. >>> > >>> > They do? I don't see anything there that shows the current SSB creation >>> > or site-zip-saving UI. >>> > >>> > --Ben >>> > >>> > >> >> >> >> -- >> anyth...@christianmarcschmidt.com >> >> http://www.christianmarcschmidt.com >> >> 917/ 575 0013 >> > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design help needed for web applications within Sugar
Sorry, it's my fault. Here http://en.wikipedia.org/wiki/SSB It's a specialised Browser that runs a single web site. It may be customised for that certain web site. An example is Mozilla Prism. If you want more info, read the webified wiki page and my blog, but it's a lot to read. 2009/8/11 Christian Marc Schmidt : > Hi Lucian > > Can you explain to me what SSB means? Sorry for my naivete, it's probably > perfectly clear to everyone else. > > Generally these look fine, but I think we could probably clarify the > interaction a bit after you give me a few pointers on what you are trying to > do. > > Thanks! > > Christian > > On Mon, Aug 10, 2009 at 6:21 PM, Lucian Branescu > wrote: >> >> Sorry, I should have pointed that out more clearly. In this image >> (http://files.getdropbox.com/u/317039/userscript%20hello%20world.png), >> the button in the top right, next to the bookmark button, is the >> button used for creating SSBs. >> >> Here (http://dl.getdropbox.com/u/317039/create%20ssb.png) is an even >> better screenshot. >> >> 2009/8/10 Benjamin M. Schwartz : >> > Lucian Branescu wrote: >> >> How should these features be presented to the user? The screenshots on >> >> my blog show the current situation. >> > >> > They do? I don't see anything there that shows the current SSB creation >> > or site-zip-saving UI. >> > >> > --Ben >> > >> > > > > > -- > anyth...@christianmarcschmidt.com > > http://www.christianmarcschmidt.com > > 917/ 575 0013 > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design help needed for web applications within Sugar
2009/8/11 Simon Schampijer : > On 08/11/2009 12:14 PM, Lucian Branescu wrote: >> >> In fact, there is the option to install the SSB activity as well, >> http://dl.getdropbox.com/u/317039/create%20ssb.png > > Yes seen that. > >> rgs on IRC suggested that the 'Keep in Journal' button could either >> save an offline version by itself or there could be a drop down with >> several options. > > Do you mean the activity keep button? Like the one in Write - where we have > the options to save a richt text format or others? If yes - yeah that sounds > like a good option actually. I'll go ahead and try to implement that, then. > >> About modifying SSBs, right now all the tools for modification are >> inside the actul activity. I'd like to see modification of userscripts >> and userstyles done in 'View Source' (as well). > > Oh, yeah view source. Sounds interesting to me, too. We just need to make > sure to not overload it. I mean editing text is easy. When it comes to > changing the icon it gets more complicated, though. Perhaps the Sugar shell should allow users to change activity icons? In any case, View Source already has Document view and Bundle view. We could either expand Document view to have a TreeView on the left like Bundle view or create a separate Editables view. > > Regards, > Simon > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design help needed for web applications within Sugar
View source would only be used for editing small things, like TurtleArt code blocks and userstyles, but no actual activity code. The activity would offer a list of pseudo-files that are to be edited by users. Changes to these would be applied immediately in the activity, so it would be easier to switch between View source and the activity. Would you consider this case too much overloading? 2009/8/11 Eben Eliason : > On Tue, Aug 11, 2009 at 1:13 PM, Lucian > Branescu wrote: >> 2009/8/11 Simon Schampijer : >>> On 08/11/2009 12:14 PM, Lucian Branescu wrote: >>>> >>>> In fact, there is the option to install the SSB activity as well, >>>> http://dl.getdropbox.com/u/317039/create%20ssb.png >>> >>> Yes seen that. >>> >>>> rgs on IRC suggested that the 'Keep in Journal' button could either >>>> save an offline version by itself or there could be a drop down with >>>> several options. >>> >>> Do you mean the activity keep button? Like the one in Write - where we have >>> the options to save a richt text format or others? If yes - yeah that sounds >>> like a good option actually. >> >> I'll go ahead and try to implement that, then. >> >>> >>>> About modifying SSBs, right now all the tools for modification are >>>> inside the actul activity. I'd like to see modification of userscripts >>>> and userstyles done in 'View Source' (as well). >>> >>> Oh, yeah view source. Sounds interesting to me, too. We just need to make >>> sure to not overload it. I mean editing text is easy. When it comes to >>> changing the icon it gets more complicated, though. >> >> Perhaps the Sugar shell should allow users to change activity icons? > > It's an unfortunate fact that there is no activity suitable for > creating SVG icons for Sugar. We need a "Draw" activity to fill this > gap and compliment Paint... > >> In any case, View Source already has Document view and Bundle view. We >> could either expand Document view to have a TreeView on the left like >> Bundle view or create a separate Editables view. > > I hesitate to overload the view source mechanism this way, actually. > Should we instead be providing a seamless mechanism for modifying > code, icons, etc. with other activities, so that users (eventually) > have choices regarding their editors? View source is a logical step in > the process, so we should certainly expose the ability to launch into > editing from there, of course. I suppose an alternative argument can > be made for the level of integration we could provide when editing > within the view source dialog. If we could hook it up to have > "real-time" effect on the running activity, so that making a change > couldbe tested right away, that may make it worth doing... > > Eben > >>> >>> Regards, >>> Simon >>> >> > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity toolbar redesign: What to do with 'simple' activities?
Would it be possible to offer a more compact design, with a single bar, but with the new API? 2009/8/12 Simon Schampijer : > Hi, > > I just ported the hello world example to the new toolbar design [1]. I > remember that once Gary pointed out, that simple activities will look > 'empty' when we move them to the new design (screenshot attached), Chat > would be a famous case. Most of the activities does have options, though. > > How do we go forward with that? Live with that compromise? Other ideas? > > Thanks, > Simon > > [1] > http://git.sugarlabs.org/projects/hello-world/repos/mainline/blobs/master/activity.py#line36 > > ___ > 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] Deployment feedback braindump
Adobe apparently loves vectors. JavaScript-in-PDF is mostly a joke and a big security risk. It's not something to be relied upon. Forms are about as much interaction as PDF get without becoming dangerous or moot. 2009/8/12 Bernie Innocenti : > El Wed, 12-08-2009 a las 07:22 -0400, Albert Cahalan escribió: >> Finally, you can put JavaScript in a PDF. I'm not sure if any of >> the free software viewers can handle this yet. In theory you can >> have all sorts of animations. It's kind of like flash. > > Yes, and it's kind of like SVG, too. > > And isn't it funny how one company monopolizes *all* these vector > graphics standards that were supposed to compete with each other: > PostScript, PDF, Flash and SVG. > > > -- > // 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] Deployment feedback braindump
2009/8/12 Bernie Innocenti : > El Wed, 12-08-2009 a las 13:28 +0100, Lucian Branescu escribió: >> Adobe apparently loves vectors. > > And monopolies. That too :) But really, they're obsessed with vectors. > >> JavaScript-in-PDF is mostly a joke and a big security risk. It's not >> something to be relied upon. > > It might be useless, but I don't see why it should be more risky than > Javascript in web browsers, which everybody happily accepted without > much thought. Is JS in PDF even allowed to make HTTP connections? > JavaScript in PDF is more risky because the sandboxing isn't as mature as the one in web browsers. It should theoretically be at least as safe, but in practice it isn't. This is mostly a problem with adobe's implementation, which is an absolute train-wreck, but other implementers without browser sandboxing experience might repeat some mistakes. > >> Forms are about as much interaction as PDF get without becoming >> dangerous or moot. > > How do you dubmit the form? By HTTP? Does the PDF reader tell the user > when it's going to make this connection? You would submit the form by sending back the completed PDF file. It's a bit awkward, but it works. Ideally, people should be using HTML forms, those are made to be easily and seamlessly submitted. > > Knowing how proprietary software companies think, I wouldn't ever dare > using Adobe Acrobat Reader. But I blindly trust Evince, Okular and all > free PDF readers to do whatever it takes to protect my security and > privacy regardless of what the document or the PDF standard tells them > to do. > In any case, PDF is a good presentation format. Why make it significantly more complex for small-to-none improvements to its main purpose? > -- > // 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] Deployment feedback braindump
2009/8/12 Albert Cahalan : > On Wed, Aug 12, 2009 at 10:16 AM, Lucian > Branescu wrote: >> 2009/8/12 Bernie Innocenti : >>> El Wed, 12-08-2009 a las 13:28 +0100, Lucian Branescu escribió: > >>>> JavaScript-in-PDF is mostly a joke and a big security risk. It's not >>>> something to be relied upon. >>> >>> It might be useless, but I don't see why it should be more risky than >>> Javascript in web browsers, which everybody happily accepted without >>> much thought. Is JS in PDF even allowed to make HTTP connections? >> >> JavaScript in PDF is more risky because the sandboxing isn't as mature >> as the one in web browsers. It should theoretically be at least as >> safe, but in practice it isn't. This is mostly a problem with adobe's >> implementation, which is an absolute train-wreck, but other >> implementers without browser sandboxing experience might repeat some >> mistakes. > > Anybody sane would just grab a mature engine from a browser. > > The recent supposed JavaScript problems in Acrobat are nothing > more than heap spraying; there are at least two non-JavaScript ways > to do that. The exploit was recently redone w/o any JavaScript. > > Note that PDF, being essentially postscript, already comes with > a full programming language. That's what postscript **is**. So what's the point of JavaScript in PDFs then? > >>> How do you dubmit the form? By HTTP? Does the PDF reader tell the user >>> when it's going to make this connection? >> >> You would submit the form by sending back the completed PDF file. It's >> a bit awkward, but it works. >> >> Ideally, people should be using HTML forms, those are made to be >> easily and seamlessly submitted. > ... >> In any case, PDF is a good presentation format. Why make it >> significantly more complex for small-to-none improvements to its main >> purpose? > > PDF forms often look attractive. HTML forms normally look ugly. > This is because PDF is a good presentation format. HTML is not. > This of course depends on your browser. I think HTML forms look great, but that's because I use OS X or KDE. > Printing a PDF form to fill it out the old-fashioned way is reasonable. > You can even fill most of it out, print it, and then sign it or stamp it. > With HTML this really isn't practical. You can do it with HTML and it would be perfectly practical if there were a format based on a HTML subset that specified printable forms. That would be moot though, since PDF is much better at printables already. > > In the case of math worksheets, the child really needs a way to > scribble on the document. This is for handwriting practice and to > allow arbitrary free-form drawing and layout. PDF can provide this, > either via printing or via wrapping extra postscript code around the > document. To do this in HTML you'd have to write a custom app > in JavaScript, Java, or flash -- none of which is really HTML at all. > You could indeed do it on PDF only, like Okular and Preview (OS X) can annotate PDFs. But you could do it with HTML & JS, with the html5 (JS is HTML's native programming language, equivalent to PS). The drawback to the second is, as with printing, that HTML is very general. An easily printable subset of HTML would be needed for this. I believe JavaScript in PDF to be useless bloat. PostScript should be enough for all PDF needs. If it isn't, then PDF is probably the wrong format to use. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] discovering open clip art library
The main website (http://www.openclipart.org/) works just fine for me in Firefox 3.5. 2009/8/13 Bryan Berry : > On Thu, 2009-08-13 at 13:37 +0545, Christoph Derndorfer wrote: >> On Thu, Aug 13, 2009 at 12:08 AM, Bryan Berry >> wrote: >> I am embarrassed to say that I wasn't aware that the Open >> ClipArt >> Library existed. >> >> I imagine they have similar goals and needs for a content >> management >> system if theirs doesn't already satisfy them. >> >> http://www.openclipart.org >> >> http://www.openclipart.org/wiki/Document_Management_System >> >> >> Not really sure what I'm looking at here except for a Web site with a >> very broken layout and a Spam infested wiki page... > > I started using the site by browsing the library from w/in the inkscape > application. I too, haven't had any success browsing the main site. > >> The describtion of their dms is also so short that I'm not sure what >> to make of it? > > there are a lot of notes farther down the page > >> >> Christoph >> >> -- >> Christoph Derndorfer >> co-editor, olpcnews >> url: www.olpcnews.com >> e-mail: christ...@olpcnews.com > -- > Bryan W. Berry > Technology Director > OLE Nepal, http://www.olenepal.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] Bundling libraries, RPMs? (was Re: WatchMe-1, a VNC activity)
As a linux user much of my life and an OS X user for the past year, I dearly miss package management. Self-contained bundles are ok as far as they have minimal dependencies besides the existing platform libraries. When you simply bundle everything, you get 100MB+ bundles for pretty much everything and enormous memory usage because of no shared libs. 2009/8/18 Gary C Martin : > Hi Bert, > > On 18 Aug 2009, at 09:10, Bert Freudenberg wrote: > >> On 17.08.2009, at 23:34, Gary C Martin wrote: >> >>> For the Mac users, it's just "Drag this application to your >>> application folder." Done, end of story. For the worst application >>> offenders (and there are some, usually some of the big corps who can >>> get away with it) the user is asked for their admin password, but >>> this >>> always looks like shoddy, dodgy application development from >>> developers who don't really know what they are doing on a Mac. >> >> Gary, this is highly unfair to Mac developers. >> >> Self-contained bundles can be installed just by drag-and-drop >> indeed. But you need an installer (which might ask for an admin >> password) to integrate with the system, e.g. to install QuickLook >> plugins which generates previews for your documents, or SpotLight >> for indexing. And obviously the "big corps" do define their own >> document types, and want them to integrate with the system. Users >> expect them to. >> >> E.g., Etoys needs an installer on the Mac to put its web browser >> plugin in the right library folder. It does nothing "evil", the main >> app could as well be installed by drag-and-drop, but we can't expect >> everyone to manually install the plugin. Also, the plugin needs to >> know where to find the app so we must require the app to be >> installed into /Applications. And once we have a QuickLook plugin we >> will need to install that too. Now you may call Etoys development >> "shoddy and dodgy" all you like, but please blame it for its actual >> faults. > > Hmmm Sorry Bert, but pretty sure everything you mention above > (QuickLook, SpotLight indexing, file document types/icons, web > plugins) for can go in the users ~/Library with absolutely no need to > request admin permissions for the whole system (affecting all users). > > I agree you might want to use an installer rather than drag and drop, > though first run of an App could put these extras in place as needed. > As for hard-coding a path to /Applications, you can ask the system to > tell you the path to the application bundle, but if I remember, there > are a few cases where even Apple slips up on this one (and I'm sure > causes no end of bug reports and support calls for Apple when folks > system upgrade after moving such an Application) – so I won't diss you > too much for that hack ;-) > > Also as an alternitive, if you have control of the file format bundle, > QuickLook previews and SpotLight indexes can also live there, though I > understand that you'll likely want to keep with an existing cross- > platform file format that can't take advantage. > > So I'd say Etoys could just be a single drag'n'drop Mac application > into Applications folder (that does it's extras on first run, MS Mac > apps do this quite a bit), or at the very least a regular package > installer with no need for the admin password. > > Apologies for the off list topic reply. > > Regards, > --Gary > > P.S. So, can I have a job now making Etoys truly Mac friendly ;-) > > ___ > 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] trac problems
It's slow (as usual), but it works for me. 2009/8/21 Tomeu Vizoso : > Hi, > > is anybody still having problems with dev.sugarlabs.org? > > Thanks, > > Tomeu > > -- > «Sugar Labs is anyone who participates in improving and using Sugar. > What Sugar Labs does is determined by the participants.» - David > Farning > ___ > 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] any luck w/ venkman?
Is there something you need that firebug can't do? 2009/8/22 Bryan Berry : > hey subzero, > > I have been trying to use the latest version of venkman w/ ff 3.5 . I > can't get it to stop on breakpoints or actually do any debugging w/ it. > > Has it worked for you? > > -- > Bryan W. Berry > Technology Director > OLE Nepal, http://www.olenepal.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] [karma] early draft of karma presentation
You could send strings for function blocks that can later be eval-ed. But the eval itself might slow things down a lot. You can also send JSON objects between workers. Some browsers serialise the JSON to string and then re-eval it, others send the actual object. About shared data, try to stay away from it anyway. Message passing is desirable most of the time. 2009/8/25 Felipe López Toledo : > Hi > in my early post I talked about > canvas vs SVG (slide #28) > why not processingJS? (slide #28) > here some technical stuff: > --- > Browser Optimization (slide #29) > Karma lessons must run under the XO-1. > Default browser: Browse ( based on Gecko ) > Experimental: Surf ( based on webkit ) > No problem with html elements (div, img, ...) > What about canvas content? > Under a normal browser clearing and redrawing the canvas objects may not be > a problem, but remember that the XO has not that kind of normal resources. > We must use them efficiently. > If we have no option, it's preferable to spend cpu than spend memory. > We emphasize rendering speed over quality > image-rendering / firefox 3.6 alpha > webkit has nothing > Quadrilaterals (http://karma.sugarlabs.org/quadrilaterals/) > how does it work? > 2 canvases > the first for temporal drawing of the current line > cleared and re drawn when "mousemove" > the second has the drawn polygon, background, etc.. > Quadrilaterals under Browse has a severe lag problem (unusable) > Quadrilaterals under Surf works nice > Surf-106 is faster than Browse-102, should we use Webkit or Gecko? > -- > Web Workers (slide #30) > We tried to use web workers to handle animations: an animation core. > The animation core would be running as a worker thread: doing the neccesary > calculations for the animated objects and sending messages to the root > document to manipulate (update) the neccesary html elements (canvas...) > We try to combine actions with predictable behaviour. > Problems: > it's not possible to send functions as worker messages, so, it's hard to use > callbacks. > how to share memory (variables) between the root document and the worker > thread without copying that data? > -- > 2009/8/21 Christoph Derndorfer >> >> Hey guys, >> I basically agree with the points raised here so far and have a couple to >> add myself: >> slide #11: I would also mentioned that you had tried eToys/Squeak >> slide #24: I'm not sure we agreed on each lesson having to include a >> tutorial and an exercise. Of course this is a good goal but the question is >> whether we should really make that a requirement? >> slide #32: "i81n";-) >> slide #43: add link to Karma blog at http://karmaproject.wordpress.com/, >> add at least one e-mail address for direct contact, add link to Sugar >> mailing-list (http://lists.sugarlabs.org/listinfo/sugar-devel) >> That's all I can think of for now... >> Christoph >> 2009/8/21 Felipe López Toledo >>> >>> Hi guys >>> >>> Joshua, Bryan has talked Christoph and me about you, thanks for writing >>> :) >>> * I would update the slide "Nobody Wants to Help", to something like, "Flash is a poor longterm solution." I would drop the claim "Flash Devs don't like to share." I would - Despite the great work of the free software community on projects like Gnash and the GameSWF library, there is very little in terms of sharing and collaboration of free software Flash projects. >>> >>> +1 - There is no free software Flash development tool, >>> >>> mmm, I remember MTASC http://www.mtasc.org/ instead almost all Flash development is done through the proprietary software created by Macromedia. >>> >>> +1 >>> >>> Bryan, really good draft, here some initial feedback: >>> >>> 1. SVG vs canvas >>> I used RaphalJS (http://raphaeljs.com/) demos to test SVG animatios using >>> Browse and Surf, >>> results: >>> under surf: the XO crashed several times :( >>> under Browse: the animations look really good, but the performance is >>> really bad (you will get a several lag when clicking something, etc...) >>> >>> canvas is low level so, canvas drawing is faster than SVG drawing. >>> about manipulation, well, It's really easy to manipulate SVG Objects >>> (everything you draw is an object) but canvas is just a box where you can >>> draw, Karma provides (some of) that objects. >>> >>> 2. why not processingjs? >>> processingjs by default uses processing language, then if you want to use >>> it you'll need to learn processing syntax... to support that syntax, >>> processingjs uses a parser, so, it's slower than simple JS. >>> in fact, you can use javascript to access processingjs objects, but.. the >>> actual processingjs library is not designed to work under the XO, neither to >>> work as a jQuery plugin. >>> I think jresig doesn't encourage to use processing (syntax), he just take >>> processing because processing was there (looking for the reference) >>> >>> I will add more info on the technical stuff. >>> >>> regards >>> >>> On
Re: [Sugar-devel] OCR?
Abbyy could distribute the free version of their software with a license that allows it to be redistributed with Sugar, or more precisely whatever activity uses it. But that would allow people to make full-featured clones of Abbyy's software, so I doubt it. 2009/8/28 Edward Cherlin : > I was at a presentation last week of Abbyy OCR software, which works > on pictures taken by mobile phone cameras in more than 100 languages. > The company wants to give away software (though not source code) in > was that will get the company good publicity. So we are talking about > using their software with the XO camera to read signs or full pages in > books. Also whether we can add languages. > > This would mean making the OCR engine a separate download, the way we > handle Adobe Flash. > > So is this likely to be worth the effort? > > Is there a Free Software OCR engine of adequate quality? > > Any other questions? > > -- > Edward Mokurai Cherlin > Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name, and > Children are > my nation. The Cosmos is my dwelling place, the Truth my destination. > http://earthtreasury.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] The ARM is near
This is a bit of a stretch, but would it be possible to distribute GIMPLE or LLVM IR and finish the compilation on installation? Installing would take longer, but it should work on any architecture the code can compile to. 2009/8/29 Tomeu Vizoso : > 2009/8/29 Philippe Clérié : >> Well, I wasn't attempting to solve anything. I thought I was just >> brainstorming. >> >> These past few weeks there have been a lot of discussions about >> processes. Meanwhile, I am heading into the classroom with a >> somewhat unstable and unfinished platform not to mention very little >> guidance as to exactly how to make this thing work. I'll probably >> let the kids take the lead. >> >> Calling Sugar a distribution might not solve anything (certainly not >> my own problems), but it might help us focus on the practical matter >> of deciding how to put out that distibution instead of arguing about >> how to decide what we're about to do. > > Ok, so the idea is to focus our resources on the distribution level? > I'm not very fond of that because: > > - we aren't a company that has resources and puts them wherever its > management says so. Work is done by volunteers and they work on > whatever they fancy. I think that having less focus is useful here > because brings more interested people onboard that we otherwise > wouldn't have. > > - polishing a distribution is _lots_ of work. Canonical, Novell, > Redhat, etc. are putting lots of resources into there. I think that a > small set of people can take one of those distros and make it work > better for a specific use case, but we aren't going to outrun the big > players in a generic, polished distro. > > - other organizations are already taking Sugar and distro bits and > putting them together for their specific use cases. Maybe no one is > doing that yet for your use cases, but I don't think it means that we > need to drop whatever we are doing and do that instead. If we have > opportunities open and advertise them properly, we may get people to > do the work. > > - if we abandon upstream development, what point is in packaging it? > > Regards, > > Tomeu > >> -- >> >> >> Philippe >> >> -- >> >>> So is the only problem what we are calling Sugar today? If we >>> rename SoaS to Sugar and Sugar to Sucrose, how we would be >>> solving anything? >>> >>> Thanks, >>> >>> Tomeu >>> >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> > > > > -- > «Sugar Labs is anyone who participates in improving and using Sugar. > What Sugar Labs does is determined by the participants.» - David > Farning > ___ > 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] The ARM is near
I suggested pre-parsed code mostly to get rid of dependency on headers and other source packages; a bit like a JIT that always compiles and caches everything. LLVM IR in particular is just a high lever assembler, so it could be distributed without any dependencies (even on build tools). There's also the small advantage that developers get to not only parse, but optimise the code beforehand, so code generation on a production machine should be rather fast. This whole idea may be too complex for its own good, though. As for more conventional compilation strategies, I think it would be best if Sugar itself to compiled all the code from the bundle on installation, instead of leaving it to the activity. Then, the activity developer simply includes all the C source and headers, much the way one would include python source. 2009/8/29 Benjamin M. Schwartz : > Lucian Branescu wrote: >> This is a bit of a stretch, but would it be possible to distribute >> GIMPLE or LLVM IR and finish the compilation on installation? >> Installing would take longer, but it should work on any architecture >> the code can compile to. > > Currently, Sugar has a number of blessed interpreters: CPython, > Spidermonkey, Squeak, bash, and arguably sed and awk. I think it would be > easy to add a C compiler to the list. (I also think skipping the C parser > stage by shipping an intermediate representation is a premature optimization.) > > Providing a C compiler would enable the use of C source code in activity > bundles. Activities would be responsible for running a script to initiate > compilation, and for caching the binaries in /data to avoid recompiling on > every launch. We can provide a standard script for this (like > sugar-launch), for the convenience of activity authors. It would be useful. > > It's more difficult to say that simply adding a compiler solves the > problem of dependencies on existing binary packages. For example, many > packages require build systems like ant, autotools, CMake, GNU make, > imake, or SCons. Unless we also provide all of these build systems, > Activities will have to compile the build systems for their dependencies, > before they can build their dependencies. It may be acceptable to bless > one or more of these build systems, to partially alleviate this problem. > > Activity bundles can test for the presence of installed applications > easily enough, to avoid unnecessary compilation. They may also attempt > to download arch-appropriate binary packages over the internet, and > compile the included source only if such binaries cannot be found. (I am > specifically referring to binary packages constructed to permit > unprivileged installation and use, such Gentoo Prefix binpackages or > 0install bundles.) We could provide a service to allow Activities to > search for binary packages already downloaded, and inform them of > preferred package servers. > > Activities could also pause and ask the user to install certain packages > through the system package manager, falling back to compilation only if > the user declines (or fails). It may be possible to use PackageKit and > PolicyKit to streamline this process, but it does not seem to be strictly > necessary. > > A remaining serious issue is headers. I don't yet totally understand this > problem, but many applications can only be compiled in the presence of > appropriate library headers, and in many distributions the appropriate > headers are not present by default (they are in -devel packages). It may > be necessary for Sugar to depend on all these -devel packages so that > Activities can compile and link correctly. This is a significant cost in > disk space. > > --Ben > > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Karma] experimenting w/ canvas, drawImage draws a distorted pic
I think canvas pixels are different from css pixels. In canvas you get the pixels of the internal rendering engine and with css you get the device-modified pixels. 2009/8/31 Bryan Berry : > apparently, everything gets screwed up when i put the height and width > in css but works fine when i put the same values in the tag > > On Mon, 2009-08-31 at 13:47 +0545, Bryan Berry wrote: >> subzero, >> >> http://karma.sugarlabs.org/mainline/experiments/mytest1.html >> >> http://git.sugarlabs.org/projects/karma/repos/mainline/blobs/master/experiments/mytest1.html >> >> for whatever reason context.drawImage draws the ball image at 2x the >> specified height. Any idea why? >> >> i have added the experiments/ folder at the root level. I know that >> clutters the root directory. perhaps there is a better place to put it >> >> > -- > Bryan W. Berry > Technology Director > OLE Nepal, http://www.olenepal.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] installing Surf on 0.82?
I installed all packages containing gnome and python and it worked. I think python-gnome2 did the trick, but I'm not sure. 2009/9/11 Bryan Berry : > I am trying to install Surf on 0.82 > http://dev.laptop.org/~bobbyp/surf/ > > I have to tried to install the dependencies as written in the notes: > > sudo yum install pywebkitgtk WebKit-gtk gnome-python2-gconf > > i have enabled the repos for: > fedora-updates-newkey.repo > fedora-updates.repo > fedora.repo > fedora-updates-testing-newkey.repo > fedora-updates-testing.repo > > and disabled olpc-development.repo > > I am able to install all the dependencies except gnome-python2-gconf > > i get the error > > missing dependency: gnome-python2 > > but when i try to update gnome-python2 yum tells me that it is already > installed, w/ the same version number that yum asked for earlier. > > would appreciate any advice > > -- > Bryan W. Berry > Technology Director > OLE Nepal, http://www.olenepal.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] [Karma] changed jquery.karma.js to use 'name' property instead of ID
Be careful, name is the historical precursor of id and it's valid in XHTML Transitional for the same purpose. 2009/9/12 Bryan Berry : > Felipe, > I changed id property for images, sounds, and surfaces to name instead. > Did this to avoid confusion with an html element's ID attribute. > > I have changed adding_up to reflect this change > > -- > Bryan W. Berry > Technology Director > OLE Nepal, http://www.olenepal.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] gtk.Label expanding/aligning issue
To be more precise, I'd like all the text except the first paragraph to extend to the left and right borders. 2009/9/19 Tomeu Vizoso : > On Fri, Sep 18, 2009 at 23:10, Lucian Branescu > wrote: >> I'm having trouble with making a gtk.Label expand to the whole screen. > > You mean the whole screen or the whole available space? > >> I've tried various combinations of box packing options, label props >> and box props, no success so far. > > AFAICS, you have all the expand=True and fill=True that should be > necessary. From just looking at the code, I would suspect the scrolled > window is having an unexpected effect. > >> My code lives here http://github.com/lucian1900/webquest > > Very clean code, congrats! > >> I've also attached a screenshot with this. > > What's the problem with this, you would like the text to extend also > to the left and right borders? > > Regards, > > Tomeu > > -- > «Sugar Labs is anyone who participates in improving and using Sugar. > What Sugar Labs does is determined by the participants.» - David > Farning > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Not connecting to a WAP+Wireless cracking
About the cracking, I don't know why it wouldn't work on an XO, but rest assured that WEP is crackable in under 1 hour by a determined individual, with minimal experience. WPA is also potentially crackable, but harder. WPA2 is too hard to try with nowadays hardware. 2009/10/8 Abhishek Indoria : > Hey all, > Sorry to bother you:) But I have a problem here, actually, two problems. > > First one, I ain't been able to connect to the Access Points using my > XO's, be is 100%signals or 50%. I click the WAP circle, it blinks for > a minute and...nothing happens. Can anyone please tell me why? > > Second one, I recently set up an Access Point in my school, and My IT > teacher wants me to test the protection, they know I am quite good in > it;-) However, It asks for a password, as it is a protected network. > Now, I have used Aircrack-ng package. First thing, I don't get enough > IVs for it. I have been trying 2 hours(nearly daily) for last 10 days, > and I have only got 8000 IVs. Anyway, its a WEP protection. Any > suggestions up here? how can I increase the packet/IV gather rate? How > can I crack it? It would be better if I won't be able to crack it, > because teachers want me to prove it. And, I want to make holes in > it;-) > > Thanks:) > > -Abhishek > > P.S.-I have tried the OLPC page on wireless crackingI just can't > get enough IVs. Any decent manual or suggestions would do:) > -- > Abhishek Indoria > OLPC Support Volunteer > http://support.laptop.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] [Karma] questions about jquery.karma.js
There's one point I want to nitpick on, you can make karma usable with any
library even if it uses jquery internally. Jquery is especially well suited
for this since it the least invasive (it even injects just one object).
On 4 Nov 2009 05:04, "Bryan Berry" wrote:
I am refactoring jquery.karma.js using test-driven development.
I think you did a great job in writing it in the first place, but I am
far to lazy to manually test out the entire library every time I make a
change.
Reading through jquery.karma.js, I have some questions:
--- the init function ---
You have an init function that receives the assets to be loaded as an
argument but actually loading them happens in the first part of the if
statement of karma.main . To me it would make more sense to just pass
the assets as an argument to karma.main({ /* assets object */}) and not
the function call back as currently.
Ideally I would like the use of Karma in lesson.js to be as simple as
var k = Karma({ images: [ .], sounds : [...], surfaces : []})
// the rest of the code for a lesson
I don't understand the if statement in karma.main. It seems to me that
the callback to main function would never be called. That the first if
clause will always be true and karma.main() won't be called a second
time.
--- taking out the jquery inside Karma ---
I like how we have packaged karma as a jquery library because it gives
us a standard pattern to follow. That said, I don't want to use jquery
internally to the library so dojo or prototype fans can use it freely
--- to prototype or not to prototype?
I intend to use monkey-patch the Object object with the function create
so Object.prototype.create = function ...
this create function will be implemented in Ecmascript 5 and it matches
Crockford's object(o) function for prototypal inheritance. This is my
excuse for monkey patching ;)
-- KButton
What is the purpose of KButton?
--- mouse.getRelativeCanvasPosition, handleEvents ---
do you have any code that uses these functions so I can see an example
of them in action?
those are the main questions I have for now. Thanks for reading this far
in a long e-mail ;)
I know you are very busy with your exams right now, but do u think we
could chat in the next couple days for about an hour about the structure
of jquery.karma.js?
I am on the east coast of the US right now so timezones are easier :)
--
Bryan W. Berry
Senior Engineer
OLE Nepal, http://www.olenepal.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] Co-hosting my own activities?
That is the correct mimr type. As long as your bundles are zip files with thr .xo extension and that mime type, they should register as activities. On 5 Nov 2009 20:29, "Art Hunkins" wrote: This may well be the problem - with SoaS as well as XO-1 not recognizing downloads of .xo activity bundles from my website. (The "activity download" is not placed in the Activities folder, nor does it appear with its proper icon in the Journal. Download otherwise appears normal.) I think so because, when I was chatting with tech at my server about why .xo bundles could not be found on my site, he asked me what the MIME type was for the bundles; I'd no idea even what MIME types were. I did tell him that .xo bundles were "just like" .zip archives; so he did something that made .xo's findable and downloadable (probably gave them the .zip MIME type). At any rate, I gather I need to tell him the *appropriate* MIME type. Do I understand correctly that it is: application/vnd.olpc-sugar? (There was an extensive listserv discussion of the topic last year.) Do I also gather correctly that no changes to my activities are needed? (I assume not.) I'm looking forward to this co-host option. Art Hunkins > > - Original Message - > From: Lucian Branescu > To: Aleksey Lim > Cc: Art Hunkins ; suga... >> >> On 5 Nov 2009 17:55, "Aleksey Lim" wrote: >> >> On Wed, Nov 04, 2009... -- ___ 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] OOM conditions
Slightly off-topic, has anyone tried compcache (http://code.google.com/p/compcache/) on an XO-1? I might if I can get it to work. 2009/11/8 Tomeu Vizoso : > On Sat, Nov 7, 2009 at 12:06, Martin Dengler wrote: >> On Fri, Nov 06, 2009 at 04:50:53PM +, Tomeu Vizoso wrote: >>> On Wed, Nov 4, 2009 at 14:16, Martin Dengler >>> wrote: >>> > On Fri, Oct 30, 2009 at 11:22:13PM +0100, Tomeu Vizoso wrote: >>> >> On Fri, Oct 30, 2009 at 16:58, Richard A. Smith >>> >> wrote: >>> >> > Working the table at the Boston book festival I was reminded how >>> >> > painful the OOM stuff is on a gen 1. The demo machines were in >>> >> > this state a lot as each visitor would open up a new >>> >> > program. Basically you have to just turn the unit off and restart >>> >> > as trying to recover is futile. >>> >> >>> >> What if activities had a higher oom_score? Would that protect enough >>> >> the processes that once killed require a system restart (X, shell, >>> >> etc)? >>> > >>> > See patch vs sugar-toolkit HEAD below[1] (I can backport to 0.82 if >>> > wanted). >>> >>> Maybe would be better to have the shell do that? So it works for >>> non-python activities. >> >> Patch inline below. > > Looks great, thanks a lot. Have you seen less memory-induced lockups > on the XO-1? > > Regards, > > Tomeu > >>> >> Regards, >>> >> >>> >> Tomeu >>> > >>> > Martin >>> > >>> Thanks, >>> >>> Tomeu >> >> Martin >> >> >> (untested) patch against >> http://cgit.sugarlabs.org/sugar-toolkit/mainline/tree/src/sugar/activity/activityfactory.py >> : >> >> From 4bd6fb9f7f245c2aed92d6964746627d0c96cbec Mon Sep 17 00:00:00 2001 >> From: Martin Dengler >> Date: Sat, 7 Nov 2009 10:55:16 + >> Subject: [PATCH] sacrifice activities to the OOM killer first >> >> change the OOM-killer score of launched activities to be the maximum. >> See discussion at http://linux-mm.org/OOM_Killer >> --- >> src/sugar/activity/activityfactory.py | 35 >> + >> 1 files changed, 35 insertions(+), 0 deletions(-) >> >> diff --git a/src/sugar/activity/activityfactory.py >> b/src/sugar/activity/activityfactory.py >> index ee0fd92..5deee6e 100644 >> --- a/src/sugar/activity/activityfactory.py >> +++ b/src/sugar/activity/activityfactory.py >> @@ -65,6 +65,39 @@ def _close_fds(): >> pass >> >> >> +def __oom_adj_pid(pid, omm_adj_value=None): >> + """ Change a process' OOM likelihood to oom_adj_value. >> + >> + By default, use the value of gconf path >> + "/desktop/sugar/performance/oom_adj_default"; if none exists, make >> + this process most likely to be killed (oom_adj_value=15). >> + >> + Linux-specific. See http://linux-mm.org/OOM_Killer for details. >> + """ >> + oom_adj_fullpath = "/proc/%s/oom_adj" % pid >> + if os.path.exists(oom_adj_fullpath): >> + try: >> + >> + # get values/defaults from gconf >> + import gconf >> + gconf_dir = "/desktop/sugar/performance" >> + gconf_key = "oom_adj_default" >> + client = gconf.client_get_default() >> + if not client.dir_exists(gconf_dir): >> + client.add_dir(gconf_dir, gconf.CLIENT_PRELOAD_NONE) >> + if oom_adj_value is None: >> + oom_adj_value = client.get_int(gconf_dir + "/" + gconf_key) >> + if oom_adj_value is None: >> + oom_adj_value = 15 >> + client.set_int(gconf_dir + "/" + gconf_key, >> + oom_adj_value) >> + >> + file(oom_adj_fullpath).write(oom_adj_value) >> + >> + except: >> + pass >> + >> + >> def create_activity_id(): >> """Generate a new, unique ID for this activity""" >> pservice = presenceservice.get_instance() >> @@ -276,6 +309,8 @@ class ActivityCreationHandler(gobject.GObject): >> stdout=log_file.fileno(), >> stderr=log_file.fileno()) >> >> + __oom_adj_pid(child.pid) >> + >> gobject.child_watch_add(child.pid, >> _child_watch_cb, >> (environment_dir, log_file)) >> -- >> 1.6.2.5 >> >> > > > > -- > «Sugar Labs is anyone who participates in improving and using Sugar. > What Sugar Labs does is determined by the participants.» - David > Farning > ___ > 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
[Sugar-devel] Keep offline for Browse (offline bookmarks)
The second point in this ticket http://bugs.sugarlabs.org/ticket/971 I've made a patch against the latest Browse, but trac doesn't let me post it (apparently I'm a bot). Besides being able to save pages for offline use, this patch will also allow distribution of HTML content in .zip files that have an 'index.html' inside. Browse will happily open such files (but they may need certain metadata). Patch attached. keep_offline.patch Description: Binary data ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keep offline for Browse (offline bookmarks)
Forgot the first time, I've looked at a book from that link and it's a .zip file with some html inside, but there's no index.html file. There is a start.html file (which I assume is the entry point), but as it is right now, the user would have to click start.html after the .zip file is loaded. I could add 'start.html' to the list of entry points to look for if it's an important enough use case. 2009/11/9 Caroline Meeks : > This sounds great! I've been trying to get the zip files of books from CAST > to work. Will this patch fix it for me? What is the easiest way for me to > try it? Is there a VM appliance? > Here is a link to the books I'm trying to get to > work: http://bookbuilder.cast.org/model.php > > Thanks! > Caroline > > On Sun, Nov 8, 2009 at 10:17 AM, Lucian Branescu > wrote: >> >> The second point in this ticket http://bugs.sugarlabs.org/ticket/971 >> I've made a patch against the latest Browse, but trac doesn't let me >> post it (apparently I'm a bot). >> >> Besides being able to save pages for offline use, this patch will also >> allow distribution of HTML content in .zip files that have an >> 'index.html' inside. Browse will happily open such files (but they may >> need certain metadata). >> >> Patch attached. >> >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> > > > > -- > Caroline Meeks > Solution Grove > carol...@solutiongrove.com > > 617-500-3488 - Office > 505-213-3268 - Fax > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keep offline for Browse (offline bookmarks)
Sorry for any confusion, the second keep_offline.patch should be applied over the older one. 2009/11/9 Lucian Branescu : > Right now, you'd need to apply the patch to Browse yourself. I've > attached an .xo bundle that should work on sugar 0.86, but I haven't > tested it. > > Right now I add some metadata to the journal object so that it is > opened by Browse by default > (metadata['activity']='org.laptop.WebActivity'). I could however > change it so that Browse opens any .zip file, not just files it > produced itself. > > I've attached a patch that does that (adds the zip mime type in > activity.info). > > 2009/11/9 Caroline Meeks : >> This sounds great! I've been trying to get the zip files of books from CAST >> to work. Will this patch fix it for me? What is the easiest way for me to >> try it? Is there a VM appliance? >> Here is a link to the books I'm trying to get to >> work: http://bookbuilder.cast.org/model.php >> >> Thanks! >> Caroline >> >> On Sun, Nov 8, 2009 at 10:17 AM, Lucian Branescu >> wrote: >>> >>> The second point in this ticket http://bugs.sugarlabs.org/ticket/971 >>> I've made a patch against the latest Browse, but trac doesn't let me >>> post it (apparently I'm a bot). >>> >>> Besides being able to save pages for offline use, this patch will also >>> allow distribution of HTML content in .zip files that have an >>> 'index.html' inside. Browse will happily open such files (but they may >>> need certain metadata). >>> >>> Patch attached. >>> >>> ___ >>> Sugar-devel mailing list >>> Sugar-devel@lists.sugarlabs.org >>> http://lists.sugarlabs.org/listinfo/sugar-devel >>> >> >> >> >> -- >> Caroline Meeks >> Solution Grove >> carol...@solutiongrove.com >> >> 617-500-3488 - Office >> 505-213-3268 - Fax >> > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keep offline for Browse (offline bookmarks)
This patch won't save video, at least not flash video. In fact, it does exactly what Firefox's 'save complete web page' functionality does. It may save video in html5 tags for offline use, but I haven't tested that. If it works with Firefox, it should work with this as well. 2009/11/9 Caroline Meeks : > Sorry, I missed this email when I sent the other one. A use case I'm > working on today is grabbing a video when I'm online, sharing it with > students for them to watch at home when I'm offline. Do I need this patch to > enable this use case also? > > On Mon, Nov 9, 2009 at 11:47 AM, Lucian Branescu > wrote: >> >> Forgot the first time, I've looked at a book from that link and it's a >> .zip file with some html inside, but there's no index.html file. There >> is a start.html file (which I assume is the entry point), but as it is >> right now, the user would have to click start.html after the .zip file >> is loaded. I could add 'start.html' to the list of entry points to >> look for if it's an important enough use case. > > Yes please add support for start.html. There a millions of books available > on the internet, but I think this is one of the few resources that provides > books that would be useful to a dyslectic second grader who reads below > grade level. And Sugar is the only platform who believes that that user is > important use case for eBooks. ;) > Thank you!! > >> >> 2009/11/9 Caroline Meeks : >> > This sounds great! I've been trying to get the zip files of books from >> > CAST >> > to work. Will this patch fix it for me? What is the easiest way for me >> > to >> > try it? Is there a VM appliance? >> > Here is a link to the books I'm trying to get to >> > work: http://bookbuilder.cast.org/model.php >> > >> > Thanks! >> > Caroline >> > >> > On Sun, Nov 8, 2009 at 10:17 AM, Lucian Branescu >> > >> > wrote: >> >> >> >> The second point in this ticket http://bugs.sugarlabs.org/ticket/971 >> >> I've made a patch against the latest Browse, but trac doesn't let me >> >> post it (apparently I'm a bot). >> >> >> >> Besides being able to save pages for offline use, this patch will also >> >> allow distribution of HTML content in .zip files that have an >> >> 'index.html' inside. Browse will happily open such files (but they may >> >> need certain metadata). >> >> >> >> Patch attached. >> >> >> >> ___ >> >> Sugar-devel mailing list >> >> Sugar-devel@lists.sugarlabs.org >> >> http://lists.sugarlabs.org/listinfo/sugar-devel >> >> >> > >> > >> > >> > -- >> > Caroline Meeks >> > Solution Grove >> > carol...@solutiongrove.com >> > >> > 617-500-3488 - Office >> > 505-213-3268 - Fax >> > > > > > -- > Caroline Meeks > Solution Grove > carol...@solutiongrove.com > > 617-500-3488 - Office > 505-213-3268 - Fax > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keep offline for Browse (offline bookmarks)
For youtube alone, I recommend one of the Youtube download scripts/extensions. There's even some userscripts and bookmarklets out there (both features I would like to add to Browse at some point). This particular patch is very much geared towards taking pure html content offline, content from plugins (such as Flash player or Java applets) may or may not work with this, depending on the website. 2009/11/10 Caroline Meeks : > > > On Mon, Nov 9, 2009 at 5:16 PM, Lucian Branescu > wrote: >> >> This patch won't save video, at least not flash video. In fact, it >> does exactly what Firefox's 'save complete web page' functionality >> does. >> >> It may save video in html5 tags for offline use, but I haven't >> tested that. If it works with Firefox, it should work with this as >> well. > > It does seem to work in firefox. For my use case we'll need to be able > share a page that some (the teacher) has saved. > Here is the scenario in a school in the US. > The school district blocks YouTube for example in schools. > But YouTube has many valuable clips. > The teacher goes to YouTube at home and pics an educational clip. (e.g. > Schoolhouse rock) and saves it. > The teacher shares/sends the browse/bookmark (terminology unclear to me) > Students can then watch the clip at home where they do not have any internet > Thanks! > Caroline >> >> 2009/11/9 Caroline Meeks : >> > Sorry, I missed this email when I sent the other one. A use case I'm >> > working on today is grabbing a video when I'm online, sharing it with >> > students for them to watch at home when I'm offline. Do I need this >> > patch to >> > enable this use case also? >> > >> > On Mon, Nov 9, 2009 at 11:47 AM, Lucian Branescu >> > >> > wrote: >> >> >> >> Forgot the first time, I've looked at a book from that link and it's a >> >> .zip file with some html inside, but there's no index.html file. There >> >> is a start.html file (which I assume is the entry point), but as it is >> >> right now, the user would have to click start.html after the .zip file >> >> is loaded. I could add 'start.html' to the list of entry points to >> >> look for if it's an important enough use case. >> > >> > Yes please add support for start.html. There a millions of books >> > available >> > on the internet, but I think this is one of the few resources that >> > provides >> > books that would be useful to a dyslectic second grader who reads below >> > grade level. And Sugar is the only platform who believes that that user >> > is >> > important use case for eBooks. ;) >> > Thank you!! >> > >> >> >> >> 2009/11/9 Caroline Meeks : >> >> > This sounds great! I've been trying to get the zip files of books >> >> > from >> >> > CAST >> >> > to work. Will this patch fix it for me? What is the easiest way for >> >> > me >> >> > to >> >> > try it? Is there a VM appliance? >> >> > Here is a link to the books I'm trying to get to >> >> > work: http://bookbuilder.cast.org/model.php >> >> > >> >> > Thanks! >> >> > Caroline >> >> > >> >> > On Sun, Nov 8, 2009 at 10:17 AM, Lucian Branescu >> >> > >> >> > wrote: >> >> >> >> >> >> The second point in this ticket http://bugs.sugarlabs.org/ticket/971 >> >> >> I've made a patch against the latest Browse, but trac doesn't let me >> >> >> post it (apparently I'm a bot). >> >> >> >> >> >> Besides being able to save pages for offline use, this patch will >> >> >> also >> >> >> allow distribution of HTML content in .zip files that have an >> >> >> 'index.html' inside. Browse will happily open such files (but they >> >> >> may >> >> >> need certain metadata). >> >> >> >> >> >> Patch attached. >> >> >> >> >> >> ___ >> >> >> Sugar-devel mailing list >> >> >> Sugar-devel@lists.sugarlabs.org >> >> >> http://lists.sugarlabs.org/listinfo/sugar-devel >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Caroline Meeks >> >> > Solution Grove >> >> > carol...@solutiongrove.com >> >> > >> >> > 617-500-3488 - Office >> >> > 505-213-3268 - Fax >> >> > >> > >> > >> > >> > -- >> > Caroline Meeks >> > Solution Grove >> > carol...@solutiongrove.com >> > >> > 617-500-3488 - Office >> > 505-213-3268 - Fax >> > > > > > -- > Caroline Meeks > Solution Grove > carol...@solutiongrove.com > > 617-500-3488 - Office > 505-213-3268 - Fax > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keep offline for Browse (offline bookmarks)
I've tried jar:, but there were numerous issues with navigating to other pages. Also, it was quite hard to get Browse to actually open that URI, it kept trying to prettify it. On top of that, jar: has been deprecated because of security issues. After investigating jar: I found out that it actually unzips things in temporary storage anyway. So I could easily replace jar: with two lines of code and not bother with its problems. The only thing my code doesn't do that jar: does is very prompt cleanup. 2009/11/10 S Page : > On Sun, Nov 8, 2009 at 7:17 AM, Lucian Branescu >> Besides being able to save pages for offline use, this patch will also >> allow distribution of HTML content in .zip files that have an >> 'index.html' inside. Browse will happily open such files (but they may >> need certain metadata). > > Why not browse the .zip files using the jar: protocol wrapper instead > of unzipping them to temporary storage? When handling a zip file, you > should be able to just wrap it with > jar:file:///path/to/zip!/index.html and hand this to the browser. In > the mailing list thread "directly browsing compressed content in the > datastore" Benjamin Schwartz mentioned > >> Lucian experimented with jar: for browsing >> offline webpages, but ultimately rejected it after determining that >> webpages using javascript would not function properly. > > Such pages worked for me, what problems did you encounter? > > BTW, since .xol files are ZIP files, your patch and/or the jar: > protocol means Sugar users could view web content bundles without > having to unpack them, allowing the distribution of really large > content bundles. I filed http://dev.sugarlabs.org/ticket/1258 I > think this is a sugar-toolkit change, but Tomeu categorized it as a > Browse bug. > > Cheers, > -- > =S Page > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keep offline for Browse (offline bookmarks)
I've actually implemented the full-blown web app part (it's called Site Specific Browser) for Browse as part of GSoC. The offline bit can be done either with LocalStorage (html5, but it's been around since Firefox 2.0) or Gears. So new offline-able web apps can target html5, existing web apps already use Gears (which needs more work for Browse). The other features are more invasive so I'm trying to make individual patches for each of them. This is the first one because it's the most useful on its own and it's been requested for a long time. 2009/11/10 Martin Langhoff : > On Sun, Nov 8, 2009 at 4:17 PM, Lucian Branescu > wrote: >> Besides being able to save pages for offline use, this patch will also > > Question on this track (perhaps OT)... do the "HTML5" specs have > something in this regard? > > IIRC (from an in-depth reading done 3 months ago) the "offline" > extensions have a simple facility (that looks a lot like what you're > working on) as well as the full blown show of offline webapps that > Gmail uses. > > If it's done in an HTML5 compatible way, love will spread and ponies > will prance in the prairies... Browse.xo users will be able to take > advantage of any website that DTRT, and any Moodle enhancements I make > to support this will be mergeable upstream... > > :-) > > > > 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-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keep offline for Browse (offline bookmarks)
There's no UI for this, the developer of the web app must support this themselves. GMail for example already does it. The user can create a SSB for GMail, which will appear as a separate activity and can have its own userscripts and whatnot. Also, userscripts could be used to adapt website for offline use (something like http://code.google.com/apis/gears/articles/gearsmonkey.html). Right now, developers can use Gears and follow its documentation or DOM storage (https://developer.mozilla.org/en/DOM/Storage). The Karma documentation could be of help as well. You can read more on my blog (http://honeyweb.wordpress.com/) or the wiki page (http://wiki.sugarlabs.org/Webified). 2009/11/10 Martin Langhoff : > On Tue, Nov 10, 2009 at 1:36 PM, Lucian Branescu > wrote: >> I've actually implemented the full-blown web app part (it's called >> Site Specific Browser) for Browse as part of GSoC. > > Great! So it should be easy to "store for offline" small bits of > static content? Is there any UI needed / present for this? > > Any "how to author static / simple offline content for HTML5" guide we > can recommend? > > cheers. > > > > 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-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Big binaries via dbus & logged in shell.log?
There's a GMail labs feature that allows you do undo in the first 30secs after sending. Very useful. 2009/11/10 Martin Langhoff : > On Tue, Nov 10, 2009 at 3:17 PM, Martin Langhoff > wrote: >> On Sugar 0.84.2 (as seen on the OLPC F11 builds)... is it normal to >> see big chunks of binary data passed around via dbus... and logged in >> shell.log? > > Scrap that. The stuff I am seeing is the data related to the bug I am chasing. > > Where's the "unsend silly email" button on this internet thing? > > > 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-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] [Karma] changing karma.run( callback) to karma.ready( callback )
You could take it even further and do karma.ready = callback or karma.onReady = callback. 2009/11/10 Bryan Berry : > hey guys, > > lucian tks for the great suggestion of karma.run() instead karma.main(). > But thinking further I think that karma.ready ( callback ) would be even > more intuitive > > > -- > Bryan W. Berry > Senior Engineer > OLE Nepal, http://www.olenepal.org > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Rationale behind the JSON -> CJSON switch in Sugar codebase?
The json module (simplejson) has only the parser written in C, so it's
still slower overall than cjson. Not by a lot, but measurable.
2009/11/12 Martin Langhoff :
> On Thu, Nov 12, 2009 at 4:59 PM, Martin Langhoff
> wrote:
>> Then maybe yes, I am seeing a bug in cjson that parses 'foo\/bar'
>> incorrectly.
>
> Confirmed. In a python session:
>
json.loads('"foo\/bar"')
> u'foo/bar' <== correct
cjson.decode('"foo\/bar"')
> 'foo\\/bar' <== incorrect
>
>
>
> 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-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] Rationale behind the JSON -> CJSON switch in Sugar codebase?
I did a quick and not-so-scientific benchmark. The test involves a round trip for a small json file 10 times. cjson7.56759595871 simplejson-c 9.09944200516 simplejson-pure 58.1605060101 2009/11/13 Daniel Drake : > On Fri, 2009-11-13 at 10:53 +0100, Martin Langhoff wrote: >> After a few tries, I did find that the same problem was reported in >> Debian, a patch proposed, and upstream rejected it: >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534709 >> >> As Tomeu mentions, Python 2.6 reduces the cjson/json performance advantage. > > OK, didn't see this. Yes, using python standard library seems like the > way to go. > > Daniel > > > ___ > 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] [karma] when does an audio element created w/ new Audio() emit the onload event?
The codec might be the issue. Afaik chromium has no codecs. Try
Chrome, although I'm not sure it has vorbis either.
2009/11/18 Bryan Berry :
> I was just playing around w/ it and I found the media.load() method
>
> loading audio remotely still doesn't work on chromium -- argh but works
> fine on FF 3.5. I need to go complain about that.
>
> http://karma-testing.sugarlabs.org/tests/index.html
>
> I add to put this code here
> http://git.sugarlabs.org/projects/karma/repos/mainline/blobs/jkjs-refactor/js/karma.js#line324
>
> after I added the event handlers
>
> if (this._type === "sound"){
> this.media.load();
> }
>
>
>
> On Wed, 2009-11-18 at 14:21 -0600, Felipe López Toledo wrote:
>> hi man
>>
>>
>> It doesn't emit that event at the same time that a new Image()
>> does. I
>> need a way to throw an error to the user if the audio file
>> isn't
>> accessible. I do this for the images and it works quite well.
>> I have used "load" and "error" and others events for new Image and new
>> Audio and it seems that work fine, could you explain the event that
>> you want to catch?
>>
>>
>> I think audio.addEventListener("error", function(e) {}, false );
>> will do the work.
>>
>>
>> btw. here is the list of events for media elements, section 4.8.10.12:
>> http://dev.w3.org/html5/spec/Overview.html
>>
>>
>> greetings!
>>
>> 2009/11/18 Bryan Berry
>> Hey subzero,
>>
>> Do you know when does an audio element created w/ new Audio()
>> emit the
>> onload event?
>>
>> It doesn't emit that event at the same time that a new Image()
>> does. I
>> need a way to throw an error to the user if the audio file
>> isn't
>> accessible. I do this for the images and it works quite well.
>>
>> I also need to this for svgs but haven't figured out the
>> mechanism
>>
>> --
>> Bryan W. Berry
>> Senior Engineer
>> OLE Nepal, http://www.olenepal.org
>>
>>
>>
>>
>> --
>> Felipe López Toledo
>>
> --
> Bryan W. Berry
> Senior Engineer
> OLE Nepal, http://www.olenepal.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] [karma] when does an audio element created w/ new Audio() emit the onload event?
Oh, sorry about that then.
2009/11/18 Bryan Berry :
> it works when the ogg files are local just not when they are remote. It
> is a known bug in chromium
> On Wed, 2009-11-18 at 22:20 +0000, Lucian Branescu wrote:
>> The codec might be the issue. Afaik chromium has no codecs. Try
>> Chrome, although I'm not sure it has vorbis either.
>>
>> 2009/11/18 Bryan Berry :
>> > I was just playing around w/ it and I found the media.load() method
>> >
>> > loading audio remotely still doesn't work on chromium -- argh but works
>> > fine on FF 3.5. I need to go complain about that.
>> >
>> > http://karma-testing.sugarlabs.org/tests/index.html
>> >
>> > I add to put this code here
>> > http://git.sugarlabs.org/projects/karma/repos/mainline/blobs/jkjs-refactor/js/karma.js#line324
>> >
>> > after I added the event handlers
>> >
>> > if (this._type === "sound"){
>> > this.media.load();
>> > }
>> >
>> >
>> >
>> > On Wed, 2009-11-18 at 14:21 -0600, Felipe López Toledo wrote:
>> >> hi man
>> >>
>> >>
>> >> It doesn't emit that event at the same time that a new Image()
>> >> does. I
>> >> need a way to throw an error to the user if the audio file
>> >> isn't
>> >> accessible. I do this for the images and it works quite well.
>> >> I have used "load" and "error" and others events for new Image and new
>> >> Audio and it seems that work fine, could you explain the event that
>> >> you want to catch?
>> >>
>> >>
>> >> I think audio.addEventListener("error", function(e) {}, false );
>> >> will do the work.
>> >>
>> >>
>> >> btw. here is the list of events for media elements, section 4.8.10.12:
>> >> http://dev.w3.org/html5/spec/Overview.html
>> >>
>> >>
>> >> greetings!
>> >>
>> >> 2009/11/18 Bryan Berry
>> >> Hey subzero,
>> >>
>> >> Do you know when does an audio element created w/ new Audio()
>> >> emit the
>> >> onload event?
>> >>
>> >> It doesn't emit that event at the same time that a new Image()
>> >> does. I
>> >> need a way to throw an error to the user if the audio file
>> >> isn't
>> >> accessible. I do this for the images and it works quite well.
>> >>
>> >> I also need to this for svgs but haven't figured out the
>> >> mechanism
>> >>
>> >> --
>> >> Bryan W. Berry
>> >> Senior Engineer
>> >> OLE Nepal, http://www.olenepal.org
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Felipe López Toledo
>> >>
>> > --
>> > Bryan W. Berry
>> > Senior Engineer
>> > OLE Nepal, http://www.olenepal.org
>> >
>> > ___
>> > Sugar-devel mailing list
>> > Sugar-devel@lists.sugarlabs.org
>> > http://lists.sugarlabs.org/listinfo/sugar-devel
>> >
> --
> Bryan W. Berry
> Senior Engineer
> OLE Nepal, http://www.olenepal.org
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 3g dependencies
It's a bad idea to do it for any bit in the networking stack. If your only internet connection is over pptp, how can NM download and install the pptp bits? I've personally had loads of trouble with this. Same for 3g. I think they should be dependencies. On 8 March 2010 15:32, Martin Langhoff wrote: > On Mon, Mar 8, 2010 at 10:26 AM, Tomeu Vizoso wrote: >> which new dependencies we need to advertise in Sugar because of the >> work in 3g devices? > > Do they need to be dependencies (from a packaging PoV)? Always better > to discover if the needed component is there at startup/runtime and > offer the extra functionality... if possible... NM already does this > for a number of components (ppptp, etc). > > cheers, > > > 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-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
[Sugar-devel] [GSoC] Sugar Browser
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. 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. 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. 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. 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? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC] Sugar Browser
On 22 March 2010 00:12, Benjamin M. Schwartz wrote: > Lucian Branescu wrote: > > 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. > > I'm not willing to accept this as proven. As for faster, see > http://weblogs.mozillazine.org/bz/archives/020434.html > > As for memory usage, see > http://dotnetperls.com/chrome-memory Of course Chrome usage is much higher. Chrome has at least one process for each tab. Safari is also a wreck, especially on Windows. > > > Webkit may be faster (although... with which javascript engine? on what > graphics hardware? with which bookmarks/awesomebar system?) but I don't > think it's so obvious. Previous comparisons on the XO have been deeply > flawed because Gecko was scaling up all fonts and images, while Webkit was > not. The test I have done both on OS X and soas have shown webkit to be far superior in execution speed and still superior in memory usage for benchmarks. These weren't entirely relevant, so I will do another set of benchmarks that are more relevant to XO usage (with firefox 3.6). Here are my old results: http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20osx.txt http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20soas.txt http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20winxp.txt > > > 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. > > This sounds like an argument for staying with Gecko and adopting > Greasemonkey and Jetpack. > It's an argument for not really needing Gecko. Both could be implemented on Webkit. > > > Second, webkit is being used by a lot of projects and has the backing of > > several companies. > > Gecko is far more widely deployed (~30% of all internet users). > The arguments other people have given to me have to do with how many projects use it (maintained by many companies/communities). > > > Furthermore, it is packaged more consistently across > > platforms/distributions. > > I'm not sure what this means, but it doesn't seem critical. > Xulrunner tends to have many patches applied by distros. Webkit doesn't. > > > 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 certainly not going to complain about an abstraction layer of this > sort. As I've said before, I think a lot of developers would enjoy an > "engine-agnostic" browser widget. > > --Ben > > ___ 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 wrote: > On Sun, Mar 21, 2010 at 23:25, Lucian Branescu > 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] Who maintains Hulahop?!?
I have applied to GSoC with this http://wiki.sugarlabs.org/go/Summer_of_Code/2010/AbstractBrowser. In short, it's a project to make Browse (mostly) engine-independent. On 16 April 2010 17:30, Jonas Smedegaard wrote: > Hi again, > > On Wed, Apr 07, 2010 at 07:19:58PM +0200, Tomeu Vizoso wrote: >> >> On Tue, Apr 6, 2010 at 22:41, Jonas Smedegaard wrote: > >>> I am wondering: Who maintains Hulahop? > >> It's unmaintained as per >> http://wiki.sugarlabs.org/go/Development_Team/Release/Modules#hulahop >> :( >> >> I can find time to discuss and review any fixes. >> >> Thanks for caring about this, > > ...and soon after this thread died out again :-( > > With noone in Sugarlabs maintaining the code, and incapable myself to > maintain it, I now strongly consider dropping Browse from Debian! > > This is a cry for help: It really really feels weird with such a central > piece of the Sugar environment being dead code. > > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQIcBAEBCgAGBQJLyJCsAAoJECx8MUbBoAEhXTsP/R5cKLsBy6XEUOEllzHJrgKy > q7+nqUKfHY7M9wDmbVuX0rNDLFB45X17Af2yGA0cb7wS/mtDyUe4ofa6iyFVcdJR > pZFK3KzjYUUikicwW75iPCrSnJeYBRO7j+f9Bhmp8suNy/uu6g/DOCFZtCbAsoV4 > U2uIOTXWN4fRgL8z3ibkzQ89tTkpc6MYJfGfuhG5oitJ+XOm9GSrHBkjN9Gm0X+9 > cDSrtvWLTNGbN4bb7Dq9RD1mPdXZ4HQ0ifHrOQfQzkFciYyLUxSH8riOz+1ueiA9 > Idbb7HLqFrNrVbLT9qSWxB6fpdUuawf+uy+EnXraKKG4FzUZAtGCyzsBw9UPXNWA > auBC7o83Oa5wMHSyd/kkB/nQnfQGASGIz1Gg2p5e+v7lSnMRzDWNkvWM/WoXsrNw > l1L66lLpFEJkaBbAO44k8bwZZLBQsQurL56uOz9qmMaWpzDr9q3kLfADRCofLw+Q > Kj4a027l5TjmRMC1vi1DHolKDsD/KAsJKcFya37LMLcNUPaKPpC7N8p5iVZ7gAkw > OWMO53X2huDZKnyRlrqtLDJz8h9G/0pTrtqtxgyeovZZcKE8w4X9PEx2ZGY1fChV > BpzkHVw77+gH4ax1A1wFJdddRNGZvi/Dtv8vrW+F+tf0Nj+YRBp9B6kWaGS/yBrI > r0Bt2PzsTmD65+6Iqn/D > =vdJO > -END PGP SIGNATURE- > > ___ > 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] Who maintains Hulahop?!?
Unfortunately, I'm quite busy now with a school project and work, and I have to revise for exams. If I find time, I'll have a look at that. On 17 April 2010 11:48, Jonas Smedegaard wrote: > On Fri, Apr 16, 2010 at 09:08:34PM +0100, Lucian Branescu wrote: >> >> I have applied to GSoC with this >> http://wiki.sugarlabs.org/go/Summer_of_Code/2010/AbstractBrowser. >> >> In short, it's a project to make Browse (mostly) engine-independent. > > Wauw, that seems quite interesting, long term. > > Could you perhaps be convinced to have a go at looking into this specific > problem that I have raised, and the related cleanup of the use of Xulrunner > which Mike have suggested? Now, before GSoC? > > > Kind regards, and good luck with your related project! > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQIcBAEBCgAGBQJLyZIPAAoJECx8MUbBoAEhx78QAJfu8x4lx9d78APQWZb/Inw0 > n1jSEYbLgqp4F/NykTto88+tNrO3BCrt8lTaCF0uPSaIFK5zkAnCdTRp9RFug3DA > RkU8m0ksDMQehWNGamHkhw+0xLHevjEIXc12dkeXr/gsFVWVU1798inmMkTKO4av > SPc+ZHV+FrpIpqjw5cpDz5nrcEn/TWel/4yXJQ4OUrQ0TGtRxO7s4rPR77p2yqjy > 97GwYXdc3YJN/K9Au4BfVKtxNJvCzf16EwEJmJn2k9dU24brRzPcEE/OoqWRj2R1 > WhWzaMJ/CtmeX3+t8e1lyaUlbcpbbCemseKo7zSMHL0oEvpo1HlzAYphKaKCdW1V > n7mUaniGlBy3ZdHj4oRkgIuNh/Ox4mR5wX5dHTdgU/DLgqk1MzDeyMQJGo8vITK6 > AOsjuXBsJyswkWELQZqjy4Bh5cBZlMe8Y8ya6aPOSETXP6FW+o714fFUCfPuHgRi > a0KH/VTJDwumjSzndjXndyLPVUan3nQLGQap1PC2vTgcZABREpolElIZ/otSQNmM > GF+Xp9DW7NGu6/F25Ht9egF2vneu+cLmKZrur6oOb1rKeWw8HE5Scu/lVRVG91Dx > 9zHK7m/e5BsK/iZupp/3uBVFWuxAdc7YIuvVK4El5iu3KY7iCwWl7mYqVE1I4u5y > 0quOC1+9BW31Ic8RKuWF > =mV9s > -END PGP SIGNATURE- > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Support for EPUB with Read in sugar-jhbuild?
My GSoC project involves building an abstraction layer above pywebkitgtk/hulahop (wiki/AbstractBrowser). While the project itself isn't related, but this abstraction layer and one of it's lower layers (i.e. pywebkitgtk) could become part of the sugar toolkit. On 25 April 2010 17:56, Sayamindu Dasgupta wrote: > Hi, > > On Sun, Apr 25, 2010 at 8:51 AM, James Simmons wrote: >> I'm doing another FLOSS Manual on e-books and Sugar and one of the >> things I'd like to do is get some screen shots of the Read Activity >> reading an EPUB e-book. I modified Get Internet Archive Books to >> download EPUBs and that seems to work OK, but when I try to launch >> Read on one of them it fails to start and complains of a missing >> adapter. As I remember it, EPUB support depended on something called >> webkit, something like that, that was an alternative to gecko. There >> was some discussion here on whether we should support both that and >> gecko. So I have two questions: >> >> 1). How do I get Read as delivered by sugar-jhbuld to work with EPUBs? >> >> 2). Does Read support EPUBs on SoaS right now? If not, what are our >> future plans regarding EPUB support? >> > > Read should be able to render EPUB files if pywebkitgtk is installed. > 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 > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Support for EPUB with Read in sugar-jhbuild?
My GSoC project involves building an abstraction layer above pywebkitgtk/hulahop (wiki/AbstractBrowser). While the project itself isn't related, this abstraction layer and one of it's lower layers (i.e. pywebkitgtk) would become a dependency of the sugar toolkit. On 25 April 2010 17:56, Sayamindu Dasgupta wrote: > Hi, > > On Sun, Apr 25, 2010 at 8:51 AM, James Simmons wrote: >> I'm doing another FLOSS Manual on e-books and Sugar and one of the >> things I'd like to do is get some screen shots of the Read Activity >> reading an EPUB e-book. I modified Get Internet Archive Books to >> download EPUBs and that seems to work OK, but when I try to launch >> Read on one of them it fails to start and complains of a missing >> adapter. As I remember it, EPUB support depended on something called >> webkit, something like that, that was an alternative to gecko. There >> was some discussion here on whether we should support both that and >> gecko. So I have two questions: >> >> 1). How do I get Read as delivered by sugar-jhbuld to work with EPUBs? >> >> 2). Does Read support EPUBs on SoaS right now? If not, what are our >> future plans regarding EPUB support? >> > > Read should be able to render EPUB files if pywebkitgtk is installed. > 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 > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Did someone say Webkit?
There already is a mostly complete pywebkitgtk activity, Surf. There has been a lot of debate on whether webkit is better than gecko for our purposes. I also plan to only support what is reasonably easy to support and let the abstraction layer be leaky. This way, the new Browse can much more easily be ported to another web engine if needed. In fact, as the abstraction layer grows more complete, Browse can be 'ported' to the rest of the abstraction layer (as opposed to AbstractBrowser+hulahop events which would be the first step). On 26 April 2010 03:20, Bernie Innocenti wrote: > On Sun, 2010-04-25 at 18:07 +0100, Lucian Branescu wrote: >> My GSoC project involves building an abstraction layer above >> pywebkitgtk/hulahop (wiki/AbstractBrowser). >> >> While the project itself isn't related, this abstraction layer and one >> of it's lower layers (i.e. pywebkitgtk) would become a dependency of >> the sugar toolkit. > > Very interesting. Would your work make it possible to switch the Browse > activity from XPCOM to Webkit? > > If there were no loss of features, would it be easier for you to switch > the Browse activty from hulahop to pywebkitgtk without developing an > abstraction framework for both? > > -- > // 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] Did someone say Webkit?
This is part of why I think having an abstraction layer is more important than having a complete pywebkitgtk browser activity. It would be even cooler if Read could also use this abstraction layer for epub. On 26 April 2010 21:10, Sayamindu Dasgupta wrote: > On Mon, Apr 26, 2010 at 2:18 PM, Lucian Branescu > wrote: >> There already is a mostly complete pywebkitgtk activity, Surf. >> >> There has been a lot of debate on whether webkit is better than gecko >> for our purposes. I also plan to only support what is reasonably easy >> to support and let the abstraction layer be leaky. >> >> This way, the new Browse can much more easily be ported to another web >> engine if needed. In fact, as the abstraction layer grows more >> complete, Browse can be 'ported' to the rest of the abstraction layer >> (as opposed to AbstractBrowser+hulahop events which would be the first >> step). >> > > Something which concerns me is the relative lack of maintainer > activity for pywebkitgtk. For example, > http://code.google.com/p/pywebkitgtk/issues/detail?id=44 lists an > issue which was reported in December last year, and there has been no > feedback on it (there is a proposed patch as well). The fix for the > issue would help address a few crashers in Read in F-12 and above. > Of course, as we move to gobject-introspection and friends, this > should become less of a concern. > Thanks, > Sayamindu > > > > >> On 26 April 2010 03:20, Bernie Innocenti wrote: >>> On Sun, 2010-04-25 at 18:07 +0100, Lucian Branescu wrote: >>>> My GSoC project involves building an abstraction layer above >>>> pywebkitgtk/hulahop (wiki/AbstractBrowser). >>>> >>>> While the project itself isn't related, this abstraction layer and one >>>> of it's lower layers (i.e. pywebkitgtk) would become a dependency of >>>> the sugar toolkit. >>> >>> Very interesting. Would your work make it possible to switch the Browse >>> activity from XPCOM to Webkit? >>> >>> If there were no loss of features, would it be easier for you to switch >>> the Browse activty from hulahop to pywebkitgtk without developing an >>> abstraction framework for both? >>> >>> -- >>> // Bernie Innocenti - http://codewiz.org/ >>> \X/ Sugar Labs - http://sugarlabs.org/ >>> >>> >> > > > > -- > 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] Did someone say Webkit?
This is part of why I think having an abstraction layer is more important than having a complete pywebkitgtk browser activity. I would be even cooler if Read could also use this abstraction layer for epub. On 26 April 2010 21:10, Sayamindu Dasgupta wrote: > On Mon, Apr 26, 2010 at 2:18 PM, Lucian Branescu > wrote: >> There already is a mostly complete pywebkitgtk activity, Surf. >> >> There has been a lot of debate on whether webkit is better than gecko >> for our purposes. I also plan to only support what is reasonably easy >> to support and let the abstraction layer be leaky. >> >> This way, the new Browse can much more easily be ported to another web >> engine if needed. In fact, as the abstraction layer grows more >> complete, Browse can be 'ported' to the rest of the abstraction layer >> (as opposed to AbstractBrowser+hulahop events which would be the first >> step). >> > > Something which concerns me is the relative lack of maintainer > activity for pywebkitgtk. For example, > http://code.google.com/p/pywebkitgtk/issues/detail?id=44 lists an > issue which was reported in December last year, and there has been no > feedback on it (there is a proposed patch as well). The fix for the > issue would help address a few crashers in Read in F-12 and above. > Of course, as we move to gobject-introspection and friends, this > should become less of a concern. > Thanks, > Sayamindu > > > > >> On 26 April 2010 03:20, Bernie Innocenti wrote: >>> On Sun, 2010-04-25 at 18:07 +0100, Lucian Branescu wrote: >>>> My GSoC project involves building an abstraction layer above >>>> pywebkitgtk/hulahop (wiki/AbstractBrowser). >>>> >>>> While the project itself isn't related, this abstraction layer and one >>>> of it's lower layers (i.e. pywebkitgtk) would become a dependency of >>>> the sugar toolkit. >>> >>> Very interesting. Would your work make it possible to switch the Browse >>> activity from XPCOM to Webkit? >>> >>> If there were no loss of features, would it be easier for you to switch >>> the Browse activty from hulahop to pywebkitgtk without developing an >>> abstraction framework for both? >>> >>> -- >>> // Bernie Innocenti - http://codewiz.org/ >>> \X/ Sugar Labs - http://sugarlabs.org/ >>> >>> >> > > > > -- > 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] Did someone say Webkit?
This is part of why I think having an abstraction layer is more important than having a complete pywebkitgtk browser activity. I would be even cooler if Read could also use this abstraction layer for epub. On 26 April 2010 21:10, Sayamindu Dasgupta wrote: > On Mon, Apr 26, 2010 at 2:18 PM, Lucian Branescu > wrote: >> There already is a mostly complete pywebkitgtk activity, Surf. >> >> There has been a lot of debate on whether webkit is better than gecko >> for our purposes. I also plan to only support what is reasonably easy >> to support and let the abstraction layer be leaky. >> >> This way, the new Browse can much more easily be ported to another web >> engine if needed. In fact, as the abstraction layer grows more >> complete, Browse can be 'ported' to the rest of the abstraction layer >> (as opposed to AbstractBrowser+hulahop events which would be the first >> step). >> > > Something which concerns me is the relative lack of maintainer > activity for pywebkitgtk. For example, > http://code.google.com/p/pywebkitgtk/issues/detail?id=44 lists an > issue which was reported in December last year, and there has been no > feedback on it (there is a proposed patch as well). The fix for the > issue would help address a few crashers in Read in F-12 and above. > Of course, as we move to gobject-introspection and friends, this > should become less of a concern. > Thanks, > Sayamindu > > > > >> On 26 April 2010 03:20, Bernie Innocenti wrote: >>> On Sun, 2010-04-25 at 18:07 +0100, Lucian Branescu wrote: >>>> My GSoC project involves building an abstraction layer above >>>> pywebkitgtk/hulahop (wiki/AbstractBrowser). >>>> >>>> While the project itself isn't related, this abstraction layer and one >>>> of it's lower layers (i.e. pywebkitgtk) would become a dependency of >>>> the sugar toolkit. >>> >>> Very interesting. Would your work make it possible to switch the Browse >>> activity from XPCOM to Webkit? >>> >>> If there were no loss of features, would it be easier for you to switch >>> the Browse activty from hulahop to pywebkitgtk without developing an >>> abstraction framework for both? >>> >>> -- >>> // Bernie Innocenti - http://codewiz.org/ >>> \X/ Sugar Labs - http://sugarlabs.org/ >>> >>> >> > > > > -- > 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] Did someone say Webkit?
I plan to use current hulahop/pywebkitgtk to start out since there's less to figure out. Since it's an abstraction layer, the backends can be switched later. I need a lot of feedback on what the abstraction layer itself needs to do. Afaik, only Browse and Read use browser engines so far. And then again, there may not be enough time write a leakless enough abstraction to be used by anything other than Browse. On 27 April 2010 08:56, C. Scott Ananian wrote: > On Mon, Apr 26, 2010 at 8:38 PM, Bobby Powers wrote: >> I wrote surf a while ago, and it was quite an easy port. In fact, the >> demo browser for pywebkitgtk was (at least at one point) based on >> browse. I did most of the work in a day and a half, but ran into >> problems with both webkit's packaging and the feature-completeness of >> pywebkitgtk (the ability to download files, for example), both of >> which seem to be solved now. >> >> There are also gir bindings for webkit (in webkit's trunk), so it >> might be worth investigating their completeness, especially since >> pywebkitgtk seems to be unmaintained, as Sayamindu pointed out. > > I believe we use the GIR bindings for webkit at litl. So you can > probably consider them well supported. > --scott > > -- > ( http://cscott.net/ ) > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] ideal flash activity to be remade as karma activity
Hello, I have this proposal http://wiki.sugarlabs.org/go/Webified_Toolkit I've had a chat with mchua and homunq on #sugar, and here's an interesting idea "homunq: if you'd need some limited common foundation, but most of your work would then be separate and compatible, you could both schedule the foundation work in the first couple weeks, then say "we will then choose whose version of the foundation to standardize on" We would both need Gears and some sort of javascript-dbus bridge. Gears should be just a plugin and javascript-dbus could be done through this http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge. Then subzero could focus on the 'framework to build sugar activities with web technologies' part and I could focus on the 'getting web apps like gmail running nicely on sugar'. There's also the choice between webkit/titanium and gecko/xulrunner/hulahop. I think it would be better to use xulrunner, since it's already a Sugar dependency. It shouldn't be significantly slower, but we should do some testing anyway. What do you all think? 2009/3/26 Wade Brainerd : > Just to be clear, this is a perfectly normal part of the GSoC application > process. Last year with OLPC I had to choose between like 6 different > Typing Turtle applications, several of which were quite good. And in the > end, none of them was funded by Google. > So, we'll analyze your designs, schedules, resumes, related projects, > potential for future contribution to the project, etc. and choose the best > one to attempt to have funded. > That said, getting a head start on the project and getting involved in the > community are great ways to ensure success. Check > out http://wiki.sugarlabs.org/go/Print_Support for an example of an > applicant who has written test programs, had his ideas evaluated several > times on the mailing list, laid out a fairly clear technical design, etc. > Keep in mind that we have no idea how many students we'll get from Google. > So you are not only competing against those who submit a proposal for the > same idea, you are competing against all the other project ideas as well. > Best, > Wade > > 2009/3/26 Jameson Quinn >> >> Subzero, you have competition. >> >> Lucian, you should check out the mailing list threads for talk between >> Bryan and Felipe; they are talking about much the same ideas you are. >> >> Bryan, you should include Lucian in your forwards. >> >> This is not intended to endorse either Lucian or Subzero. This is one of >> our highest-priority projects for GSoC, and it is even conceivable that we >> could even accept both of your proposals, to be attempted independently. >> Both of you, feel free to take ideas from each other's proposals, but >> remember, we're assuming that you are doing that, and we'd like to see you >> give fair attribution. You're also both welcome to submit a backup proposal >> on another idea, either from the ideas list or of your own invention; it >> seems clear that you are both good applicants, and having a backup proposal >> will help us do you both justice in case you both make the cut. We will not >> let the presence or absence of backup proposals bias us in which one of you >> we choose to do the Karma idea. >> >> Good luck, may the best proposal win! >> >> Jameson >> >> 2009/3/24 Bryan Berry >>> >>> http://hg.olenepal.org/6_Maths_CoOrdinates_22_swf/ >>> >>> Subzero, I think this might be a great flash activity to redo for Karma. >>> Let me know if you have trouble running it on your regular machine. It >>> is in Nepali but I think you will be able to figure it out. I really >>> like how it demonstrates the concepts of coordinates and lets kids play >>> w/ those concepts. >>> >>> You can also download our latest stable monster E-Paath bundle from here >>> (224 MB) >>> >>> http://dev.olenepal.org/E-Paath-2/STABLE/ >>> >>> -- >>> Bryan W. Berry >>> Technology Director >>> OLE Nepal, http://www.olenepal.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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ideal flash activity to be remade as karma activity
Hello, I have this proposal http://wiki.sugarlabs.org/go/Webified_Toolkit I've had a chat with mchua and homunq on #sugar, and here's an interesting idea "homunq: if you'd need some limited common foundation, but most of your work would then be separate and compatible, you could both schedule the foundation work in the first couple weeks, then say "we will then choose whose version of the foundation to standardize on" We would both need Gears and some sort of javascript-dbus bridge. Gears should be just a plugin and javascript-dbus could be done through this http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge. Then subzero could focus on the 'framework to build sugar activities with web technologies' part and I could focus on the 'getting web apps like gmail running nicely on sugar'. There's also the choice between webkit/titanium and gecko/xulrunner/hulahop. I think it would be better to use xulrunner, since it's already a Sugar dependency. It shouldn't be significantly slower, but we should do some testing anyway. What do you all think? 2009/3/26 Wade Brainerd : > Just to be clear, this is a perfectly normal part of the GSoC application > process. Last year with OLPC I had to choose between like 6 different > Typing Turtle applications, several of which were quite good. And in the > end, none of them was funded by Google. > So, we'll analyze your designs, schedules, resumes, related projects, > potential for future contribution to the project, etc. and choose the best > one to attempt to have funded. > That said, getting a head start on the project and getting involved in the > community are great ways to ensure success. Check > out http://wiki.sugarlabs.org/go/Print_Support for an example of an > applicant who has written test programs, had his ideas evaluated several > times on the mailing list, laid out a fairly clear technical design, etc. > Keep in mind that we have no idea how many students we'll get from Google. > So you are not only competing against those who submit a proposal for the > same idea, you are competing against all the other project ideas as well. > Best, > Wade > > 2009/3/26 Jameson Quinn >> >> Subzero, you have competition. >> >> Lucian, you should check out the mailing list threads for talk between >> Bryan and Felipe; they are talking about much the same ideas you are. >> >> Bryan, you should include Lucian in your forwards. >> >> This is not intended to endorse either Lucian or Subzero. This is one of >> our highest-priority projects for GSoC, and it is even conceivable that we >> could even accept both of your proposals, to be attempted independently. >> Both of you, feel free to take ideas from each other's proposals, but >> remember, we're assuming that you are doing that, and we'd like to see you >> give fair attribution. You're also both welcome to submit a backup proposal >> on another idea, either from the ideas list or of your own invention; it >> seems clear that you are both good applicants, and having a backup proposal >> will help us do you both justice in case you both make the cut. We will not >> let the presence or absence of backup proposals bias us in which one of you >> we choose to do the Karma idea. >> >> Good luck, may the best proposal win! >> >> Jameson >> >> 2009/3/24 Bryan Berry >>> >>> http://hg.olenepal.org/6_Maths_CoOrdinates_22_swf/ >>> >>> Subzero, I think this might be a great flash activity to redo for Karma. >>> Let me know if you have trouble running it on your regular machine. It >>> is in Nepali but I think you will be able to figure it out. I really >>> like how it demonstrates the concepts of coordinates and lets kids play >>> w/ those concepts. >>> >>> You can also download our latest stable monster E-Paath bundle from here >>> (224 MB) >>> >>> http://dev.olenepal.org/E-Paath-2/STABLE/ >>> >>> -- >>> Bryan W. Berry >>> Technology Director >>> OLE Nepal, http://www.olenepal.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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ideal flash activity to be remade as karma activity
I'll quite homunq again "homunq: you'd both do the work independently, so that neither of you would miss any schedule if the other one flaked out, but if you both did it you could choose which was best." Would something like this be ok? We would both work together on, let's say, adding Gears and javascript-dbus support to hulahop in the first week(s) and go on our separate ways from there. 2009/3/26 Wade Brainerd : > I've suggested something similar in past years, but Google prefers to avoid > students projects working together at all. This includes working together > on projects, or having dependencies on the results of other projects. > There is a significant failure rate for GSoC projects and it's not fair for > one student's success to be dependent on the work of another. > > If the projects can be made to work 100% independently and yet still > complement each other, then we are good. > Best, > Wade > On Thu, Mar 26, 2009 at 1:22 PM, Lucian Branescu > wrote: >> >> Hello, I have this proposal http://wiki.sugarlabs.org/go/Webified_Toolkit >> >> I've had a chat with mchua and homunq on #sugar, and here's an interesting >> idea >> "homunq: if you'd need some limited common foundation, but most of >> your work would then be separate and compatible, you could both >> schedule the foundation work in the first couple weeks, then say "we >> will then choose whose version of the foundation to standardize on" >> >> We would both need Gears and some sort of javascript-dbus bridge. >> Gears should be just a plugin and javascript-dbus could be done >> through this http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge. >> >> Then subzero could focus on the 'framework to build sugar activities >> with web technologies' part and I could focus on the 'getting web apps >> like gmail running nicely on sugar'. >> >> There's also the choice between webkit/titanium and >> gecko/xulrunner/hulahop. I think it would be better to use xulrunner, >> since it's already a Sugar dependency. It shouldn't be significantly >> slower, but we should do some testing anyway. >> >> What do you all think? >> >> 2009/3/26 Wade Brainerd : >> > Just to be clear, this is a perfectly normal part of the GSoC >> > application >> > process. Last year with OLPC I had to choose between like 6 different >> > Typing Turtle applications, several of which were quite good. And in >> > the >> > end, none of them was funded by Google. >> > So, we'll analyze your designs, schedules, resumes, related projects, >> > potential for future contribution to the project, etc. and choose the >> > best >> > one to attempt to have funded. >> > That said, getting a head start on the project and getting involved in >> > the >> > community are great ways to ensure success. Check >> > out http://wiki.sugarlabs.org/go/Print_Support for an example of an >> > applicant who has written test programs, had his ideas evaluated several >> > times on the mailing list, laid out a fairly clear technical design, >> > etc. >> > Keep in mind that we have no idea how many students we'll get from >> > Google. >> > So you are not only competing against those who submit a proposal for >> > the >> > same idea, you are competing against all the other project ideas as >> > well. >> > Best, >> > Wade >> > >> > 2009/3/26 Jameson Quinn >> >> >> >> Subzero, you have competition. >> >> >> >> Lucian, you should check out the mailing list threads for talk between >> >> Bryan and Felipe; they are talking about much the same ideas you are. >> >> >> >> Bryan, you should include Lucian in your forwards. >> >> >> >> This is not intended to endorse either Lucian or Subzero. This is one >> >> of >> >> our highest-priority projects for GSoC, and it is even conceivable that >> >> we >> >> could even accept both of your proposals, to be attempted >> >> independently. >> >> Both of you, feel free to take ideas from each other's proposals, but >> >> remember, we're assuming that you are doing that, and we'd like to see >> >> you >> >> give fair attribution. You're also both welcome to submit a backup >> >> proposal >> >> on another idea, either from the ideas list or of your own invention; >
Re: [Sugar-devel] [IAEP] ars technica
I can help translating to Romanian, if that helps. 2009/3/26 Sean DALY : > Please, if there is anyone who can help translating our press release > into Portugese, Italian, or any other language besides the four we had > at launch, I would be very grateful. > > thanks > > Sean > Marketing Coordinator ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ideal flash activity to be remade as karma activity
I've been doing some benchmarks between firefox and safari nightlies on OS X Leopard x86. Firefox had Tracemonkey and Safari had SquirrelFish Extreme. Every test was run three times and the best time was recorded. Memory usage is Real Size as reported by the OS X (Activity Monitor and top). I asked around on #firefox and #webkit, people in general agreed that the v8 bench is purely synthetic, since it mainly tests recursion and memory management. SunSpider was said to be the most indicative of real-world usage and Dromaeo the most comprehensive. The results may vary greatly on linux, and in particular the XO. bernie (or bemasc, sorry I keep getting your nicks mixed up) was thinking of testing on the XO, I don't know how far he got. (if you do test, also try the chrome experiments) In the end, I believe it may be beneficial for Sugar to switch to webkit, but it would be best to not introduce a new dependency only for the web-activity thing. The difference isn't that great and things like Bespin manage to work fine on firefox. A webkit backend for hulahop would probably be an interesting project, but I may be wrong since I don't know that much about hulahop's API. 2009/3/27 Jameson Quinn : > >> >> 3 months is a very short period to bring not only 2 but 4 people to work >> together across multiple time zones. > > I brought this up on #gsoc yesterday, and LH (the top authority) was > somewhat skeptical about any coordination. I said we would leave it up to > the students involved, and she said that sounded good, but Google would have > to approve any final plan, and they wanted to avoid any dependencies, > whether implicit or explicit, on the future work of anyone besides the > mentor and the student. > > Jameson > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ideal flash activity to be remade as karma activity
I'm such an idiot, I forgot to link the results. Here http://dl.getdropbox.com/u/317039/webkit%20vs%20gecko.txt 2009/3/28 Lucian Branescu : > I've been doing some benchmarks between firefox and safari nightlies > on OS X Leopard x86. Firefox had Tracemonkey and Safari had > SquirrelFish Extreme. > Every test was run three times and the best time was recorded. Memory > usage is Real Size as reported by the OS X (Activity Monitor and top). > > I asked around on #firefox and #webkit, people in general agreed that > the v8 bench is purely synthetic, since it mainly tests recursion and > memory management. SunSpider was said to be the most indicative of > real-world usage and Dromaeo the most comprehensive. > > The results may vary greatly on linux, and in particular the XO. > bernie (or bemasc, sorry I keep getting your nicks mixed up) was > thinking of testing on the XO, I don't know how far he got. (if you do > test, also try the chrome experiments) > > In the end, I believe it may be beneficial for Sugar to switch to > webkit, but it would be best to not introduce a new dependency only > for the web-activity thing. The difference isn't that great and things > like Bespin manage to work fine on firefox. > > A webkit backend for hulahop would probably be an interesting project, > but I may be wrong since I don't know that much about hulahop's API. > > > 2009/3/27 Jameson Quinn : >> >>> >>> 3 months is a very short period to bring not only 2 but 4 people to work >>> together across multiple time zones. >> >> I brought this up on #gsoc yesterday, and LH (the top authority) was >> somewhat skeptical about any coordination. I said we would leave it up to >> the students involved, and she said that sounded good, but Google would have >> to approve any final plan, and they wanted to avoid any dependencies, >> whether implicit or explicit, on the future work of anyone besides the >> mentor and the student. >> >> Jameson >> >> > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ideal flash activity to be remade as karma activity
I did some more testing, this time in SoaS inside VirtualBox. It's as close as I can get to an XO. I used this code for hulahop http://wiki.laptop.org/go/Sugar_Code_Snippets#WebView Similar code for pywebkitgtk. Results here http://dl.getdropbox.com/u/317039/webkit%20vs%20gecko%20soas.txt They seem to be consistent with my results on OS X. Also, it occured to me that making a pywebkitgtk backend for hulahop would be easier than I had thought. 2009/3/28 Lucian Branescu : > I'm such an idiot, I forgot to link the results. > Here http://dl.getdropbox.com/u/317039/webkit%20vs%20gecko.txt > > 2009/3/28 Lucian Branescu : >> I've been doing some benchmarks between firefox and safari nightlies >> on OS X Leopard x86. Firefox had Tracemonkey and Safari had >> SquirrelFish Extreme. >> Every test was run three times and the best time was recorded. Memory >> usage is Real Size as reported by the OS X (Activity Monitor and top). >> >> I asked around on #firefox and #webkit, people in general agreed that >> the v8 bench is purely synthetic, since it mainly tests recursion and >> memory management. SunSpider was said to be the most indicative of >> real-world usage and Dromaeo the most comprehensive. >> >> The results may vary greatly on linux, and in particular the XO. >> bernie (or bemasc, sorry I keep getting your nicks mixed up) was >> thinking of testing on the XO, I don't know how far he got. (if you do >> test, also try the chrome experiments) >> >> In the end, I believe it may be beneficial for Sugar to switch to >> webkit, but it would be best to not introduce a new dependency only >> for the web-activity thing. The difference isn't that great and things >> like Bespin manage to work fine on firefox. >> >> A webkit backend for hulahop would probably be an interesting project, >> but I may be wrong since I don't know that much about hulahop's API. >> >> >> 2009/3/27 Jameson Quinn : >>> >>>> >>>> 3 months is a very short period to bring not only 2 but 4 people to work >>>> together across multiple time zones. >>> >>> I brought this up on #gsoc yesterday, and LH (the top authority) was >>> somewhat skeptical about any coordination. I said we would leave it up to >>> the students involved, and she said that sounded good, but Google would have >>> to approve any final plan, and they wanted to avoid any dependencies, >>> whether implicit or explicit, on the future work of anyone besides the >>> mentor and the student. >>> >>> Jameson >>> >>> >> > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] help
Don't bother with the i18n, just change the python source. 2009/3/28 asran zara : > hi guys > > I (finally) have my sugar devel environment under ubuntu, > could anyone say me how to modify the labels in the menu-item (shut > down, restart,etc)? > I changed some fields of the sugar-jhbuild/source/sugar/po and then I > did ./sugar-jhbuild build > but I don't get it. > > any help is good. > thanks. > ___ > 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] [math4] FourthGradeMath Digest, Vol 2, Issue 37
The latest Jython is 2.5 RC2 I think. The problem is that Jython can't really use CPython (regular python) extensions and Sugar depends on many things, most importantly GTK. 2009/3/29 Luke Faraone : > Brian Long wrote: >> >> > >> > Is there any means of running sugar or python via a JVM? > > Sure, see http://jython.org. *Sugar* won't run in it (it's py2.4 IIRC), but > you'll get Python. > > > -- > Luke Faraone > http://luke.faraone.cc > > ___ > 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] [math4] FourthGradeMath Digest, Vol 2, Issue 37
I'm using SoaS in VirtualBox. Works great for me :) 2009/3/29 Brian Long : > Yeah, > > Sorry for any waste of time, I was debating what might be my best option for > testing anything I develop. I will probably go with "Sugar on a Stick" > instead. > > There was also some chatter on the FourthGradeMath mailing list about the > best way that teacher's involved in our projects could be exposed to Sugar. > SoaS is probably the best option for people who only have access to a PC as > well. > > Thanks, > Brian > > > > On Sun, Mar 29, 2009 at 2:57 PM, Lucian Branescu > wrote: >> >> The latest Jython is 2.5 RC2 I think. >> >> The problem is that Jython can't really use CPython (regular python) >> extensions and Sugar depends on many things, most importantly GTK. >> >> 2009/3/29 Luke Faraone : >> > Brian Long wrote: >> >> >> >> > >> >> > Is there any means of running sugar or python via a JVM? >> > >> > Sure, see http://jython.org. *Sugar* won't run in it (it's py2.4 IIRC), >> > but >> > you'll get Python. >> > >> > >> > -- >> > Luke Faraone >> > http://luke.faraone.cc >> > >> > ___ >> > 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] ideal flash activity to be remade as karma activity
I got inspired while testing webkit vs gecko and I needed a backup proposal anyway. Here it is: http://wiki.sugarlabs.org/go/Webkit_backend_for_Hulahop Please have a look when you have time. 2009/3/28 Lucian Branescu : > I did some more testing, this time in SoaS inside VirtualBox. It's as > close as I can get to an XO. > > I used this code for hulahop > http://wiki.laptop.org/go/Sugar_Code_Snippets#WebView > Similar code for pywebkitgtk. > > Results here http://dl.getdropbox.com/u/317039/webkit%20vs%20gecko%20soas.txt > They seem to be consistent with my results on OS X. > > Also, it occured to me that making a pywebkitgtk backend for hulahop > would be easier than I had thought. > > 2009/3/28 Lucian Branescu : >> I'm such an idiot, I forgot to link the results. >> Here http://dl.getdropbox.com/u/317039/webkit%20vs%20gecko.txt >> >> 2009/3/28 Lucian Branescu : >>> I've been doing some benchmarks between firefox and safari nightlies >>> on OS X Leopard x86. Firefox had Tracemonkey and Safari had >>> SquirrelFish Extreme. >>> Every test was run three times and the best time was recorded. Memory >>> usage is Real Size as reported by the OS X (Activity Monitor and top). >>> >>> I asked around on #firefox and #webkit, people in general agreed that >>> the v8 bench is purely synthetic, since it mainly tests recursion and >>> memory management. SunSpider was said to be the most indicative of >>> real-world usage and Dromaeo the most comprehensive. >>> >>> The results may vary greatly on linux, and in particular the XO. >>> bernie (or bemasc, sorry I keep getting your nicks mixed up) was >>> thinking of testing on the XO, I don't know how far he got. (if you do >>> test, also try the chrome experiments) >>> >>> In the end, I believe it may be beneficial for Sugar to switch to >>> webkit, but it would be best to not introduce a new dependency only >>> for the web-activity thing. The difference isn't that great and things >>> like Bespin manage to work fine on firefox. >>> >>> A webkit backend for hulahop would probably be an interesting project, >>> but I may be wrong since I don't know that much about hulahop's API. >>> >>> >>> 2009/3/27 Jameson Quinn : >>>> >>>>> >>>>> 3 months is a very short period to bring not only 2 but 4 people to work >>>>> together across multiple time zones. >>>> >>>> I brought this up on #gsoc yesterday, and LH (the top authority) was >>>> somewhat skeptical about any coordination. I said we would leave it up to >>>> the students involved, and she said that sounded good, but Google would >>>> have >>>> to approve any final plan, and they wanted to avoid any dependencies, >>>> whether implicit or explicit, on the future work of anyone besides the >>>> mentor and the student. >>>> >>>> Jameson >>>> >>>> >>> >> > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ideal flash activity to be remade as karma activity
There has been some talk about the interaction between my project and Felipe's. I've had an interesting chat with Bryan and Ben on #sugar. Here's the whole chat http://dl.getdropbox.com/u/317039/bryan%26bemasc%20chat.txt Here's the lastest idea: I would be focusing on building something akin to http://fluidapp.com. I keep giving it as an example because it's very minimalist, but provides the essential features to turn web apps into 'native' apps: - creates independent packages of web apps from given URLs - has Gears, so websites can be taken offline - (optional) has userstyles to customize the look of web apps - (optional) can customize keyboard shortcuts - has userscripts (GreaseMonkey) to customize the behaviour (and look) of web apps - provides some level of platform integration http://fluidapp.com/developer I'm running GMail and Google Reader and Google Docs with it and they have mostly replaced their native counterparts because they're better in almost every way: they work offline and sync to servers online, they look native because of native widgets in browser engines and a few userstyles, they're fast because everybody is focused on browser engine performance, they have sounds and native notifications because of userscripts+fluid APIs. Read my proposal for Sugar-specific details http://wiki.sugarlabs.org/go/Webified On the other hand, Felipe could focus on creating an educational framework (Karma), built on standard HTML5, JavaScript and Gears. This would handle animation (preferably through stuff), i18n (locales stored with Gears, chosen according to browser locale), general persistence (Gears & cookies), sounds () and other things an educational framework should do. Karma would only use technologies available in modern, HTML 5-supporting browsers (firefox 3/3.5, safari 3/4, opera 9/10) and Gears, which is a widely used plugin for taking stuff offline. Not only will it work with my web app sugarizer (note to self: maybe i should rename webified to sugarizer), but also with other browsers on regular computers. And Browse. However, the framework could have optional extensions (probably supported through a javascript-dbus bridge) that would improve integration with Sugar. These extensions would work, for example, on the runtime of my sugarizer. Web developers could improve the Sugar integration of the stuff they made with Karma and package the results as .xo bundles. Users would hardly be able to tell the difference. To reduce the dependency Karma would have on my project, Browse could also have a javascript-dbus bridge and Gears added to it. Security would need to be sourted out so that only Karma web apps inside .xo bundles can access dbus. How does that sound? PS: Sorry it was so long. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ideal flash activity to be remade as karma activity
Yes, I'm more interested in the slightly lower level part. As in, just making web apps work as native Sugar activities. I wouldn't invent any framework-ish thing myself as all of the framework stuff I'd use is already written or at least has a clear, usually proven API (HTML, JS, Gears, GreaseMonkey, Sugar itself). And I really care about adhering to web standards and practices, because it yields incredible code reuse and opportunities for integration. That's why I suggested that you could build Karma so that it works on (most) modern browsers, including Browse. Chrome experiments http://www.chromeexperiments.com/ proves that impressive animations and even 3D is possible with Webkit, Webkit+v8 and Firefox 3.1. AFAIK, there isn't any nice framework for building educational, interactive web apps. HTML5 (with Gears) has almost all of the features Flash has and JavaScript is very similar to ActionScript. If building stuff with Karma would be easier (or at least just higher-level) than doing the same with Flash, it would be a real incentive to stop using flash and instead use good, updated browsers (no IE). As for Webkit, I agree that it may be better for Sugar to switch to it. See my backup proposal http://wiki.sugarlabs.org/go/Webkit_backend_for_Hulahop However, Karma the way I see it should not depend on a specific engine. That's why I suggested making the deep Sugar integration stuff optional for any applications built on Karma (anything beyond saving HTML and Gears state in the Journal) If there was a need for stuff built with Karma to run outside Browse as separate activities, a demo browser or a copy of Browse itself could be used. PS: Felipe, get well soon, we need'ya! PPS: Again, this ended up very long and probably repetitive. Sorry. 2009/3/31 Felipe López Toledo : > Hi there! > > Sorry, I've been sick :s with limited internet access, I'm updating... > > I have been talking with Bryan, we both are more interested in Karma > (framework), as Lucian says: >>On the other hand, Felipe could focus on creating an educational >>framework (Karma), built on standard HTML5, JavaScript and Gears. This >>would handle animation (preferably through stuff), i18n >>(locales stored with Gears, chosen according to browser locale), >>general persistence (Gears & cookies), sounds () and other >>things an educational framework should do. > > I think that Lucian is more interested in dbus >>However, the framework could have optional extensions (probably >>supported through a javascript-dbus bridge) that would improve >>integration with Sugar. These extensions would work, for example, on >>the runtime of my sugarizer. Web developers could improve the Sugar >>integration of the stuff they made with Karma and package the results >>as .xo bundles. Users would hardly be able to tell the difference. > >>To reduce the dependency Karma would have on my project, Browse could >>also have a javascript-dbus bridge and Gears added to it. Security >>would need to be sourted out so that only Karma web apps inside .xo >>bundles can access dbus > in this way our projects won't be mutually dependent and we can work in > parallel > > btw, I rise the hand to use WebKit. > > greetings. > > 2009/3/29 Bryan Berry >> >> I really like this idea. Felipe, Wadeb what do you think? >> >> On Mon, 2009-03-30 at 04:49 +0200, Lucian Branescu wrote: >> > There has been some talk about the interaction between my project and >> > Felipe's. >> > >> > I've had an interesting chat with Bryan and Ben on #sugar. Here's the >> > whole chat http://dl.getdropbox.com/u/317039/bryan%26bemasc%20chat.txt >> > >> > Here's the lastest idea: >> > >> > I would be focusing on building something akin to http://fluidapp.com. >> > I keep giving it as an example because it's very minimalist, but >> > provides the essential features to turn web apps into 'native' apps: >> > - creates independent packages of web apps from given URLs >> > - has Gears, so websites can be taken offline >> > - (optional) has userstyles to customize the look of web apps >> > - (optional) can customize keyboard shortcuts >> > - has userscripts (GreaseMonkey) to customize the behaviour (and look) >> > of web apps >> > - provides some level of platform integration >> > http://fluidapp.com/developer >> > >> > I'm running GMail and Google Reader and Google Docs with it and they >> > have mostly replaced their native counterparts because they're better >> > in almost every way: they work offline and sync to servers online, >&g
Re: [Sugar-devel] [Bugs] #645 UNSP: make sugarlabs.org the default page
Perhaps google would be interested in hosting a homepage like they do for firefox? It would at least be faster to load. 2009/4/1 Simon Schampijer : > Gary C Martin wrote: >> On 31 Mar 2009, at 22:40, Gary C Martin wrote: >> >>> On 30 Mar 2009, at 14:59, Sean DALY wrote: >>> I really like this idea, "baseline" so first-time visitors won't get lost between site sections Christian, would it be possible for you to put together that 1 page linking to the different sections + Google? >>> FWIW: Assuming it's not being worked on yet, I just picked this ticket >>> up. Will post a screen grab to the list tomorrow for quick review/ >>> feedback cycle. >> >> Here's a quick first pass at a simple static page, please do fire off >> some feedback - FWIW, I'm not too keen on how the Google treatment >> clashes with SL logo, but it is a useful feature to have on a home page: >> >> >> http://dev.sugarlabs.org/attachment/ticket/645/simple_static_page_v1.png >> >> Regards, >> --Gary >> >>> --Gary > > Do we need the google logo for trademark reasons? Otherwise I would just > leave it out. It says 'Google' on the button already. > > Would be nice to have a link to our bug tracker as well - maybe just > named 'Bugs'. > > Of course - ideally this page would be translated :/ We can do that for > 0.86 then I guess :) > > Thanks, >Simon > ___ > 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] ideal flash activity to be remade as karma activity
2009/4/1 Bryan Berry : > On Tue, 2009-03-31 at 15:45 +0200, Lucian Branescu wrote: > In the short-term, we need to create some proof-of-concept animations w/ > audio and client-side i18n. It would be great to have at the end of the > summer some re-usable javascript libraries for lesson plan reader, > navigation, help, etc. I'll look into audio (programmable from JS) and i18n. is already proven :) >> And I really care about adhering to web standards and practices, >> because it yields incredible code reuse and opportunities for >> integration. That's why I suggested that you could build Karma so that >> it works on (most) modern browsers, including Browse. Chrome >> experiments http://www.chromeexperiments.com/ proves that impressive >> animations and even 3D is possible with Webkit, Webkit+v8 and Firefox >> 3.1. > > Absolutely, web standards make everyone's life easier > I'd meant to put more emphasis on practices. For interoperability, but most importantly to make skills transferrable. Web developers would find a native API being recommended instead of or unusual and unintuitive. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Call for Testers (New Snapshot!)
The ISO boots up fine in VirtualBox. Again, the vmdk appliance doesn't. http://dev.sugarlabs.org/ticket/677 2009/4/4 Sebastian Dziallas : > Hi folks, > > the SoaS team has another snapshot ready for testing - it's absolutely > important that it get's tested as much as possible for our release! > > You can grab it from here: > > http://download.sugarlabs.org/soas/snapshots/2/Soas2-200904031934.iso > > If you're going to put it on a USB key or a SD card under Linux, please > make sure to use exactly this version of livecd-iso-to-disk, as you > might encounter issues with other versions, which are around: > > http://shell.sugarlabs.org/sdz/livecd-iso-to-disk.sh > > There's also a new appliance snapshot available, but testing should > really focus on the .iso file for now: > > http://download.sugarlabs.org/soas/appliances/soas2-20090403.tar.gz > > What has changed? > > * We're now supporting locales! You can change it in the control panel. > * You'll notice our funky boot screen - no hotdog anymore... ;) > * Browse has been updated - including skin and default page changes! > > Again, please give it a try. And if you think that we should include > this or that specific activity, make sure to come up with it! > > So long, thanks and happy testing, > --Your SoaS Team > ___ > 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] webified and google gears
2009/4/14 Tomeu Vizoso : > On Tue, Apr 14, 2009 at 20:19, Lucian Branescu > wrote: >> Gears is just a XUL extension, packaging shouldn't be a problem. > > You mean you are volunteering to package it? ;) > > David Van Assche already worked on it and got it pretty much working, > but it never was submitted to fedora. Would you like to finish this > work? > > Packaging work might not seem too challenging, but consumes quite a > bit of time and is crucially important for projects like Sugar. > I'll have to look into that, then. >> Also, >> it does not require sync-ing state, web apps can store everything in >> Gears and work in offline mode. Gears provides some integration with >> the desktop (which can simply be ignored, it's mostly desktop >> shortcuts and the like), an SQLite database accesible from JS and a >> Worker (thread-like) object. > > Sounds good. > >> Using existing web technologies and standards (de facto or not) is >> very valuable, especially for my case. I don't want to invent any new >> technologies or techniques, just to provide a simple Site Specific >> Browser. If I were to do so, existing web apps would have to be >> modified and new ones would be unusual from the POV of web developers. > > Agreed. > >> For Journal integration, the entire Gears database could be store in >> the DataStore. > > That would work fine, only that for example a karmized web app that > processes images might make more sense to write a png file, so other > activities can open it. But I don't think it's a critical point. > The Desktop module in Gears can access local files, with permission from the user. So a Gears web app that deals with files should be able to do this. > Regards, > > Tomeu > > >> 2009/4/14 Tomeu Vizoso : >>> Hi, >>> >>> I like your proposal because focuses on a problem interesting to the >>> Sugar community and because proposes a solution that is reasonable >>> enough to be implemented in the GSoC timeframe. >>> >>> But the mention of google gears concerns me a bit, since no >>> distribution that I know is packaging it and because AFAIK it would be >>> sync'ing state between local storage and a remote server when >>> activities are supposed to be storing it's whole state to the journal. >>> >>> From my current POV, may be better to provide a (XPCOM?) component >>> accessible from JS that provides DataStore integration. I think it >>> could be fairly simple to do with hulahop. >>> >>> On the other hand, we should really find a way to have Google Gears >>> installed alongside Sugar because many interesting sites require it, >>> but it may be out of scope form your proposal. >>> >>> Regards, >>> >>> Tomeu >>> >> > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] webified and google gears
I don't have experience with rpm, but since much of the work is already done, I guess packaging it wouldn't be a problem. Especially since it would only be necessary after the SSB actually works, although earlier can't hurt. 2009/4/14 Tomeu Vizoso : > On Tue, Apr 14, 2009 at 21:42, David Van Assche wrote: >> I can send over what I have... I had the rpm source file somewhere... >> I can look for it if there is interest... > > Yes please, the .spec file will be a good step forward. > > Thanks, > > Tomeu > >> David >> >> On Tue, Apr 14, 2009 at 8:36 PM, Lucian Branescu >> wrote: >>> 2009/4/14 Tomeu Vizoso : >>>> On Tue, Apr 14, 2009 at 20:19, Lucian Branescu >>>> wrote: >>>>> Gears is just a XUL extension, packaging shouldn't be a problem. >>>> >>>> You mean you are volunteering to package it? ;) >>>> >>>> David Van Assche already worked on it and got it pretty much working, >>>> but it never was submitted to fedora. Would you like to finish this >>>> work? >>>> >>>> Packaging work might not seem too challenging, but consumes quite a >>>> bit of time and is crucially important for projects like Sugar. >>>> >>> >>> I'll have to look into that, then. >>> >>>>> Also, >>>>> it does not require sync-ing state, web apps can store everything in >>>>> Gears and work in offline mode. Gears provides some integration with >>>>> the desktop (which can simply be ignored, it's mostly desktop >>>>> shortcuts and the like), an SQLite database accesible from JS and a >>>>> Worker (thread-like) object. >>>> >>>> Sounds good. >>>> >>>>> Using existing web technologies and standards (de facto or not) is >>>>> very valuable, especially for my case. I don't want to invent any new >>>>> technologies or techniques, just to provide a simple Site Specific >>>>> Browser. If I were to do so, existing web apps would have to be >>>>> modified and new ones would be unusual from the POV of web developers. >>>> >>>> Agreed. >>>> >>>>> For Journal integration, the entire Gears database could be store in >>>>> the DataStore. >>>> >>>> That would work fine, only that for example a karmized web app that >>>> processes images might make more sense to write a png file, so other >>>> activities can open it. But I don't think it's a critical point. >>>> >>> >>> The Desktop module in Gears can access local files, with permission >>> from the user. So a Gears web app that deals with files should be able >>> to do this. >>> >>>> Regards, >>>> >>>> Tomeu >>>> >>>> >>>>> 2009/4/14 Tomeu Vizoso : >>>>>> Hi, >>>>>> >>>>>> I like your proposal because focuses on a problem interesting to the >>>>>> Sugar community and because proposes a solution that is reasonable >>>>>> enough to be implemented in the GSoC timeframe. >>>>>> >>>>>> But the mention of google gears concerns me a bit, since no >>>>>> distribution that I know is packaging it and because AFAIK it would be >>>>>> sync'ing state between local storage and a remote server when >>>>>> activities are supposed to be storing it's whole state to the journal. >>>>>> >>>>>> From my current POV, may be better to provide a (XPCOM?) component >>>>>> accessible from JS that provides DataStore integration. I think it >>>>>> could be fairly simple to do with hulahop. >>>>>> >>>>>> On the other hand, we should really find a way to have Google Gears >>>>>> installed alongside Sugar because many interesting sites require it, >>>>>> but it may be out of scope form your proposal. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Tomeu >>>>>> >>>>> >>>> >>> ___ >>> 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] discussion of which javascript framework to use for Karma
jQuery makes the DOM suck less, that's it's main plus. I think the jQuery UI is complete enough for most tasks and doesn't have architectural constraints that keep it from getting better. It's also quite small. However, I don't think it should matter too much which framework is blessed. Web devs have their preferences (granted, most like jQuery). If jQuery in compatibility mode is used for the framework itself, web devs can use whichever framework they like. They get more consistency if they use jQuery, but it shouldn't be a problem if they don't. 2009/4/21 Bryan Berry : > Subzero, > > below is a conversation I had w/ my friend Christopher Marin who is a > web developer. El es ecuadoreno pero crecimos juntos en Los Angeles. > > also, this google trends report should be of interest > http://www.google.com/trends?q=dojo%2C+extjs%2C+jQuery%2C > +mootools&ctab=0&geo=all&date=ytd&sort=0 > > me: hey dude, have a moment to chat? > C: Sure > me: I am working w/ a GSoC participant on Karma > the first thing to do is evaluate which js framework to use > we are going to evaluate dojo, jQuery, and at least 1 more > what do you recommend? > Christopher: Great > My favorite general use js framework at the moment is jQuery. It seems > to have the most momentum behind it, creator is js genius, and it is > easy to write apps with it. > The only thing it doesn't have a strong base in right now is widgets > me: and widgets are what? > Christopher: In my opinion ext is tops here. > Things like grids, windowing and layout systems, tabs, menus, > accordions, etc > me: will jQuery catch up in time? or is it limited architecturally? > Christopher: Ext can actually run on top of jquery > So in our app at my company we run both jquery and ext > Jquery has ui project > me: and jquery-ui is analogous to extjs widgets? > Christopher: They've made good strides lately, already have a book out > just on that subproject > Yes, but not as mature or near the range of functionality, yet, though > I'm sure they'll catch up eventually > Ext is coming out with a major new release soon, the base version of 3 > is already outC > Best thing to do with them is to check out their samples, documentation > is also top notch. Also a few books came out on ext recently > me: what about extjs community? its leadership? > Christopher: Only issue with ext is licensing > me: i don't like licensing problems at all > Christopher: They made their licensing more strict as of 3. Free for > open source projects, uses gpl > But commercial is supposed to pay > me: but for-profit, closed-source companies have to pay? > Christopher: Community and leadership of ext good, though nothing > seems as large as jquery community nowadays > me: I don't like that. I want closed-source education companies to > switch from Flash to js > How do u compare dojo to jQuery? > Christopher: Yes, those have to pay > Microsoft and nokie recently standardized on jquery > Nokia > So lots of folks from those camps are contributing code and samples > me: cool, and big for-profit edu companies will like it better if uses > similar technologies to MS > Christopher: Dojo is mature, probably stronger in widgets, or at > least more standardized in terms of look and feel > The thing is with jquery there are a million plugins, but until ui > project there was no standardization of look and feel, and how > components shoulkd interact > Sent at 9:52 AM on Tuesday > Christopher: That's the beauty of ext, you can do a full almost > desktop like ui with sortable, filterable grids, even bake it all into > adobe air. jquery not quite there yet > Sent at 9:54 AM on Tuesday > me: it's pretty critical to me that commercial companies use our > little framework. Anything that slows down commercial adoption would be > bad. > Christopher: But back to dojo, my sense is that it has lost momentum, > along with prototype and scriptaculous. Mootools is another intersting > one. > me: could dojo regain the momentum? does it have good leadership? > Christopher: An interesting experiment would be to do a search of > these on google trends. You'll see how these have fared over the last > year > me: sure > Sent at 9:56 AM on Tuesday > Christopher: If I had to pick one framework it would be jquery > Chances are, someone somewhere will have solved many of the challenges > you'll face > me: which is what I am really hoping for > what are more plusses, minuses for dojo? > here is an older trend report file:///home/hitman/Desktop/Personal/Link% > 20to%20docs/javascript/jquery/jquery_beginning_part1_files/trends.jpg > Christopher: To be honest I haven't used it much at all. Tried one of > their widgets a couple years ago. I think the thing I didn't like at the > time was the skins, they weren't particularly pretty. > On my cell right now, can't see links > me: john resig is really impressive > Christopher: Yeah, just used one of his functions of his blog a few
Re: [Sugar-devel] Fwd: Print Support (journal vs activity)
I vote for the second option. Having Read do this makes sense to me: if you want to read (including preview) something you either read it off the screen or print it and read it off a paper. 2009/4/22 Vamsi Krishna Davuluri : > > Yep, agreed, though for some reason if the user has a file other than that > specified format, and wants to print it badly (say a file which he just > transferred from his pendrive), in-activity printing would never work, and > even having a missing odf filter would be inviting a loophole. So my idea is > I will create a filter for every default format and include it (which is > only odf) (we wont have even one additional filter, and as we wont be > requiring PPD files for either wifi printing or pdf conversion through > cups-pdf we would be reducing the installation size greatly) that taken care > of, > > here's a brief outlline of journal printing, > we create a new button, for previewing purposes open it with read, for print > purposes link to a printing activity (building a print activity is final > step) end gsoc. apart from moodle this is the skeleton I think is best. > instead of trying to write print code for each new activity why not just see > to it that we follow a norm of filters? > > OR TWO! , we avoid all this complicated stuff, we make read our printing > dock, any file sent to journal will be opened by read when we want to print > it or preview it and for all the objects this will do pdf drawing for moodle > and create a journal item as pdf too, and for direct printing use gtkprint. > > Please, try to agree to one of these, both are technically journal printing, > both send pdf to moodle. > > On Wed, Apr 22, 2009 at 12:05 AM, Andrés Ambrois > wrote: >> >> On Tuesday 21 April 2009 14:16:36 Tomeu Vizoso wrote: >> > On Tue, Apr 21, 2009 at 19:02, Carol Farlow Lerche >> > wrote: >> > > It's entirely unclear what this project has morphed to. Tomeu, what >> > > use >> > > is uploading arbitrary journal entries to Moodle? >> > >> > Because the chances that the needed filter to convert that file to a >> > printable format is in the server are bigger than being in every >> > machine, for some deployments. >> > >> > > I thought creating pdf >> > > output in sugar and enabling uploading of the pdf to Moodle was the >> > > point >> > > of this project. That is useful in two ways. First, it is a path to >> > > assignment turn-in or printing either through Moodle or by other >> > > transports to a system configured to print pdfs. It also allows a >> > > student to review the printer-ready output to decide if it is worth >> > > getting hard copy. >> > >> > Sure, I though I had made clear than printing to PDF in Sugar has >> > important use cases. >> > >> > Regards, >> > >> > Tomeu >> >> My idea for dealing with the headache of filters is assuming only pdf/ps >> is printable, and having the Journal display a "Print" button if and only if >> the mimetype is pdf or ps. >> >> This way we can then make the decision of sending it to moodle via >> xml-rpc, a local cups queue, or a remote cups server using lpr. >> >> Activities that can't output to pdf/ps will be provided with gtkprint >> facilities and a pdf journal entry will be generated after they draw their >> output. >> >> Vamsi has already hacked pdf output into Write, so that's one big activity >> we will have covered. >> >> For the security issues, activities will only generate a journal pdf >> entry, which would be displayed using show_object_in_journal or somesuch >> (just like Chat currently handles opnening URLs). The user will then have >> the ability to immediately review the printable output and/or send it to the >> preferred queue. >> >> This architecture follows some basic principles: >> >> 1) Paper/Ink is expensive, we need a way to easily and reliably review >> what's going to be printed. Requiring people to load up Browse, navigate >> inside Moodle, and download a PDF file for review, is not exactly >> user-friendly. >> >> 2) We don't need to specify a set of "required" filters...yet, we can >> easily expand this to "well, HTML, JPG and PNG are probably going to be >> supported by every CUPS out there, so admit those as well", but I think 1) >> is priority here. >> >> 3) Following up on 2), the journal mechanism is orthogonal to what we end >> up sending to Moodle. Ben and Tomeu have sort of agreed on sending the raw >> journal entries to Moodle, so we can use all the CUPS filters on the server, >> this conflicts with 1) in my view, but it has its advantages. >> >> > > On Tue, Apr 21, 2009 at 9:36 AM, Tomeu Vizoso >> > > wrote: >> > >> On Tue, Apr 21, 2009 at 18:29, Benjamin M. Schwartz >> > >> >> > >> wrote: >> > >> > -BEGIN PGP SIGNED MESSAGE- >> > >> > Hash: SHA1 >> > >> > >> > >> > Tomeu Vizoso wrote: >> > >> >> Printing is not limited to uploading files to moodle, we provide >> > >> >> both >> > >> >> local and server printing and users will use whatever works in >> > >> >> their >> > >> >> envir
Re: [Sugar-devel] processing.js - tool to replace flash in websites [KARMA]
I guess my brain was a tad outdated. So Sizzle is very cool, but
doesn't add anything if you're already using jQuery.
Hehe, hippies. And what are we?
2009/4/27 Ties Stuij :
> On Mon, Apr 27, 2009 at 7:21 AM, Bryan Berry wrote:
>> thanks for the reality check ;). Processing.js is probably overkill for
>> the simple stuff we need to do. It is easy to get distracted w/
>> high-quality animations when what we need are simple animations that are
>> very responsive to the user.
>>
>> I have fallen in love w/ the default jQuery selector engine. It is
>> pretty darn fantastic.
>
> Actually Sizzle *is* the default jQuery CSS selector engine. From the
> jQuery source:
>
> * Sizzle CSS Selector Engine - v0.9.3
> * Copyright 2009, The Dojo Foundation
> * Released under the MIT, BSD, and GPL Licenses.
> * More information: http://sizzlejs.com/
>
> Notice the Dojo copyright attribution!
> It's hard to keep these frameworks apart these days. I've also seen
> YUI attributing Resig amongst others in some ajax code, Resig reacting
> on a Mootools mailing-list post. Aren't they supposed to compete with
> each-other? Damn hippies.
>
> /Ties
>
>
>> On Sun, 2009-04-26 at 12:41 +0100, Lucian Branescu wrote:
>>> Processing.js is a port of Processing (JVM) and it doesn't really have
>>> anything to do with jQuery. It uses as a backend for drawing
>>> things, so it needs recent enough browsers.Try it in a webkit browser
>>> or Chrome. They're much faster for most things than Firefox.
>>>
>>> I don't know if the abstraction Processing.js offers over plain
>>> is useful for Karma or it's just overhead.
>>>
>>> jQuery already has a selector engine ( called by $('bla') ), afaik
>>> Sizzle is supposed to be a jQuery-independent selector engine. I don't
>>> think it has much use outside of creating js libraries.
>>>
>>>
>>> 2009/4/26 Bryan Berry :
>>> > Hey Subzero,
>>> >
>>> > I just came across this blog post from John Resig, the creator of
>>> > jQuery. He kicked off a processing.js to replace flash for animations. I
>>> > am not really sure how it relates to jQuery
>>> >
>>> > http://processingjs.org/
>>> >
>>> > he also has a new project sizzle that is a CSS3 selector engine
>>> > http://sizzlejs.com/
>>> >
>>> > frankly, I don't actually know what a CSS3 selector engine is or what
>>> > CSS3 selectors are but looks interesting
>>> >
>>> > http://processingjs.org/exhibition
>>> >
>>> > here are some demos. Interesting thing is that these demos really rev my
>>> > CPU. I have a centrino dual-core 2 GHz. Firefox chews up 70% of my
>>> > processor. However, when I stream Youtube Firefox also often chews up
>>> > 50% of my processor so not sure if firefox is at fault or processing.js
>>> >
>>> >
>>> > --
>>> > Bryan W. Berry
>>> > Technology Director
>>> > OLE Nepal, http://www.olenepal.org
>>> >
>>> > ___
>>> > Sugar-devel mailing list
>>> > Sugar-devel@lists.sugarlabs.org
>>> > http://lists.sugarlabs.org/listinfo/sugar-devel
>>> >
>> --
>> Bryan W. Berry
>> Technology Director
>> OLE Nepal, http://www.olenepal.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] [KARMA] don't need an ide for js
I've used the Webkit inspector thing, it rivals firebug. Less features, though. I've always just used a text editor for JS work. I don't like IDEs in general. 2009/5/4 Felipe López Toledo : > Hi Bryan > >>i don't see myself using aptana or another special ide. firebug + emacs >>are a perfect fit. > yes, you're right! > > my early reason to use aptana was fast coding through the html assistant, > highlight and auto completion tool. one of the *good* things of aptana is > the inclusion (choose) of the javascript library (dojo, jquery, mootols, > etc).. > but, I felt like slow using it.. > > I just ended using gedit / kate + firebug > > here is another tool like firebug (venkman from mozilla) > http://www.mozilla.org/projects/venkman/ > > currently reading about it at > http://www.mozilla.org/projects/venkman/venkman-walkthrough.html > > > > > 2009/5/3 Bryan Berry >> >> subzero, >> >> i am pretty darn blown away by how useful firebug is >> >> check out this tutorial >> http://www.evotech.net/blog/2007/06/introduction-to-firebug/ >> >> and the intro pages here: >> http://www.getfirebug.com >> >> i don't see myself using aptana or another special ide. firebug + emacs >> are a perfect fit. >> >> -- >> Bryan W. Berry >> Technology Director >> OLE Nepal, http://www.olenepal.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] Browse.xo performance & resolution - Hulahop 200dpi vs Browse 134dpi
This is very interesting, similar to the problem Qt used to have on Maemo. I was always surprised by report of being slow on the XO, it's probably the fastest and the lowest overhead drawing technology available to JavaScript. 2009/5/15 Martin Langhoff : > On Fri, May 15, 2009 at 9:56 AM, Martin Langhoff > wrote: >> - I am intrigued, hulahop sources say it's hardcoded to 200dpi (and >> that jives with our screen) - why does it end up being 134? Should it >> be 200dpi? Would that hit the fast paths properly? (Mihai: does 200dpi >> make it better?) > > At least that part of the mystery is solved -- hulahop checks whether > dpi == 200dpi, and in that case... sets the dpi to 134. See > _get_layout_dpi here: > http://dev.laptop.org/git/projects/hulahop/diff/python/__init__.py?id=32a18dfc6da97801673dd0bf7424350489694ca0 > > Marco, do you remember where the magic 134 came from? > > Still chasing up why canvas rendering goes through the floor @ 134... > > cheers, > > > > 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-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] Browse.xo performance & resolution - Hulahop 200dpi vs Browse 134dpi
Does anyone know how gecko 1.9.1's full page zoom interacts with ? 2009/5/16 Albert Cahalan : > Martin Langhoff writes: > >> The short version of it is that canvas (and image rendering in >> general) is hurting lots due to the dpi being hardcoded to 134 >> which forces Gecko into image scaling games. Just setting >> layout.css.dpi to 96 makes Browse much snappier in general, >> and incredibly faster in canvas painting. > > This was discovered when scaling was first enabled. > > One could write a special-case scaler for that DPI, > avoiding the more generic scaling code. > > The XO also suffers from 5:6:5 pixel layout, which requires > lots of bit shifting. > >> It also makes pages unreadably small though. > > It's not just the size. The XO screen purposely smears the pixels > to reduce color fringing. > >> Questions: >> >> - I am intrigued, hulahop sources say it's hardcoded to 200dpi >> (and that jives with our screen) - why does it end up being 134? >> Should it be 200dpi? > > 134 puts 860x645 web pixels on the screen. We do this partly because > it is enough pixels for most modern web pages, and partly because of > a persistant myth that the XO screen resolution is equal to 800x600. > In other words, it's an arbitrary number with feeble justification. > > There are at least two reasonable ways to deal with this problem. > > The first way is to use the hardware scaling. This involves telling > the X server to change screen resolution. Sugar would need to manage > this on a per-activity basis, with adjustments to the frame as needed. > Besides elimination of scaling, the browser would move fewer pixels > and need less memory. It'd be amazing for performance. A downside is > that text would be less sharp, both from the scaler operation and more > directly from having fewer pixels. > > The second way is to choose a scaling factor that is easy to optimize, > and then do so. Easy would be 128 (3:4 ratio, 900x645 web pixels) or > 144 (2:3 ratio, 800x600 web pixels). You could optimize both, along > with 192 (1:2 ratio, 600x450 web pixels), and let users get a choice. > Unscaled can be an option too. > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse.xo performance & resolution - Hulahop 200dpi vs Browse 134dpi
I was thinking whether it has some scaling optimisations, since it does a lot of it with the zoom. 2009/5/17 Mihai Sucan : > Le Sun, 17 May 2009 14:30:16 +0300, Lucian Branescu > a écrit: > >> Does anyone know how gecko 1.9.1's full page zoom interacts with ? > > Please be more specific. > > As far as I know, zooming is applied "transparently" - the Web application > does not "observe" the changes. Dimensions of all elements, including the > canvas element, remain the same. This is similar to changing the DPI. > Obviously, drawing on the canvas is slower, since the canvas image needs to > be scaled to the zoom level. > > > > > -- > Mihai Sucan > http://www.robodesign.ro > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] soas live cd on MacBook? How?
rEFIt http://refit.sourceforge.net/ is akin to GRUB, but nicer. It detects and shows all boot options. 2009/5/20 Sean DALY : > This may be helpful too: > > http://support.apple.com/kb/HT1310 > > > > On Wed, May 20, 2009 at 1:03 PM, Sean DALY wrote: >> For completeness, here are the documented Apple OSX keyboard >> shortcuts, stable over the past six versions (10.0->10.5): >> >> http://support.apple.com/kb/HT1343 >> >> Potentially useful at boot time: the Option key (looks like a ski >> slope) to show & select bootable volumes >> >> Sean >> >> >> >> On Wed, May 20, 2009 at 12:33 PM, Dave Bauer wrote: >>> >>> >>> On Wed, May 20, 2009 at 2:31 AM, Edward Cherlin wrote: On Tue, May 19, 2009 at 11:08 PM, Caryl Bigenho wrote: > Hi, > > I downloaded soas-beta.iso to my MacBook and burned it to a disk. I > would > like to get it to boot and be usable on the MacBook. Does anyone know > how > to do this? Most x86 ISOs boot just fine on an x86 Mac with no preparation other than to tell MacOS to boot from the CD. PPC, no. ^_^ >>> >>> You can reboot and hold down the "C" key to boot from the CDROM. >>> >>> Dave >>> > Thanks, > > Caryl > > ___ > IAEP -- It's An Education Project (not a laptop project!) > i...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > -- Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name And Children are my nation. The Cosmos is my dwelling place, The Truth my destination. http://earthtreasury.org/worknet (Edward Mokurai Cherlin) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel >>> >>> >>> >>> -- >>> Dave Bauer >>> d...@solutiongrove.com >>> http://www.solutiongrove.com >>> >>> ___ >>> IAEP -- It's An Education Project (not a laptop project!) >>> i...@lists.sugarlabs.org >>> http://lists.sugarlabs.org/listinfo/iaep >>> >> > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] possible foundation for an email activity
It looks lovely, even has conversations (the one absolutely necessary feature of GMail). The GUI is also very simple, most of it is the WebView. 2009/5/22 Tomeu Vizoso : > Hi, > > Anjal uses Webkit and the evolution backend and has a cool UI, may be > interesting to see how to use that code in an activity. > > http://live.gnome.org/Anjal > > Regards, > > Tomeu > ___ > 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] Sugar with Metacity (again)
Perhaps Maximus from Ubuntu netbook remix may help with emulating matchbox behaviour? https://launchpad.net/maximus I don't really have a say in this, but I'd go for EWMH compliance. Even Compiz could be used in XO 1.5, since it has some 3D support. 2009/5/23 Jonas Smedegaard : > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > On Sat, May 23, 2009 at 07:30:15PM +0200, Bernie Innocenti wrote: >>On 05/23/09 19:16, Bernie Innocenti wrote: >>> I couldn't get this to boot, it hangs some time after the grub menu. >>> But it might be because qemu is broken in Fedora 11. >> >>Oh, wait! It was just damn slow because I wasn't using kvm >>(permissions issue). >> >>Now I could test it, and it looks good, modulo the bugs that Tomeu and >>Gary reported. TurtleArt would work for me, but the window was >>mispositioned. >> >>I'd say: let's switch early in the 0.86 release cycle, as soon as we've >>shaked the major bugs, so activity maintainers have time to fix the >>remaining issues in their code. > > Do you really mean to say that switching window manager should be done > in a stable environment? Or did you mean to suggest swtiching early > _after_ the 0.86 release? > > > >>The only thing I didn't like very much is memory usage: 21MB VIRT, 10MB >>RSS. But I suppose we can't do much about it. > > Is the purpose to switch from one specific window manager to another > specific one, or to move towards working properly with any > EWMH-compliant window manager (and just picking one of them by default)? > > GNOME can work with different window managers too, even if it ships with > this one as default. > > > - Jonas > > - -- > * Jonas Smedegaard - idealist og Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEAREDAAYFAkoYOssACgkQn7DbMsAkQLjXAQCeLGCK7GvW7PnLxRxg5GO++lg+ > TQsAoJZ0RdYsWOleadgD+2Rbl0LyTkte > =Dq8b > -END PGP SIGNATURE- > ___ > 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] soas live cd on MacBook? How?
blessing would be useful for enabling 'boot from USB'. 'boot from CD' or 'boot from USB with helper CD' don't need it. 2009/5/24 Andrea Mangiatordi : > Jonas Smedegaard wrote: >> You cannot run the currently released SoaS on a PowerPC Macintosh. > > That's why I wrote "so I can't test it directly" ;) > >> SoaS is only currently compiled for 32bit x86, which works on amd64 but >> not on PowerPC. > > Yeah, I had to use jhbuild and precompiled ubuntu packages in order to > try and use Sugar. > > I don't really know if the boot management system is the same on all > Macs, what I wanted to say is that there are live Linux distributions > for both series and those distros only include free software, so there > won't be any need for the developers to use proprietary blessings. > > Kind regards > > Andrea > > -- > Andrea Mangiatordi > > www.farfalla-project.org > www.bglug.it > ___ > 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] Physics activity development
I'm in the same situation (well, I will be when I get my macbook back). I do see a lot of talk towards making Sugar and activities behave more like standard applications. Perhaps Sugar will work on OS X natively some day. 2009/5/27 Gary C Martin : > Hi Asaf, > > On 27 May 2009, at 05:00, Asaf Paris Mandoki wrote: > >> Hi, >> >> I would like to get started adding the play/pause button and the pin >> button. Probably the next step is to integrate the activity with the >> journal. The only problem is that I haven't been able to get my >> development environment working. It seems there are some open issues >> with ubuntu. My plan right now is to wait until the Ubuntu issues >> are fixed. Any suggestions for a better setup? The only thing I have >> working now is a virtualbox environment where i've been testing the >> activity and found some bugs. I saw a commit with the "joystick" >> feature removed. Is the base code ready to start adding the minor >> button changes? > > As for my part I'll hold off making any changes for now. Too many > cooks, but a nice situation to be in :-) > > Other than recommending, A) trying to keep in the habit of working in > your own git branch and then merging back to master when stable; or B) > use Gitorious to just clone the repository and work there, then make a > merge request when your done (this option is more visible as folks can > see what you doing as you commit changes and you can also give your > branch a nice visible name). > > Have a chat and co-ordinate with Brian and see what his current plans > are; the other usual way to communicate would be to create trac > tickets (dev.sugarlabs.org) for the bugs/features you want to work on, > assign it to yourself, and cc: the others involved (bjordan and myself > at the moment) – unfortunately the Physics component has not yet been > added (and there is no temporary 'other') so you'll need to email/chat > just for now. > > Regarding development environments; I have a Mac here, so spend most > time in VirtualBox with Fedora 10 and sugar-jhbuild, though I'd have a > much simpler Activity development set-up if I could just use a recent > Sugar distro in VirtualBox, but the distros are all still a little too > 'pre-release' to want to rely on just now – running a Mac, running > VirtualBox, running sugar-jhbuild, running Sugar is rather a wasteful > and large stack of code I hope to avoid at some point :-) > > Regards, > --Gary > >> Thanks, >> Asaf >> >> >> On Mon, May 25, 2009 at 2:17 AM, Brian Jordan >> wrote: >> On Sun, May 24, 2009 at 8:59 PM, Gary C Martin >> wrote: >> > Hi Brian, >> > >> > On 24 May 2009, at 18:36, Brian Jordan wrote: >> > >> >> Hey all, >> >> >> >> Gary -- when you get a chance, can you add me as a committer on >> >> git.sl.o? I'd like to help clean things up! >> > >> > You're added! :-) >> > >> > Can I request we try and make small clean commits and try to let >> others know >> > what we are doing. If you want to hack, Gitorious supports quite a >> nice >> > 'Clone repository' and then 'Request merge' process (no commit >> rights needed >> > for the main project). The alternative, if you know what you are >> doing, is >> > just make your own local git branch to hack on, so you can take >> care of any >> > merge/conflict issues yourself when you fold it back into the >> current >> > master. >> > >> > I'm far from a git expert, but I can recommend some bed time >> reading at: >> > >> > http://www.eecs.harvard.edu/~cduan/technical/git/ >> > >> > and/or >> > >> > http://gitready.com/ >> > >> >> Thank you, will devote some to that! Need to learn to keep my crazy >> features in branches. >> >> > I'd like to get on with Labyrinth work, if you're willing to have >> an initial >> > clean up of the Physics source in the next few days... so what was >> > 'joysitck' feature all about? ;-) >> >> This would probably be best to describe on the wiki page, the idea was >> to make a UI for assigning keys on the XO-1 to impulses or changes on >> certain objects, so simple 2 player physics based games could be made >> from within Physics. >> >> Agreed, though, I will rid that from the code so we have a nice base >> line for crazy-feature branches. >> >> > Once the dev.sugarlabs.org component is added we should add the >> > features/bugs in there to keep them all together. FWIW, from a UI >> point of >> > view I had in mind: >> > >> > 1) remove/disable 'joysitick' feature as I have no idea what it >> was meant to >> > be ;-) >> > 2) build tool buttons correctly using RadioToolButton so they >> display state >> > correctly >> > 3) use set_accelerator to define visible keyboard shortcuts for >> the tools >> > >> >> Asaf -- do you have a http://git.sugarlabs.org account yet? >> >> >> >> This is some feedback from Asaf (these could fit as enhancements in >> >> http://dev.sugarlabs.org/ ): >> >> >> >>> While playing with the activity I found a "pause" button to stop >> time >> >>> could be very useful. It's compl
[Sugar-devel] Gears in Browse
For both Webified and Karma, Gears support in Browse is necessary (or at least preferred), but AFAIK there is currently no strategy to get it running. Since Browse uses xulrunner, it should be possible to use the Firefox version of Gears, with possible modifications. However, I could not find any documentation about XUL/Firefox extensions running on Browse. On a related note, Sebastian Dzillas has done some work on packaging Gears in a .rpm for Firefox. The work is not complete, as the extension tries to write in places owned by root, instead of the local user profile. My project would probably need to be able to move/edit/delete the Gears profile for Journal integration (search your .mozilla default profile for the folder 'Google Gears for Firefox' after installing Gears in Firefox). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
