Re: [Sugar-devel] HTML5 video in Browse
On Tue, Jan 18, 2011 at 1:15 AM, Bernie Innocenti ber...@codewiz.org wrote: On Fri, 2011-01-14 at 15:27 +1100, Sridhar Dhanapalan wrote: What is the status of HTML5 video support in Browse? I'm using version 108.4. Testing with the videos linked from http://double.co.nz/video_test/, most don't start when I press the Play button. Dextrose 2 includes all the free-world codecs that would be required to cover the most common video formats used by html5 and flash. For complete video support we need to either upgrade xulrunner to a recent version or replace Browse with Surf, which is based on WebKit. I believe 3.6 supported the theora component of html5. WebM will be supported as of firefox 4. I believe the next stable release of OLPC OS will be based upon Fedora 14 so will have the former. SoaS 5 will be based on Fedora 15 which will have the later so should support both theora and webm. I look forward to seeing people test this component as we amp up testing post Fedora 15 alpha release. Being still based on Fedora 11, Dextrose and OLPC-OS cannot meet all the dependencies of a modern version of webkitgtk, but Surf would be a great addition for SoaS and USR. Mozilla announced that Firefox 4 won't support a public ABI/API for xulrunner, Ubuntu has dropped the xulrunner-python bindings since Lucid and all the GNOME applications have already been converted to WebKitGtk. It's already very clear which way the wind blows. That's not entire true. They stated that they wouldn't ship other bindings (such as python) within the core xulrunner package. Also ActiveState who are the core developers of pyxpcom requested that it be split back out of the core code base to allow easier development. Regards, Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Fwd: [Scratch] Interested in packaging Scratch for Fedora
FYI - Bert - Begin forwarded message: From: W. Michael Petullo m...@flyn.org Date: 18. Januar 2011 04:14:26 MEZ To: Amos Blanton a...@scratch.mit.edu Cc: Bert Freudenberg b...@freudenbergs.de, li...@scratch.mit.edu, Sayamindu Dasgupta sayami...@media.mit.edu Subject: Re: [Scratch] Interested in packaging Scratch for Fedora I have submitted a Scratch package to RPM Fusion. Please see https://bugzilla.rpmfusion.org/show_bug.cgi?id=1601. -- Mike :wq ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activities not compatible with Sugar-0.90
On Mon, Jan 17, 2011 at 11:34:34PM -0500, Bernie Innocenti wrote: On Mon, 2011-01-17 at 17:11 -0500, Rafael Enrique Ortiz Guerrero wrote: I can't. I think every maintainer must do the change. Right every maintainer has to make that change in ASLO. Aren't you an aslo admin? You can change any activity. Imho, thats the job for activity authors (to see what sugar version is compatible with his activity). Another thing is that there is no way to say sugar = 0.86 on ASLO and uploaders need to add any new sugar version after it appeared. In dextrose we already have the code that relies on activity.info spec for sugar dep version, not to ASLO info. In my mind, thats the best way to go (and after that many activities switched to activity.info, we can remove sugar versions from ASLO at all). Btw, I guess most of not-all-sugars activities are Fructose, in time w/ switching to the new ASLO[1], we can review all activities and maybe do not implement sugar versions in new ASLO. For the record, the current aslo admins are: Tomeu Vizoso Wade Brainerd Simon Schampijer Mick Weiss Gary Martin david farning Walter Bender Sebastian Dziallas Rafael Ortiz Aleksey Lim Pablo Flores Bernie Innocenti josh [j...@tucson-labs.com] Thomas Gilliard Stefan Unterhauser Anish Mangal Sascha Silbe The activity editors are: Tomeu Vizoso Simon Schampijer Gary Martin Sebastian Dziallas Luke Faraone Rafael Ortiz James Simmons Aleksey Lim Activity Team We should probably cleanup both lists from people who are no longer actively working on ASLO. I think, would be better to do that on explicit requests from these people. As always, if anyone would like to help us maintaining ASLO or any other service provided by Sugar Labs, just let one of the Infrastructure Team members know. We hire volunteers after a short interview to ensure that they have the necessary technical skills and they intend to take the job seriously. Of course, when you run out of free time you can step down (responsibly!) from your role. Also, in my mind, ASLO is primarily a doer/user tool, so ASLO editors should not change existed uploads in the way they think is needed. They can remove existed activities if activities don't follow Editors policy[2] (or don not accept them to public). On other hand, when people (especially deployments) need the handle to say what activity version work in particular env., they can create collections and specify particular activity versions. This feature is accessible on activities-testing.sl.o and will be moved to production in time w/ dextrose-2 (that will contain new microformat updater). [1] http://wiki.sugarlabs.org/go/Platform_Team/Roadmap [2] http://wiki.sugarlabs.org/go/Activity_Library/Editors/Policy -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Modified Patch for adding feedback-icon.svg to sugar-artwork
From: root root@ubuntu.(none) 1)Icon converted to plain svg format Signed-off-by: Mukesh Gupta mukeshgupta.2...@gmail.com --- icons/scalable/device/Makefile.am |1 + icons/scalable/device/feedback-icon.svg | 378 +++ 2 files changed, 379 insertions(+), 0 deletions(-) mode change 100644 = 100755 icons/scalable/device/Makefile.am create mode 100755 icons/scalable/device/feedback-icon.svg diff --git a/icons/scalable/device/Makefile.am b/icons/scalable/device/Makefile.am old mode 100644 new mode 100755 index bca43f0..d75985c --- a/icons/scalable/device/Makefile.am +++ b/icons/scalable/device/Makefile.am @@ -3,6 +3,7 @@ category=device icondir = $(datadir)/icons/sugar/$(iconsize)/$(category) icon_DATA =\ + feedback-icon.svg \ battery-000.icon\ battery-000.svg \ battery-010.icon\ diff --git a/icons/scalable/device/feedback-icon.svg b/icons/scalable/device/feedback-icon.svg new file mode 100755 index 000..c7fc9a8 --- /dev/null +++ b/icons/scalable/device/feedback-icon.svg @@ -0,0 +1,378 @@ +?xml version=1.0 encoding=UTF-8 standalone=no? +!-- Created with Inkscape (http://www.inkscape.org/) -- + +svg:svg + xmlns:dc=http://purl.org/dc/elements/1.1/; + xmlns:cc=http://creativecommons.org/ns#; + xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; + xmlns:svg=http://www.w3.org/2000/svg; + xmlns:xlink=http://www.w3.org/1999/xlink; + version=1.0 + width=60 + height=60 + viewBox=0 0 128 128 + id=svg548 + svg:metadata + id=metadata48 +rdf:RDF + cc:Work + rdf:about= +dc:formatimage/svg+xml/dc:format +dc:type + rdf:resource=http://purl.org/dc/dcmitype/StillImage; / +dc:title/dc:title + /cc:Work +/rdf:RDF + /svg:metadata + svg:defs + id=defs601 +svg:linearGradient + x1=55.4272 + y1=102.1953 + x2=55.4272 + y2=-7.1773 + id=linearGradient3803 + gradientUnits=userSpaceOnUse + gradientTransform=translate(0,-0.496766) + spreadMethod=pad + svg:stop + id=stop3805 + style=stop-color:#00;stop-opacity:1 + offset=0 / + svg:stop + id=stop3807 + style=stop-color:#59657f;stop-opacity:1 + offset=0.20505001 / + svg:stop + id=stop3809 + style=stop-color:#b3caff;stop-opacity:1 + offset=0.41010001 / + svg:stop + id=stop3811 + style=stop-color:#dfeaff;stop-opacity:1 + offset=0.8258 / + svg:stop + id=stop3813 + style=stop-color:#eff4ff;stop-opacity:1 + offset=0.91289997 / + svg:stop + id=stop3815 + style=stop-color:#ff;stop-opacity:1 + offset=1 / + midPointStop + offset=0 + style=stop-color:#7C74FF + id=midPointStop560 / + midPointStop + offset=0.5 + style=stop-color:#7C74FF + id=midPointStop561 / + midPointStop + offset=0.4101 + style=stop-color:#B3CAFF + id=midPointStop562 / + midPointStop + offset=0.5 + style=stop-color:#B3CAFF + id=midPointStop563 / + midPointStop + offset=0.8258 + style=stop-color:#DFEAFF + id=midPointStop564 / + midPointStop + offset=0.5 + style=stop-color:#DFEAFF + id=midPointStop565 / + midPointStop + offset=1 + style=stop-color:#FF + id=midPointStop566 / +/svg:linearGradient +svg:linearGradient + id=linearGradient2802 + svg:stop + id=stop2804 + style=stop-color:#1d12aa;stop-opacity:1 + offset=0 / + svg:stop + id=stop2806 + style=stop-color:#8b12aa;stop-opacity:0 + offset=1 / +/svg:linearGradient +svg:linearGradient + id=linearGradient2812 + svg:stop + id=stop2814 + style=stop-color:#1d25aa;stop-opacity:1 + offset=0 / + svg:stop + id=stop2816 + style=stop-color:#8b12aa;stop-opacity:0 + offset=1 / +/svg:linearGradient +svg:marker + refX=0 + refY=0 + orient=auto + id=Arrow1Lstart + style=overflow:visible + svg:path + d=M 0,0 5,-5 -12.5,0 5,5 0,0 z + transform=scale(0.8,0.8) + id=path2991 + style=fill-rule:evenodd;stroke:#00;stroke-width:1pt;marker-start:none / +/svg:marker +svg:linearGradient + id=linearGradient4766 + svg:stop + id=stop4768 + style=stop-color:#0447ff;stop-opacity:1 + offset=0 / + svg:stop + id=stop4770 + style=stop-color:#00;stop-opacity:0 + offset=1 / +/svg:linearGradient +svg:linearGradient + x1=55.4272 + y1=102.1953 + x2=55.4272 + y2=-7.1773 + id=XMLID_1_ +
Re: [Sugar-devel] New Dextrose 2 build: os438dx
Thanks. I was talking with Gary about working in the Record UI. We must work in this for F14 version Gonzalo On Tue, Jan 18, 2011 at 1:00 AM, Bernie Innocenti ber...@codewiz.orgwrote: On Mon, 2011-01-17 at 22:51 -0300, Gonzalo Odiard wrote: If you come up with a patch, we'll include it in Dextrose. We already have a forked version to fix the UI layout, it can't hurt to have this bug fixed as well. Curious, where is this fork? Here it is: http://git.sugarlabs.org/~m_anish/record/ui-fixeshttp://git.sugarlabs.org/%7Em_anish/record/ui-fixes Now that the bug also affects F14-0.88, perhaps someone will care to fix it upstream one way or another. -- // 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] acti-plications: write once, run anywhere?
On a dual-boot XO, does it make sense to use the same binary code for sugar activities also in gnome applications? If so, are there guidelines or example acti-plications? If the same binary code is *not *re-used by both platforms, but just the same code base, are there guidelines or examples of how to re-use the same code base effectively? Off the top of my head, how data is serialized is handled differently between the two platforms. This question is of particular concern to acti-plications with many media assets, like some video games. It would be nice to avoid file redundancy. Given the small size of the XO netbooks, I hope this question is on mark for this community. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activities not compatible with Sugar-0.90
On 18 January 2011 13:06, Aleksey Lim alsr...@member.fsf.org wrote: Also, in my mind, ASLO is primarily a doer/user tool, so ASLO editors should not change existed uploads in the way they think is needed. I guess this means that my usage of activities.sugarlabs.org is not according to its design. Here's the task: I want to pull the latest activity version compatible with Sugar-0.90 for a specific set of activities from now until mid-April, several times a week. This is for their inclusion in development OS builds. What's your suggested approach to this? Right now I am querying http://activities.sugarlabs.org/services/update-aslo.php?id=ACTIVITYappVersion=0.90 and parsing the resultant XML. Thanks, Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] acti-plications: write once, run anywhere?
On 18.01.2011, at 18:41, Erik Blankinship wrote: On a dual-boot XO, does it make sense to use the same binary code for sugar activities also in gnome applications? If so, are there guidelines or example acti-plications? I think it makes a lot of sense. That's one of the reasons the Etoys activity bundle is but a tiny wrapper. Etoys works as stand-alone application in Gnome and as activity in Sugar. If the same binary code is not re-used by both platforms, but just the same code base, are there guidelines or examples of how to re-use the same code base effectively? Off the top of my head, how data is serialized is handled differently between the two platforms. Yes. Etoys switches the tool bar, e.g., the insert object/keep a copy buttons are replaced by file load/save buttons, the sharing button goes away, a full-screen button is added. The file format is the same, but different code paths are used. This question is of particular concern to acti-plications with many media assets, like some video games. It would be nice to avoid file redundancy. Given the small size of the XO netbooks, I hope this question is on mark for this community. Right on. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] acti-plications: write once, run anywhere?
On Tue, Jan 18, 2011 at 12:41 PM, Erik Blankinship er...@mediamods.com wrote: On a dual-boot XO, does it make sense to use the same binary code for sugar activities also in gnome applications? If so, are there guidelines or example acti-plications? The gnome side will most likely be installed via RPMs (or .deb files on Ubuntu/Fedora setups). So your Sugar app could just use the libraries, binaries and resources/assets from the RPM. Examples - Write.xo uses the Abiword libraries. Browse.xo uses xulrunner (the Firefox libraries backend). Bert pointed out EToys. In all those cases, you get code reuse and a small Activity, but the activity completely depends finding the things it needs. hth, 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] acti-plications: write once, run anywhere?
The gnome side will most likely be installed via RPMs (or .deb files on Ubuntu/Fedora setups). So your Sugar app could just use the libraries, binaries and resources/assets from the RPM. Examples - Write.xo uses the Abiword libraries. Browse.xo uses xulrunner (the Firefox libraries backend). Bert pointed out EToys. In all those cases, you get code reuse and a small Activity, but the activity completely depends finding the things it needs. If my acti-plication has dependencies that are not part of the underlying build, do I need to install them on the gnome side first? Or can cross-platform libraries be initially installed on the Sugar side too? A related follow-up: does it make sense to put cross-platform dependencies that a gnome activity would need into ~/Activities/MyCoolActivity.activity/ ? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activities not compatible with Sugar-0.90
On Tue, Jan 18, 2011 at 05:48:05PM +, Daniel Drake wrote: On 18 January 2011 13:06, Aleksey Lim alsr...@member.fsf.org wrote: Also, in my mind, ASLO is primarily a doer/user tool, so ASLO editors should not change existed uploads in the way they think is needed. I guess this means that my usage of activities.sugarlabs.org is not according to its design. Here's the task: I want to pull the latest activity version compatible with Sugar-0.90 for a specific set of activities from now until mid-April, several times a week. This is for their inclusion in development OS builds. What's your suggested approach to this? Right now I am querying http://activities.sugarlabs.org/services/update-aslo.php?id=ACTIVITYappVersion=0.90 and parsing the resultant XML. You can either do not use appVersion and update-aslo.php will return recent versions or just create collection. The activity-testing.sl.o implementation allows setting particular activity versions (it will be pushed to production after testing within dextrose-2, that was the purpose for this feature). In the last case, collection content will be accessible via microformat page, eg: http://activities-testing.sugarlabs.org/services/micro-format.php?collection_nickname=fructose Thanks, Daniel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activities not compatible with Sugar-0.90
On 18 January 2011 19:58, Aleksey Lim alsr...@member.fsf.org wrote: You can either do not use appVersion and update-aslo.php will return recent versions or just create collection. The activity-testing.sl.o implementation allows setting particular activity versions (it will be pushed to production after testing within dextrose-2, that was the purpose for this feature). In the last case, collection content will be accessible via microformat page, eg: http://activities-testing.sugarlabs.org/services/micro-format.php?collection_nickname=fructose I don't think either of those is what I need: If I drop appVersion, I'd get activities that run only on Sugar-0.92 and are incompatible with Sugar-0.90 (none right now, but I forsee a couple appearing before mid-April arrives). I want activities that are compatible with Sugar-0.90. If I use a collection, the versions are fixed to the exact versions that I add to the collection, whereas (see last mail) I want the latest activity version compatible with Sugar-0.90. (please correct me if I've misunderstood what a collection is) I'm now feeling more confident that my current approach is correct. Thoughts? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activities not compatible with Sugar-0.90
On Tue, 2011-01-18 at 20:32 +, Daniel Drake wrote: If I use a collection, the versions are fixed to the exact versions that I add to the collection, whereas (see last mail) I want the latest activity version compatible with Sugar-0.90. (please correct me if I've misunderstood what a collection is) The latest activity compatible with Sugar-X.Y is what the RDF protocol provided. This wasn't considered good for deployments enough because it doesn't allow the pedagogical team to do any QA on updates before they hit the users. So the idea is that Dextrose could create a collection dextrose2 which pins certain activity versions. Paraguay could create a collection dextrose2-py and pin slightly different activities. The downside of this approach is that development builds no longer get the latest and greatest activities automatically. Is this what is bothering you? Perhaps we could add separate microformat URLs that filter by Sugar version. In my mind, letting the activity owner self-certify which versions of Sugar are known to work well is poor QA practice. I'd rather have someone responsible to do some testing upfront before blessing them for the sugar-0.90 collection. Moreover, the version range currently supported by ASLO is a little too simplistic for the variety of ABIs that we're going to see soon: f14-s0.90-i386, f15-s0.92-arm... maybe even crazier. With multiple architectures, the dream of a simple universal bundle format for activity is over and our package management tools are still very immature. -- // 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] Activities not compatible with Sugar-0.90
On 18 January 2011 22:00, Bernie Innocenti ber...@codewiz.org wrote: This wasn't considered good for deployments enough because it doesn't allow the pedagogical team to do any QA on updates before they hit the users. Agreed. This is not for deployments, this is for development. The downside of this approach is that development builds no longer get the latest and greatest activities automatically. Is this what is bothering you? Yes. Perhaps we could add separate microformat URLs that filter by Sugar version. This would be good, but is basically what we have now in a different format: http://activities.sugarlabs.org/services/update-aslo.php?id=ACTIVITYappVersion=0.90 and I gathered from Aleksey that this isn't what activities.sugarlabs.org is designed for. (but judging from further responses, it's perhaps the only non-manual option that we have for now) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activities not compatible with Sugar-0.90
On Tue, Jan 18, 2011 at 05:00:07PM -0500, Bernie Innocenti wrote: On Tue, 2011-01-18 at 20:32 +, Daniel Drake wrote: If I use a collection, the versions are fixed to the exact versions that I add to the collection, whereas (see last mail) I want the latest activity version compatible with Sugar-0.90. (please correct me if I've misunderstood what a collection is) The latest activity compatible with Sugar-X.Y is what the RDF protocol provided. This wasn't considered good for deployments enough because it doesn't allow the pedagogical team to do any QA on updates before they hit the users. So the idea is that Dextrose could create a collection dextrose2 which pins certain activity versions. Paraguay could create a collection dextrose2-py and pin slightly different activities. The downside of this approach is that development builds no longer get the latest and greatest activities automatically. Is this what is bothering you? Perhaps we could add separate microformat URLs that filter by Sugar version. In my mind, letting the activity owner self-certify which versions of Sugar are known to work well is poor QA practice. I'd rather have someone responsible to do some testing upfront before blessing them for the sugar-0.90 collection. That depends on what side we are talking :), from deployment/distro pov, there is a need in [downstream] QA and collection is the right way (all activities need to be passed via such QA, if we talking about QA not just about letting deployment/distro users install some activities). My strong thinking is that ASLO should-not/impossible/useless be like a GNU/Linux distribution repository when all packages are well QAed and tested (it is perpendicular to sugar purposes when it is all about experiments and, thus, producing not-well-working/temporary solutions). ASLO is just a sharing place, we can have tens implementations of the same Record on ASLO (which is impossible in distribution repositories) from different doers and there [should not] is no any guaranties that all these implementations works well. If there is a need in guaranties, people work with particular doer (on improving particular activity) or create QAed/supporteded [downstream] collections. Moreover, the version range currently supported by ASLO is a little too simplistic for the variety of ABIs that we're going to see soon: f14-s0.90-i386, f15-s0.92-arm... maybe even crazier. With multiple architectures, the dream of a simple universal bundle format for activity is over and our package management tools are still very immature. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activities not compatible with Sugar-0.90
On Tue, 2011-01-18 at 22:06 +, Daniel Drake wrote: Perhaps we could add separate microformat URLs that filter by Sugar version. This would be good, but is basically what we have now in a different format: http://activities.sugarlabs.org/services/update-aslo.php?id=ACTIVITYappVersion=0.90 and I gathered from Aleksey that this isn't what activities.sugarlabs.org is designed for. (but judging from further responses, it's perhaps the only non-manual option that we have for now) Ah, yeah... I agree it's a useful feature for development. Originally, there was no way to pin particular versions in collections. One would always get the latest version flagged to work on your browser. Which is exactly what you're asking for. I'm not sure what's currently missing server-side, but it shouldn't be hard to do. -- // 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] Activities not compatible with Sugar-0.90
On Mon, Jan 17, 2011 at 09:07:32PM +, Daniel Drake wrote: Hi, According to activities.sugarlabs.org, the following activities (amongst others, probably) are not compatible with Sugar-0.90: org.laptop.WebActivity org.laptop.sugar.ReadActivity org.laptop.TamTamSynthLab, org.laptop.TamTamJam, org.laptop.TamTamEdit, org.laptop.TamTamMini, org.vpri.EtoysActivity, org.laptop.MeasureActivity org.laptop.ImpodeActivity vu.lux.olpc.Maze com.garycmartin.Moon edu.mit.media.ScratchActivity org.laptop.Terminal org.laptop.Log If these activities do work on 0.90, please mark them as so. Last changes for collections/microformat batch updater for ASLO: http://activities-testing.sugarlabs.org/services/micro-format.php?collection_nickname=collection-nick[sugar=sugar-version] * if activity version was not set in collection and sugar request argument wasn't passed, then return recent activity version * if activity version was not set in collection and sugar request argument was passed, then return either recent activity version only for this sugar or nothing * if activity version was set in collection, regardless sugar request argument, exactly this version will be returned Any help with testing this feature on activities-testing.sugarlabs.org (it several months copy of activities.sugarlabs.org) is welcome. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] acti-plications: write once, run anywhere?
On Tue, Jan 18, 2011 at 2:25 PM, Erik Blankinship er...@mediamods.com wrote: If my acti-plication has dependencies that are not part of the underlying build, do I need to install them on the gnome side first? It's not technically at the gnome side... you have to install them in the system :-) - Power users, developers with an XO, will use yum (or a GUI frontend to yum) to install the required libs, and the gnome app. - Typical users in an OLPC deployment will often depend on the OS image having the libs installed -- as it happens now with the examples I've given earlier. 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] acti-plications: write once, run anywhere?
On Tue, Jan 18, 2011 at 9:57 PM, Martin Langhoff martin.langh...@gmail.comwrote: On Tue, Jan 18, 2011 at 2:25 PM, Erik Blankinship er...@mediamods.com wrote: If my acti-plication has dependencies that are not part of the underlying build, do I need to install them on the gnome side first? It's not technically at the gnome side... you have to install them in the system :-) Let's assume delivery of the activity-application is via a usb stick. Let's also assume the video game has 200mb of assets. The goal is to make it as easy as possible to install the activity-application once, from either side, and to put the assets in one place. For sugar, this would be a ~200mb xo bundle on the usb stick. For gnome, this might be a ~200mb rpm on the usb stick. Do all activity and application developers have write access to any part of the system where they can add the libraries that they need to the system from either gnome or sugar side and then access if from either side? Where and how should assets be installed? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
