[Sugar-devel] [Design help] for Webified
I have this project http://wiki.sugarlabs.org/go/Webified, more info at http://honeyweb.sugarlabs.org Right now, I have added the following functionality to my branch of Browse: - new button for creating an SSB - new toolbar for bookmarklet buttons http://en.wikipedia.org/wiki/Bookmarklet - context menu option for adding bookmarklets SSBs would allow users to create customised versions of Browse, for specific web sites. Users could create the GMail activity with just a click and they could customise it with a few more. Bookmarklets are part of the customisation of SSBs. For example, the GMail activity could have bookmarklets like 'compose' or 'enable offline' or 'save drafts to journal' (the latter isn't possible yet). Since bookmarklets are useful in other case as well (http://www.squarefree.com/bookmarklets/), I have decided to give this functionality to Browse as well. I would like to know your opinion, especially if you deal with design. Here are some screenshots of what I have now: http://files.getdropbox.com/u/317039/bookmarklet%20button.png http://files.getdropbox.com/u/317039/create%20ssb.png http://files.getdropbox.com/u/317039/save%20bookmarklet.png ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [Design help] for Webified
Those are screenshots of Browse with some modification. It's not my decision what typefaces are used. Furthermore, we pages can choose fonts on their own (or at least choose between Serif and Sans-Serif). I was looking for some feedback about the extra features added to Browse and their UI. 2009/6/24 Frederick Grose : > On Tue, Jun 23, 2009 at 11:25 PM, Lucian Branescu > wrote: >> >> ... >> >> I would like to know your opinion, especially if you deal with design. >> Here are some screenshots of what I have now: >> http://files.getdropbox.com/u/317039/bookmarklet%20button.png >> http://files.getdropbox.com/u/317039/create%20ssb.png >> http://files.getdropbox.com/u/317039/save%20bookmarklet.png > > Nice work! > Try > setting the default, page typeface to be the same as used in the Browse toolbar. This should unify the two, and make it seem more like an extension. > Thank you for contributing! > --Fred > ___ > 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] I need help for Webified - SSB activity favicons
In case you don't know what Webified is http://wiki.sugarlabs.org/go/Webified http://honeyweb.wordpress.com In short, I have added to Browse the ability to create SSB (http://en.wikipedia.org/wiki/Site-specific_browser) activities. Since I'm generating activities, they need to have icons. After some discussions, I have decided to use a .svg wrapper icon for all SSBs that includes the website favicon. I need to extract the favicon from a website and include it in the .svg icon. Any thoughts? Right now, I'm doing cls = components.classes['@mozilla.org/network/io-service;1'] io_service = cls.getService(interfaces.nsIIOService) ns_uri = io_service.newURI(uri, None, None) cls = components.classes['@mozilla.org/browser/favicon-service;1'] favicon_service = cls.getService(interfaces.nsIFaviconService) favicon_service.getFaviconData(ns_uri) But the last line throws xpcom.Exception: -2147221231. I haven't been able to figure out what that error is. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC] I need help for Webified - SSB activity favicons
I've tried more methods from here https://developer.mozilla.org/en/nsIFaviconService getFaviconImageForPage() and getFaviconLinkForIcon() work and they return URIs to the favicon. However, getFaviconData( getFaviconLinkForIcon() ) still gives an exception. I have looked at the URIs returned by getFaviconImageForPage() and getFaviconLinkForIcon() and they're both the default favicon. This means getFaviconData( getFaviconImageForPage() ) should work, but it still doesn't. It also means that Browse doesn't collect favicons. I could resort to getting /favicon.ico, but it's not very standard and .ico is an annoying format. I would also not account for any tags that may define icons. I was also hoping of using xulrunner's image handling and get the base64 image from it instead of processing an image file. 2009/6/25 Lucian Branescu : > In case you don't know what Webified is > http://wiki.sugarlabs.org/go/Webified http://honeyweb.wordpress.com > > In short, I have added to Browse the ability to create SSB > (http://en.wikipedia.org/wiki/Site-specific_browser) activities. > > Since I'm generating activities, they need to have icons. After some > discussions, I have decided to use a .svg wrapper icon for all SSBs > that includes the website favicon. > > > I need to extract the favicon from a website and include it in the > .svg icon. Any thoughts? > > > Right now, I'm doing > > > cls = components.classes['@mozilla.org/network/io-service;1'] > io_service = cls.getService(interfaces.nsIIOService) > ns_uri = io_service.newURI(uri, None, None) > > cls = components.classes['@mozilla.org/browser/favicon-service;1'] > favicon_service = cls.getService(interfaces.nsIFaviconService) > > favicon_service.getFaviconData(ns_uri) > > > But the last line throws xpcom.Exception: -2147221231. I haven't been > able to figure out what that error is. > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Strawberry VDI, please
Are you sure sound is enabled in the VirtualBox VM setting? It's disabled by default. 2009/6/25 Frederick Grose : > On Thu, Jun 25, 2009 at 4:18 PM, Gary C Martin wrote: >> >> On 25 Jun 2009, at 21:00, Dave Bauer wrote: >> >> > It was creatd witth Virtualbox 2.2.4. I tested on Virtualbox hosts >> > on Linux and Mac OS X. > > I launched it from a Vista32 host, but had no sound in Speak. > > See > http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Getting_Involved/Testing/Soas-strawberry-vdi > > --Fred > > > ___ > 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] [API proposal] toolbox.get_toolbars()
While adding the bookmarklet functionality to Browse, I realised that the toolbox API is hard to work with if your toolbars change. For example, set_current_toolbar() takes the index of the toolbar as a parameter, something which you can't really know if your toolbars move around. Tomeu suggested I propose to extend the toolbox API with a get_toolbars() method. This method returns a list of the actual Toolbar objects, in the order they currently have in the gtk.Notebook. This method allows for things like if toolbar in toolbox.get_toolbars() or toolbar_index = toolbox.get_toolbars().index(toolbar), giving a lot more flexibility in manipulating toolbars. It could also kill off the ugly _TOOLBAR_FOO globals in Browse. I've made toolbox.toolbars a property for get_toolbars(). I have attached a patch to toolbox.py, in the sugar.graphics package. get_toolbars.patch Description: Binary data ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
I have some workarounds in my Browse, it works fine without that patch on 0.84 I haven't tried it on 0.82 yet, but AFAIK Browse 108 doesn't work in 0.82. None of my changes should prevent it from running on 0.82 though, so I should be able to backport them. It's just not something I've tackled yet. 2009/6/30 Benjamin M. Schwartz : > Lucian Branescu wrote: >> I have attached a patch to toolbox.py, in the sugar.graphics package. > > What is your plan for backwards compatibility? Do you intend for your > SSB-enabled Browse to run on 0.84 or 0.82? > > --Ben > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
I have some workarounds in my Browse, it works fine without that patch on 0.84 I haven't tried it on 0.82 yet, but AFAIK Browse 108 doesn't work in 0.82. None of my changes should prevent it from running on 0.82 though, so I should be able to backport them. It's just not something I've tackled yet. 2009/6/30 Benjamin M. Schwartz : > Lucian Branescu wrote: >> I have attached a patch to toolbox.py, in the sugar.graphics package. > > What is your plan for backwards compatibility? Do you intend for your > SSB-enabled Browse to run on 0.84 or 0.82? > > --Ben > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC] I need help for Webified - SSB activity favicons
I've put that on hold for now. It's rather low-impact high-effort when compared to userstyles and userscripts. I'll try downloading the favicon with stuff in nsChannel, but I'm not sure I can embed that in an SVG (especially since gtk's SVG support is very bad). 2009/7/1 Tomeu Vizoso : > On Thu, Jun 25, 2009 at 02:56, Lucian Branescu > wrote: >> In case you don't know what Webified is >> http://wiki.sugarlabs.org/go/Webified http://honeyweb.wordpress.com >> >> In short, I have added to Browse the ability to create SSB >> (http://en.wikipedia.org/wiki/Site-specific_browser) activities. >> >> Since I'm generating activities, they need to have icons. After some >> discussions, I have decided to use a .svg wrapper icon for all SSBs >> that includes the website favicon. >> >> >> I need to extract the favicon from a website and include it in the >> .svg icon. Any thoughts? > > Can SVG images contain bitmaps? Because I guess that most sites will > be using a PNG or GIF. > >> Right now, I'm doing >> >> >> cls = components.classes['@mozilla.org/network/io-service;1'] >> io_service = cls.getService(interfaces.nsIIOService) >> ns_uri = io_service.newURI(uri, None, None) >> >> cls = components.classes['@mozilla.org/browser/favicon-service;1'] >> favicon_service = cls.getService(interfaces.nsIFaviconService) >> >> favicon_service.getFaviconData(ns_uri) >> >> >> But the last line throws xpcom.Exception: -2147221231. I haven't been >> able to figure out what that error is. > > At this point, I would debug the mozilla side of things. It may seems > like a pain, but may actually save you time when compared with trying > things randomly. > > Another option is once you get the URI to download it (see nsChannel > components). > > HTH, > > 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] [API proposal] toolbox.get_toolbars()
Sorry about that. I've attached another patch which follows the guidelines. I'm not sure I should be opening a ticket about this, though. I've had a chat with Walter last night and he said that since the toolbar will get a re-haul in 0.86, it's a chance to improve the API as well. 2009/7/1 Tomeu Vizoso : > On Tue, Jun 30, 2009 at 04:55, Lucian Branescu > wrote: >> While adding the bookmarklet functionality to Browse, I realised that >> the toolbox API is hard to work with if your toolbars change. For >> example, set_current_toolbar() takes the index of the toolbar as a >> parameter, something which you can't really know if your toolbars move >> around. >> >> Tomeu suggested I propose to extend the toolbox API with a >> get_toolbars() method. This method returns a list of the actual >> Toolbar objects, in the order they currently have in the gtk.Notebook. >> This method allows for things like if toolbar in >> toolbox.get_toolbars() or toolbar_index = >> toolbox.get_toolbars().index(toolbar), giving a lot more flexibility >> in manipulating toolbars. >> It could also kill off the ugly _TOOLBAR_FOO globals in Browse. >> >> I've made toolbox.toolbars a property for get_toolbars(). >> >> I have attached a patch to toolbox.py, in the sugar.graphics package. > > Could you please follow > http://wiki.sugarlabs.org/go/Development_Team/CodeReview#Patch_guidelines > ? > > I would also like to hear from the activity team (Gary?) if they have > any objection to this API addition (I would like to see sugar-toolkit > changes being driven by them at some point in the future). > > Thanks! > > Tomeu > >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> >> > get_toolbars.patch Description: Binary data ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: REVU: [ubuntu/karmic] gears 0.5.21.0~svn3334+dfsg-0ubuntu1 (New)
I'll try and see if it works/I can backport it to an older ubuntu (my jhbuild runs on a ubuntu in a VM). I don't think alien is a long term solution. Very interesting, thanks. 2009/7/2 David Van Assche : > interesting gears now .debbed for ubuntu guess alien might be > enough to make the rpm? > > D > > > -- Forwarded message -- > From: Stefan Lesicnik > Date: Wed, Jul 1, 2009 at 2:19 PM > Subject: Re: REVU: [ubuntu/karmic] gears 0.5.21.0~svn3334+dfsg-0ubuntu1 (New) > To: Siegfried Gevatter > Cc: Ubuntu-MOTU Mailing list > > > On Wed, Jul 1, 2009 at 2:09 PM, Siegfried Gevatter wrote: >> -- Forwarded message -- >> From: Ubuntu Installer >> Date: 2009/7/1 >> Subject: [ubuntu/karmic] gears 0.5.21.0~svn3334+dfsg-0ubuntu1 (New) >> To: Siegfried Gevatter , MOTU >> , Stefan Lesicnik >> >> >> NEW: gears_0.5.21.0~svn3334+dfsg.orig.tar.gz >> NEW: gears_0.5.21.0~svn3334+dfsg-0ubuntu1.diff.gz >> NEW: gears_0.5.21.0~svn3334+dfsg-0ubuntu1.dsc >> >> gears (0.5.21.0~svn3334+dfsg-0ubuntu1) karmic; urgency=low >> >> * Initial release (LP: #244245). > > Hey! Just to let everyone know, this works for x86 & amd64! Gears > from the .xpi from the website doesn't support 64! It also works with > Prism. I am pretty sure we are the first distribution to include gears > in our repo. > > At the moment, Firefox 3.5 is not supported. - As soon as upstream > releases code that starts to work, I will update this. > > Stefan > > -- > Ubuntu-motu mailing list > ubuntu-m...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu > ___ > 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] Gecko for Win32, pyjamas-desktop, python-hulahop
2) That was my backup proposal in fact, and I ended up getting accepted with this one http://wiki.sugarlabs.org/go/Webified I'd still like to make browse Browse able to use webkit (and preferably to be able to switch between webkit and gecko), but that's for after GSoC. I'll probably love that wrapper script :) 2009/7/3 Luke Kenneth Casson Leighton : > folks, hi, just wanted to mention a couple of things that i found. > > 1) you'll be pleased to know that i managed to hack pyjamas-desktop > into submission to use python-hulahop, at europython over the last > couple of days. i managed to get window event listeners going, > element listeners _and_ XMLHTTPRequest async callbacks - all > python-based. none of which would be possible without > hulahop.WebView. so - thank you. > > 2) i found a page yesterday of a GSoc 2009 student who was proposing > to port hulahop to webkit. i put on the "talk" page that of course > because pywebkitgtk now has python bindings to the DOM that most of > the work is now done and so his task will be made much easier. that's > if GSoc 2009 is still going. or if his proposal was accepted. > anyway, just mentioning it. > > 3) the next step is of course to have python-hulahop running on win32, > alongside python-xpcom, yippee, won't that be fun. so, looking around > for xulrunner for win32, i find that the olpc page says "Install > Gecko: TODO" ha :) so anyway i found this: > http://www.novell.com/coolsolutions/feature/14918.html which may > contain the stuff that's needed. i.e. GRE (gecko runtime environment). > i mean, after all, firefox compiles for win32 duh so it should be > perfectly possible to get XUL and python-xpcom, right? h :) > > 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
Re: [Sugar-devel] Gecko for Win32, pyjamas-desktop, python-hulahop
I'm afraid you misread my proposal. I'm making a SSB for sugar, akin to Fluid (http://fluidapp.com) and Mozilla Prism. This would allow web applications to work nicely in Sugar as separate activities (applications). Stuff like userstyles, userscripts, bookmarklets-as-buttons and javascript-dbus can greatly enhance the Sugar integration, making web apps seem even more like native activities. In fact I should stop using 'would', because creating SSBs works! Userstyles and userscripts will come soon. In general, people are trying to get web stuff to work nicely in Sugar (see http://blog.tomeuvizoso.net/2009/05/progress-on-sugar-activities-with-swf.html and http://karmaproject.wordpress.com/), not the other way around. Mostly because loads more people know flash/html+js than Python. Of course, efforts going the other way are more than welcome, but they have less impact in the short term. 2009/7/3 Luke Kenneth Casson Leighton : > On 7/3/09, Lucian Branescu wrote: >> 2) That was my backup proposal in fact, and I ended up getting >> accepted with this one http://wiki.sugarlabs.org/go/Webified > > ooo. ah. take a look at pygtkweb (in pyjamas) and note that luis > pamirez solved the "import " problem by using JSONRPC > exactly as you outline. > > however what he did was provide a way to run pygtk apps in a web > browser (unmodified) and i'm not quite sure that that's the same thing > that you're proposing in Webified but i'm sure there's quite a lot > of crossover. > > luis only had about 8 weeks so he only got up to rangewidgets.py pygtk > example, which is still a heck of a long way. > > but - the principle, it shows that it's perfectly possible to port a > python-based Widget GUI API to run in web browsers, using the pyjamas > compiler. > > much of luis' work was to improve the pyjs compiler at the time: if > what you are proposing is to port the Sugar GUI API to the web then, > because luis already created browser.py and also because pyjs compiler > is much more mature, you should get a heck of a long way further. > > plus, because Sugar GUI still relies on pygtk in a lot of places you > can leverage his work. > > ... that's if i have translated your proposal correctly as being "make > Sugar apps run (unmodified) in web browsers". > > if you decide not to go "generic web browser" and instead decide to go > "browser engine" e.g. pywebkitgtk or e.g. > gecko/xul/python-xpcom/hulahop then you should definitely look at > pyjamas-desktop and _still_ look at making luis pygtkweb work run in > pyjamas-desktop! > > yes, i know - that's a port of gtk to pyjamas where pyjamas runs on > top of gtk. crazy idea but it's because pyjamas API is an abstraction > layer where one of the lower layers _happens_ to be gtk at the moment. > > so, lots of options and opportunities. > >> I'd still like to make browse Browse able to use webkit (and >> preferably to be able to switch between webkit and gecko), but that's >> for after GSoC. I'll probably love that wrapper script :) > > yehh - take a look in pyjamas at pyjd/pywebkitgtk.py and also in > pyjd/hula.py they are near-identical. a wrapper (submitted as a patch > to pywebkitgtk, #13) wraps the [stupid] glib/gobject naming convention > making it look like proper W3C DOM functions and thus near-identical > to xpcom. > > so in that way you are independent of the underlying DOM technology. > unfortunately, python-khtml is broken (c++ RTTI related bug and a bug > in kde's twine python-c++ auto-generator) but if it wasn't it could be > added as the third option. macos pyobjc is the fourth option to be > considered. > > in this way, you can see that if Sugar apps are based on DOM > technology (indirectly) you have maaany more options. and if you look > at the list of dependencies to e.g. get python-hulahop compiled for > Win32, you _really_ want to open up the options much much more, by > making Sugar apps run in web browsers and on web engine technology, > rather than try to hit heads against brick walls compiling xulrunner, > python-xpcom 40mb downloads on windows ICK! :) > > l. > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
I recently looked over sugar-port source, and I found this http://people.sugarlabs.org/~alsroot/sugar-port/ It's equivalent to my patch, but is slightly less readable. 2009/7/1 Tomeu Vizoso : > On Wed, Jul 1, 2009 at 15:18, Lucian Branescu > wrote: >> Sorry about that. I've attached another patch which follows the guidelines. >> >> I'm not sure I should be opening a ticket about this, though. I've had >> a chat with Walter last night and he said that since the toolbar will >> get a re-haul in 0.86, it's a chance to improve the API as well. > > If we really manage to implement that feature for 0.86 (the design is > not agreed on as of yet), the API will have to be a separate addition > because we'll need to keep both the old tabs-based toolbox and the new > one as not all activities will be able to move to the new one at the > same time. > > That said, your patch seems clean enough to be added now and the fact > this API is going to get deprecated makes it easier to add API to it. > > Regards, > > Tomeu > >> 2009/7/1 Tomeu Vizoso : >>> On Tue, Jun 30, 2009 at 04:55, Lucian Branescu >>> wrote: >>>> While adding the bookmarklet functionality to Browse, I realised that >>>> the toolbox API is hard to work with if your toolbars change. For >>>> example, set_current_toolbar() takes the index of the toolbar as a >>>> parameter, something which you can't really know if your toolbars move >>>> around. >>>> >>>> Tomeu suggested I propose to extend the toolbox API with a >>>> get_toolbars() method. This method returns a list of the actual >>>> Toolbar objects, in the order they currently have in the gtk.Notebook. >>>> This method allows for things like if toolbar in >>>> toolbox.get_toolbars() or toolbar_index = >>>> toolbox.get_toolbars().index(toolbar), giving a lot more flexibility >>>> in manipulating toolbars. >>>> It could also kill off the ugly _TOOLBAR_FOO globals in Browse. >>>> >>>> I've made toolbox.toolbars a property for get_toolbars(). >>>> >>>> I have attached a patch to toolbox.py, in the sugar.graphics package. >>> >>> Could you please follow >>> http://wiki.sugarlabs.org/go/Development_Team/CodeReview#Patch_guidelines >>> ? >>> >>> I would also like to hear from the activity team (Gary?) if they have >>> any objection to this API addition (I would like to see sugar-toolkit >>> changes being driven by them at some point in the future). >>> >>> 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] [API proposal] toolbox.get_toolbars()
I didn't realise the docs didn't use a get url. Look for ActivityToolbox.get_bars in the activity module. 2009/7/4 Lucian Branescu : > I recently looked over sugar-port source, and I found this > http://people.sugarlabs.org/~alsroot/sugar-port/ > > It's equivalent to my patch, but is slightly less readable. > > 2009/7/1 Tomeu Vizoso : >> On Wed, Jul 1, 2009 at 15:18, Lucian Branescu >> wrote: >>> Sorry about that. I've attached another patch which follows the guidelines. >>> >>> I'm not sure I should be opening a ticket about this, though. I've had >>> a chat with Walter last night and he said that since the toolbar will >>> get a re-haul in 0.86, it's a chance to improve the API as well. >> >> If we really manage to implement that feature for 0.86 (the design is >> not agreed on as of yet), the API will have to be a separate addition >> because we'll need to keep both the old tabs-based toolbox and the new >> one as not all activities will be able to move to the new one at the >> same time. >> >> That said, your patch seems clean enough to be added now and the fact >> this API is going to get deprecated makes it easier to add API to it. >> >> Regards, >> >> Tomeu >> >>> 2009/7/1 Tomeu Vizoso : >>>> On Tue, Jun 30, 2009 at 04:55, Lucian Branescu >>>> wrote: >>>>> While adding the bookmarklet functionality to Browse, I realised that >>>>> the toolbox API is hard to work with if your toolbars change. For >>>>> example, set_current_toolbar() takes the index of the toolbar as a >>>>> parameter, something which you can't really know if your toolbars move >>>>> around. >>>>> >>>>> Tomeu suggested I propose to extend the toolbox API with a >>>>> get_toolbars() method. This method returns a list of the actual >>>>> Toolbar objects, in the order they currently have in the gtk.Notebook. >>>>> This method allows for things like if toolbar in >>>>> toolbox.get_toolbars() or toolbar_index = >>>>> toolbox.get_toolbars().index(toolbar), giving a lot more flexibility >>>>> in manipulating toolbars. >>>>> It could also kill off the ugly _TOOLBAR_FOO globals in Browse. >>>>> >>>>> I've made toolbox.toolbars a property for get_toolbars(). >>>>> >>>>> I have attached a patch to toolbox.py, in the sugar.graphics package. >>>> >>>> Could you please follow >>>> http://wiki.sugarlabs.org/go/Development_Team/CodeReview#Patch_guidelines >>>> ? >>>> >>>> I would also like to hear from the activity team (Gary?) if they have >>>> any objection to this API addition (I would like to see sugar-toolkit >>>> changes being driven by them at some point in the future). >>>> >>>> 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] Good filesystem for USB flash with compression?
USB flash drives have controllers that do wear-leveling. They try really hard to make them look like hard drives. JFFS2 works on raw flash, so it's not useful. Basically any FS that works on all the OSes you need. ext2 is a good option. NTFS might be, but it's fiddly. I've tried to get a UDF filesystem on a flash once, since UDF is supported on any OS, but I didn't get too far. Also, windows doesn't seem to have support for the 'hard-drive' UDF profile. 2009/7/7 Luke Faraone : > Hi all, > > I noticed a problem when attempting to unsquash the SoaS filesystem and > extract it on to a flashdrive: it's over 1.2GiB. > > Since squashfs is read-only, is there a good read-write filesystem that > achieves decent compression (while not carrying too steep a speed penalty on > older systems) that is reasonable to use on a USB flash drive? > > JFFS2 won't work, from what I've heard. Are there any other well-developed > alternatives? > > -- > 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] Good filesystem for USB flash with compression?
Sorry, I should've read the question more carefully. Perhaps JFFS2 works on USB flash after all? Besides btrfs which is very primitive ATM, I don't know other compressed FSs. 2009/7/7 Luke Faraone : > On Mon, Jul 6, 2009 at 21:00, Lucian Branescu > wrote: >> >> Basically any FS that works on all the OSes you need. ext2 is a good >> option. NTFS might be, but it's fiddly. > > I don't really care about compatibility, rather I need something that will > work on Linux systems, and something with compression. > > > > -- > Luke Faraone > http://luke.faraone.cc > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] css selector
jQuery uses Sizzle, which uses native selectors whenever it can. You can see in that graph the green bar (jQuery 1.2.7 experimental) is only a sliver slower than native selectors, when available. Even without native selectors, Sizzle is very fast and I doubt it'll be a bottleneck for you. If I were you, I'd stick to jQuery or use Sizzle directly if jQuery is inappropriate for some other reason. 2009/7/9 Bryan Berry : > for our code, i would prefer to use jquery selectors, it will make our > code a lot more portable > > Also, for the purpose of getting translation strings, speed not so > important. > > > On Thu, 2009-07-09 at 01:53 -0500, Felipe López Toledo wrote: >> Hi Byan. >> >> Since I'm printing everything that seems useful, I found this: >> http://hacks.mozilla.org/2009/06/dom-selectors-api/ >> >> summary: native css selectors are faster than other css selectors >> >> maybe it's not important.. but (for a moment) I was thinking jQuery >> css selector vs native css selectors: what do we must use? >> >> 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] Initial implementation of toolbars design
b) About the API, I would like to stress the need for ways to (more) easily remove and add toolbars/toolbar items at runtime. 2009/7/11 Simon Schampijer : > On 07/11/2009 03:44 AM, Gary C Martin wrote: >> Hi Aleksey, >> >> On 10 Jul 2009, at 16:19, Aleksey Lim wrote: >> >>> Hi all, >>> >>> http://git.sugarlabs.org/projects/sugar-toolkit/repos/toolbars >>> there is simle example in examples/toolbar.py >>> >>> Does it satisfy mockups? >> >> Sugar-jhbuild is broken for me just now so can't look/test :-( Is this >> toolbar example work for the Journal, Browse (tabs treatment), or the >> main system wide Sugar toolbars (BTW: I'm making some new mock-ups of >> them just now)? > > for reference: http://wiki.sugarlabs.org/go/Features/New_Toolbar_Design > eben's mockups: http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars > > I had a brief look at the code. Looks like a great start and proof of > concept. What I think we should do now is (in the order): > > a) DESIGN: discuss the design further and get some mockups together, one > question that came up is: do we always have a one line secondary tool > bar? How would more complex widgets like the color chooser look like > http://wiki.sugarlabs.org/go/File:ColorToolButton.png ? Or would they > open from the secondary palette? Maybe we should step through some of > the activities and just remodel them to see what would work and find out > about the edge cases (think gary is already working on that) > > b) API: we need a rock solid API. This is public API and will be used by > all the activity authors, so very important to get this right - so we do > not need to change it again afterwards > > c) IMPLEMENTATION: we have the proof of concept, we should check if we > would be easier to create a custom widget, see what parts can be moved > to the theme so we do not have to work around issues in the code > > Sounds good? Comments? > > 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] Initial implementation of toolbars design
I meant something like Toolbox.get_toolbars() and/or Toolbox.get_toolbar(name:str), so you can easily identify a toolbar, or check how many toolbars they are and so on. I don't know how that fits in the new API, that's why I didn't specify details. 2009/7/11 Aleksey Lim : > On Sat, Jul 11, 2009 at 10:49:21AM +0100, Lucian Branescu wrote: >> b) About the API, I would like to stress the need for ways to (more) >> easily remove and add toolbars/toolbar items at runtime. > > Usage of new sugar.graphics.Toolbar is clean in that case, > there are just another tool button - sugar.graphics.ToolbarButton > just another gtk.Toolbar in sugar.graphics.Toolbars.top property > so, you a free to invoke all gtk.Toolbar methods for 'top' property > including adding/removing ToolbarButton buttons. > > -- > Aleksey > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] reading and writing translatable strings
Searching strings inside all HTML elements could be very slow. I
suggest if you search inside html elements, stick to a predefined list
of them (like a "translate" class).
2009/7/12 Bryan Berry :
> Subzero,
>
> I have figured out how to read the strings from an html file, at least
> somewhat:
>
> utils/narwhal/bin/narwhal source.html output.pot
>
> generates a .pot file from the strings in one html file
>
> I haven't automated grabbing the strings from a .js file because it
> seems fairly straightforward.
>
> Reading back in the strings from the po might present a problem. I
> gather that we will have to convert the po file to a .json file
>
> I guess we can use the perl module po2json for now
> (http://jsgettext.berlios.de/doc/html/po2json.html) Later we may want to
> consider doing this w/ python or narwhal (command-line js), since
> neither u nor I know perl.
>
> but we still have to match the strings w/ the target html.
>
> It was dead easy to grab the strings using a css selector $('h1, h2, h3,
> title, ...')
>
> but to write back the strings we need to match the msgid string to the
> actual element html. Can we create a jQuery css or XPath selector that
> selects based on element html? something like
>
> $('*[html="The Highest score is"]'). ???
>
> I am wondering if it will be feasible performance-wise to write in all
> the strings each time the page loads. I guess the only way to find out
> is to experiment.
>
> We could possibly pre-create localized html pages using narwhal. We
> could use the package_po.json to generate index_ne_NP.html or
> index_he.html from the command-line.
>
>
> --
> 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] [API proposal] Source editor and widget
I'm proposing the addition of sugar.graphics.sourceedit.SourceView. It would be similar to what can be found in jarabe.view.viewsource. Exact names of classes and/or module are up for debate. I'm also thinking of adding a FileView class in there, but I'm not sure about it. I've already seen almost the exact same code in Pippy and viewsource.py; now I'm writing almost the same code in my branch of Browse and it could be a base for the proposed Clipboard text editor (http://wiki.sugarlabs.org/go/Features/Edit-panel-on-Frame). Thus, I believe it's a common enough need. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] Source editor and widget
I've attached a file with a SourceView class.
I'll try to write up a FilesView class as well, since 3 of the 4
aforementioned use cases do something like this.
2009/7/13 Tomeu Vizoso :
> On Mon, Jul 13, 2009 at 18:09, Lucian Branescu
> wrote:
>> I'm proposing the addition of sugar.graphics.sourceedit.SourceView. It
>> would be similar to what can be found in jarabe.view.viewsource. Exact
>> names of classes and/or module are up for debate.
>
> May be better if you first code your new stuff and then we discuss
> about merging it in the sugar-toolkit? viewsource.py doesn't add too
> much around gtksourceview2.View itself, so you may end up with more
> differences than similarities with viewsource.py.
>
> Regards,
>
> Tomeu
>
>> I'm also thinking of adding a FileView class in there, but I'm not
>> sure about it.
>>
>>
>> I've already seen almost the exact same code in Pippy and
>> viewsource.py; now I'm writing almost the same code in my branch of
>> Browse and it could be a base for the proposed Clipboard text editor
>> (http://wiki.sugarlabs.org/go/Features/Edit-panel-on-Frame). Thus, I
>> believe it's a common enough need.
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
import os
import mime
import gobject
import pango
import gtk
import gtksourceview2
from sugar.activity import activity
from sugar.graphics import style
from sugar.graphics.icon import Icon
class SourceView(gtk.ScrolledWindow):
'''TextView-like widget with syntax coloring and scroll bars
Much of the initialisation code if from Pippy'''
__gtype_name__ = 'SugarSourceView'
def __init__(self, syntax_color=True, width=None, height=None):
gtk.ScrolledWindow.__init__(self)
self.set_policy(gtk.POLICY_AUTOMATIC, gtk.POLICY_AUTOMATIC)
self.mime_type = mime_type
self.width = width or int(gtk.gdk.screen_width()/2)
self.height = height or int(gtk.gdk.screen_height()/1.5)
self._file_path = None
# buffer
self._buffer = gtksourceview2.Buffer()
if syntax_color:
if hasattr(self._buffer, 'set_highlight'):
self._buffer.set_highlight(True)
else:
self._buffer.set_highlight_syntax(True)
# editor view
self._view = gtksourceview2.View(self._buffer)
self._view.set_size_request(self.width, self.height)
self._view.set_editable(True)
self._view.set_cursor_visible(True)
self._view.set_show_line_numbers(True)
self._view.set_wrap_mode(gtk.WRAP_CHAR)
self._source_view.set_right_margin_position(80)
#self._source_view.set_highlight_current_line(True) #FIXME: Ugly color
self._view.set_auto_indent(True)
self._view.modify_font(pango.FontDescription("Monospace " +
str(style.FONT_SIZE)))
self._source_view.modify_font(_SOURCE_FONT)
self.add(self._view)
self.show_all()
def set_mime_type(self, mime_type):
lang_manager = gtksourceview2.language_manager_get_default()
if hasattr(lang_manager, 'list_languages'):
langs = lang_manager.list_languages()
else:
lang_ids = lang_manager.get_language_ids()
langs = [lang_manager.get_language(lang_id)
for lang_id in lang_ids]
for lang in langs:
for m in lang.get_mime_types():
if m == mime_type:
self._buffer.set_language(lang)
def get_text(self):
end = self._buffer.get_end_iter()
start = self._buffer.get_start_iter()
return self._buffer.get_text(start, end)
def set_text(self, text):
self._buffer.set_text(text)
text = property(get_text, set_text)
def _set_file_path(self, file_path):
if file_path == self._file_path:
return
else:
self._file_path = file_path
if self._file_path is None:
self.text = ''
return
mime_type = mime.get_for_file(self._file_path)
self.set_mime_type(mime_type)
self.text = open(self._file_path, 'r').read()
def _get_file_path(self):
return self._file_path
file_path = property(_get_file_path, _set_file_path)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Request to add webkitgtk as a external dependency
Many people report WebKit to be faster and my own benchmarks seem to confirm that. I think it would be great if there were some browser API for activities that could use both hulahop and pywebkitgtk. This way, the best overall engine at the time can be used. 2009/7/15 Bryan Berry : > On Tue, 2009-07-14 at 23:41 +0530, Sayamindu Dasgupta wrote: >> I initially tried out whatever I wanted to do with Gecko, however, it >> looks like performance can be degraded quite a bit with larger books. >> To ensure proper pagination (the current form of Read depends on the >> document being properly and consistently broken up into pages), I need >> to pre-render the entire book beforehands to get an idea of the >> dimensions (under a predefined set of graphics settings, so that the >> dimensions come out in a device/screen independent manner). However, >> with large books like War and Peace (which consists of more than 350 >> XHTML files), the basic pre-rendering code takes around 18 seconds >> with Gecko (using Hulahop) and around 2 seconds with Webkit. This is >> on my desktop machine - I did not try the comparison on an XO-1. All >> the pages are quite simple, with no images, and minimalistic >> formatting. > > I side w/ Sayamindu on this. Rendering native texts in a reasonable > amount of time is really important for a lot of parts of the world. I > can certainly say it is for South Asia. If webkit speeds up rendering of > indic scripts by a factor of 9, then it is worth having two browser > engines IMHO. > >> WebkitGTK seems to fast gaining acceptance among application >> developers > > I see the same. > > -- > 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] [API proposal] Source editor and widget
I'm proposing the addition of a general widget that could be used in many places(Pippy, View Source, my Browse branch). In fact, it is partly based on View Source code. I figured it would be a good idea to not have all this code duplication. For my project's needs (editing Userstyles and Userscripts), I could use View Source, but besides being read-only, it also can only open one document from the activity. I would want Browse's view source to show the loaded html, one user stylesheed and a folder of userscripts. Only things in the 'document' view would be editable, not in the 'bundle' view. 2009/7/15 Simon Schampijer : > On 07/13/2009 06:09 PM, Lucian Branescu wrote: >> >> I'm proposing the addition of sugar.graphics.sourceedit.SourceView. It >> would be similar to what can be found in jarabe.view.viewsource. Exact >> names of classes and/or module are up for debate. >> >> I'm also thinking of adding a FileView class in there, but I'm not >> sure about it. >> >> >> I've already seen almost the exact same code in Pippy and >> viewsource.py; now I'm writing almost the same code in my branch of >> Browse and it could be a base for the proposed Clipboard text editor >> (http://wiki.sugarlabs.org/go/Features/Edit-panel-on-Frame). Thus, I >> believe it's a common enough need. > > Hi Lucian, > > I have seen your feature request. Did you consider using the view source > dialog and adding the save functionality there? > http://dev.sugarlabs.org/ticket/803#comment:3 > > At least that was an obvious place to add such functionality for me. > > Regards, > Simon > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] Source editor and widget
Alright then. I'm unfamiliar with policies about code duplication in sugar and activity code. If duplication is ok, then my proposal is moot :) Ignore and move along. 2009/7/15 Tomeu Vizoso : > On Mon, Jul 13, 2009 at 19:09, Lucian Branescu > wrote: >> I've attached a file with a SourceView class. > > I'm still a bit unsure about the convenience of adding this code to > sugar-toolkit. It's quite trivial code and the API we add to > sugar-toolkit should be more or less stable (though we aren't yet > promising a stable API). > > The code you are attaching basically preconfigures gtk.SourceView2 and > adds a little bit of code to set the language. Maybe this would be > more appropriate as a snippet in the Sugar Almanac? > > http://wiki.sugarlabs.org/go/Development_Team/Almanac > > Regards, > > Tomeu > >> I'll try to write up a FilesView class as well, since 3 of the 4 >> aforementioned use cases do something like this. >> >> 2009/7/13 Tomeu Vizoso : >>> On Mon, Jul 13, 2009 at 18:09, Lucian Branescu >>> wrote: >>>> I'm proposing the addition of sugar.graphics.sourceedit.SourceView. It >>>> would be similar to what can be found in jarabe.view.viewsource. Exact >>>> names of classes and/or module are up for debate. >>> >>> May be better if you first code your new stuff and then we discuss >>> about merging it in the sugar-toolkit? viewsource.py doesn't add too >>> much around gtksourceview2.View itself, so you may end up with more >>> differences than similarities with viewsource.py. >>> >>> Regards, >>> >>> Tomeu >>> >>>> I'm also thinking of adding a FileView class in there, but I'm not >>>> sure about it. >>>> >>>> >>>> I've already seen almost the exact same code in Pippy and >>>> viewsource.py; now I'm writing almost the same code in my branch of >>>> Browse and it could be a base for the proposed Clipboard text editor >>>> (http://wiki.sugarlabs.org/go/Features/Edit-panel-on-Frame). Thus, I >>>> believe it's a common enough need. >>>> ___ >>>> 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] [API proposal] Source editor and widget
Sure, I'll put it on the wiki, then. About editing userscripts, I'll resort to overriding the default View Source, at least for now. 2009/7/15 Tomeu Vizoso : > On Wed, Jul 15, 2009 at 17:09, Lucian Branescu > wrote: >> Alright then. I'm unfamiliar with policies about code duplication in >> sugar and activity code. If duplication is ok, then my proposal is >> moot :) Ignore and move along. > > Is not ok, it's bad, but avoiding code duplication has a cost that > needs to be taken into account. Worst than simple code duplication is > duplication of logic and also inefficient learning efforts. > > In the code you attached I don't see any logic complex enough, but I > see how someone not familiar yet with gtk.SourceView2 could spend lots > of time getting the desired configuration, that's why I suggested the > Almanac instead. > > Regards, > > Tomeu > >> 2009/7/15 Tomeu Vizoso : >>> On Mon, Jul 13, 2009 at 19:09, Lucian Branescu >>> wrote: >>>> I've attached a file with a SourceView class. >>> >>> I'm still a bit unsure about the convenience of adding this code to >>> sugar-toolkit. It's quite trivial code and the API we add to >>> sugar-toolkit should be more or less stable (though we aren't yet >>> promising a stable API). >>> >>> The code you are attaching basically preconfigures gtk.SourceView2 and >>> adds a little bit of code to set the language. Maybe this would be >>> more appropriate as a snippet in the Sugar Almanac? >>> >>> http://wiki.sugarlabs.org/go/Development_Team/Almanac >>> >>> Regards, >>> >>> Tomeu >>> >>>> I'll try to write up a FilesView class as well, since 3 of the 4 >>>> aforementioned use cases do something like this. >>>> >>>> 2009/7/13 Tomeu Vizoso : >>>>> On Mon, Jul 13, 2009 at 18:09, Lucian Branescu >>>>> wrote: >>>>>> I'm proposing the addition of sugar.graphics.sourceedit.SourceView. It >>>>>> would be similar to what can be found in jarabe.view.viewsource. Exact >>>>>> names of classes and/or module are up for debate. >>>>> >>>>> May be better if you first code your new stuff and then we discuss >>>>> about merging it in the sugar-toolkit? viewsource.py doesn't add too >>>>> much around gtksourceview2.View itself, so you may end up with more >>>>> differences than similarities with viewsource.py. >>>>> >>>>> Regards, >>>>> >>>>> Tomeu >>>>> >>>>>> I'm also thinking of adding a FileView class in there, but I'm not >>>>>> sure about it. >>>>>> >>>>>> >>>>>> I've already seen almost the exact same code in Pippy and >>>>>> viewsource.py; now I'm writing almost the same code in my branch of >>>>>> Browse and it could be a base for the proposed Clipboard text editor >>>>>> (http://wiki.sugarlabs.org/go/Features/Edit-panel-on-Frame). Thus, I >>>>>> believe it's a common enough need. >>>>>> ___ >>>>>> 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] [API proposal] Source editor and widget
Here it is http://wiki.sugarlabs.org/go/Development_Team/Almanac#How_do_I_create_a_text_box_for_code_editing.3F 2009/7/15 Lucian Branescu : > Sure, I'll put it on the wiki, then. > > About editing userscripts, I'll resort to overriding the default View > Source, at least for now. > > 2009/7/15 Tomeu Vizoso : >> On Wed, Jul 15, 2009 at 17:09, Lucian Branescu >> wrote: >>> Alright then. I'm unfamiliar with policies about code duplication in >>> sugar and activity code. If duplication is ok, then my proposal is >>> moot :) Ignore and move along. >> >> Is not ok, it's bad, but avoiding code duplication has a cost that >> needs to be taken into account. Worst than simple code duplication is >> duplication of logic and also inefficient learning efforts. >> >> In the code you attached I don't see any logic complex enough, but I >> see how someone not familiar yet with gtk.SourceView2 could spend lots >> of time getting the desired configuration, that's why I suggested the >> Almanac instead. >> >> Regards, >> >> Tomeu >> >>> 2009/7/15 Tomeu Vizoso : >>>> On Mon, Jul 13, 2009 at 19:09, Lucian Branescu >>>> wrote: >>>>> I've attached a file with a SourceView class. >>>> >>>> I'm still a bit unsure about the convenience of adding this code to >>>> sugar-toolkit. It's quite trivial code and the API we add to >>>> sugar-toolkit should be more or less stable (though we aren't yet >>>> promising a stable API). >>>> >>>> The code you are attaching basically preconfigures gtk.SourceView2 and >>>> adds a little bit of code to set the language. Maybe this would be >>>> more appropriate as a snippet in the Sugar Almanac? >>>> >>>> http://wiki.sugarlabs.org/go/Development_Team/Almanac >>>> >>>> Regards, >>>> >>>> Tomeu >>>> >>>>> I'll try to write up a FilesView class as well, since 3 of the 4 >>>>> aforementioned use cases do something like this. >>>>> >>>>> 2009/7/13 Tomeu Vizoso : >>>>>> On Mon, Jul 13, 2009 at 18:09, Lucian >>>>>> Branescu wrote: >>>>>>> I'm proposing the addition of sugar.graphics.sourceedit.SourceView. It >>>>>>> would be similar to what can be found in jarabe.view.viewsource. Exact >>>>>>> names of classes and/or module are up for debate. >>>>>> >>>>>> May be better if you first code your new stuff and then we discuss >>>>>> about merging it in the sugar-toolkit? viewsource.py doesn't add too >>>>>> much around gtksourceview2.View itself, so you may end up with more >>>>>> differences than similarities with viewsource.py. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Tomeu >>>>>> >>>>>>> I'm also thinking of adding a FileView class in there, but I'm not >>>>>>> sure about it. >>>>>>> >>>>>>> >>>>>>> I've already seen almost the exact same code in Pippy and >>>>>>> viewsource.py; now I'm writing almost the same code in my branch of >>>>>>> Browse and it could be a base for the proposed Clipboard text editor >>>>>>> (http://wiki.sugarlabs.org/go/Features/Edit-panel-on-Frame). Thus, I >>>>>>> believe it's a common enough need. >>>>>>> ___ >>>>>>> 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] best way to localize audio and image files?
I'd go for option 1) until Pootle sound is done, it makes sense to me.
Translate the english filename (sound.ogg) to the french filename
(sound-fr.ogg)
2009/7/16 Bryan Berry :
> done!
> http://wiki.sugarlabs.org/go/Development_Team/Sound#Crowdsourcing_Audio_and_Image_Localization
> On Thu, 2009-07-16 at 14:16 +0200, David Schönstein wrote:
>> Hi Byran,
>>
>> Any chance of taking a couple of minutes to throw your question and
>> proposed solution up on the Sugar Sound wiki?
>>
>> http://wiki.sugarlabs.org/go/Development_Team/Sound
>>
>> That way I can try ask around me and get some feedback from people
>> from inside and outside the Sugar community.
>>
>> Thanks a lot.
>>
>> David
>>
>> 2009/7/16 David Schönstein
>> Hi Byran,
>>
>> Any chance of taking
>>
>> 2009/7/16 Bryan Berry
>>
>>
>> Sayamindu,
>>
>> I need your thoughts on the matter of localizing audio
>> files and image
>> files.
>>
>> I have two strategies in mind:
>>
>> 1) Integrate w/ pootle
>> 2) Not integrated w/ pootle
>>
>> 1) Integrate w/ pootle.
>>
>> When I grab the translatable strings from my files I
>> also grab the
>> filenames of the audio and image files and stick the
>> value of the src=""
>> attribute into in the .po as the msgid
>> for example:
>>
>> >> index.html
>>
>>
>>
>>
>>
>> >> karma.pot
>>
>> msgid "./images/house.png"
>> msgstr ""
>>
>> msgid "./sounds/yes.ogg"
>> msgstr ""
>>
>> >> ne-NP.po
>>
>> msgid "./images/house.png"
>> msgstr "./images/ne-NP_house.png"
>>
>> msgid "./sounds/yes.ogg"
>> msgstr "./sounds/ne-NP_yes.ogg"
>>
>> >> es-SP.po
>>
>> msgid "./images/house.png"
>> msgstr "./images/es-SP_house.png"
>>
>> msgid "./sounds/yes.ogg"
>> msgstr "./sounds/es-SP_yes.ogg"
>>
>>
>> Then to load the localized strings, I simply use a
>> jQuery CSS selector
>> to write the translated strings into the markup at
>> page load.
>>
>> the code is basically:
>>
>> var localeStrings = load('pofile_converted_to.json');
>>
>> for (var msgid in localeStrings){
>> //if an element matches the msgid, replace it
>> with the msgstr
>> if (msgid.tagName === img or audio){
>> $(:contains(msgid)).attr('src',
>> localeStrings[msgid]);
>> }
>> else {
>>
>> $(:contains(msgid)).html(localeStrings[msgid]);
>> }
>> }
>>
>> Using the .po file for everything that can be
>> localized makes everything
>> nice and consistent
>>
>> That said, the whole point of putting stuff in .po
>> files is that u can
>> input the translated value directly into the .po with
>> a text editor or
>> the pootle interface. Going to all this trouble when
>> pootle doesn't let
>> u upload audio and image files seems a bit of a waste.
>>
>>
>> 2) Orrr, I could just check for images and sounds that
>> are prefixed w/
>> the current locale at run-time and load them.
>>
>> The problem with this it doesn't give us any
>> forward-compatibility if we
>> get pootle or find another solution to support
>> crowd-sourcing
>> translation of audio and image assets.
>>
>> Your thoughts are most appreciated.
>>
>> --
>> 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
>>
>>
>>
>> --
>>
>> "The intuitive mind is a sacred gift and the rational mind is
>> a faithful servant.
>> We have created a society that honours the servant and has
>> forgotten the gift." Albert Einstein
>>
>>
>> David Schönstein
>> Arkamys
>> LIMSI-CNRS Thésard CIFRE
>> Groupe Audio Acoustique
>> Portable (Mobile Phone): +33 (0)6 88 49 95 75
>> www.li
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
[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
