Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
For those interested in integrating the embedded browser (xul), replete with javascript (and presumably all plugins), into a sugar activity, looking at the Map activity might offer some good starting points. See http://wiki.laptop.org/go/Map_(activity) In addition to simply embedding the browser component, the Map activity also: - matches pixel position information from the browser component directly to activity coordinates (overlaying gstreamer video streams over a map in the browser) - runs a local web server and also connects to a remote web server to mix local javascript with remote javascript - handles both "ajax" and "comet" connections allowing for fluid interaction with the remote html/javascript content and the activity's gtk widgets - can run multiple instances of itself on one machine without port conflicts - saves activity data to the journal ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
On Mon, Jan 5, 2009 at 3:03 PM, Chris Ball wrote: > It seems to me that > Sugar exists because we claim at least the following failings of most > educational software projects: > > * they don't allow the knowledge they contain to be *appropriated*. > * they don't allow children to be *creators* > * they don't allow learning to be *collaborated upon* I totally agree with these, but let me add two more perhaps unstated ones. 1. Existing educational software costs a lot of *money*, or else is *poorly designed*. In my state, entire classes of elementary school students receive MacBooks from the school, loaded with advanced educational software. Even with Apple's massive discounting, the hardware + software must cost around $1500 per student. Further, a lot of the existing open source educational software is fairly weak. It's even further behind the open source desktop software, which still has a long way to go to catch up with Microsoft, Apple and the other commercial vendors. To me, Sugar represents the best effort yet to provide actual quality, cohesive educational software as free software. Some Flash animations are poorly designed, but many are not, they can be made quickly and targeted at specific educational goals. The deployments have access to trained Flash programmers who are willing to help out. 2. Existing educational software does not *run on the XO*. The XO is the cheap hardware platform we are delivering to under served children, so what software they can use to learn with must run on this limited platform. Flash programs don't run great right now, but with some tweaking I believe they could probably be made to run acceptably. Best, -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
OpenLaszlo anyone? Not that I especially know what I'm talking about, but I get the impression it's trying to be an alternative to Flash, as well as accomodating Flash. Details at: http://www.openlaszlo.org/ http://en.wikipedia.org/wiki/OpenLaszlo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
Hi, all, The FlashPlayer is a virtual machine for display of highly visual, interactive, and compelling software content. I don't agree that use of Flash as a platform would be incompatible with "our strategy of _how_ to achieve education of the world's children" just because it was created under the proprietary umbrella of Macromedia and now Adobe. In case you are not aware of the opening of Flash source to software developers, here's a short article: http://www.flashmagazine.com/news/detail/open_screen_project_opens_adobe_even_more/ The use of a closed-source FlashPlayer is no more of an impediment to creating good educational software than is the use of the proprietary hardware inside the XO. Does anyone care that the processor components inside those chips are not open source? They're still a platform upon which creative people can build out their free & open-source ideas. The creativity is built on top of the platform, not necessarily within the platform. However, it's really not much of an issue because the guts of the XO barely meet the minimum requirements of the Flash player and don't meet the minimum for video playback.Flash animations work ok at 450 MHz, but video needs more speed to look smooth. As a cross-platform virtual machine, however, there's nothing out there as ubiquitous as Flash. The same program will play on Windows, Mac, & Linux (with careful attention to the few platform differences that Flash exposes to the programmer). It's even moving onto cell phones. If you would like an example of how Flash can provide an easy to use, collaborative environment, try www.vyew.com on your XO. It's a Flash application. Unfortunately, the FlashPlayer for Linux doesn't (yet) have appropriate drivers for the webcam in the XO, so you can't send video from the XO, but you can receive and view video from someone else collaborating on the vyew application while sharing a "whiteboard" for drawing and typing collaboratively. Regarding free development tools, the FlashDevelop IDE is free open-source and quite good for developing source code for the FlashPlayer. The various development kits (SDK) from Adobe and 3rd parties for Flash development (ActionScript, Flex, AIR, Away3d, etc.) are free downloads. Stan Chris Ball wrote: > Hi, > >> When the primary mission - educating the world's least served children >> - comes into conflict with Software Freedom, which one wins? How do >> you explain that to the deployments? > > This is a fine question. Here's my shot at it. > > First, I think it would be a mistake to think that we're the only group > of people, or the only software project, interested in educating these > children. It would be helpful for me, then, if we could be more > specific about what we in particular are trying to do (although it > contains the risk that we won't agree on that). It seems to me that > Sugar exists because we claim at least the following failings of most > educational software projects: > > * they don't allow the knowledge they contain to be *appropriated*. For > example, translated into other languages or cultures so that it can be > useful for the entire world, or modified, commented on and discussed. > They might choose to disallow this technically (by not providing a > method to perform the appropriation) or socially (by actively > disallowing it). > > * they don't allow children to be *creators*, and not just consumers. > We believe, as a consensus, that the best way to learn is by creation > and problem-solving rather than by being dictated to. > > * they don't allow learning to be *collaborated upon*, critiqued, > and conducted jointly. > > I'm sure this is less eloquent than the text that's already been written > on our goals, but it's a start. What follows from it is that we should > build software that: > > * is eminently modifiable by all, so that it can be appropriated into > areas of the world and use cases that its authors did not consider. > > * should allow not just the consumption of content, but its outright > creation. > > * should provide for pervasive sharing. > > Why did I just repeat all of this? It makes it easy for me to see that > a system like Flash is not (yet) appropriate software for learning as > we envision it, because it would not support our strategy of _how_ to > achieve education of the world's children, and that strategy is our > reason for not sitting back and letting the rest of the software > projects out there solve the problem for us. > > For this reason, I would support having Sugar Labs advocate against the > use of Flash, and think I can do this in an intellectually honest way. > This doesn't mean I would stop someone from writing a Flash player > wrapper if they want to, and it means I would likely change my mind > if free Flash players and editors became more available. > > Thanks, > > - Chris. > ___
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
Hi Stanley, > The FlashPlayer is a virtual machine for display of highly visual, > interactive, and compelling software content. I don't agree that > use of Flash as a platform would be incompatible with "our strategy > of _how_ to achieve education of the world's children" just because > it was created under the proprietary umbrella of Macromedia and now > Adobe. Please re-read my e-mail -- Flash's creation story was not in the list of reasons I gave for finding it an inappropriate platform for Sugar. > Regarding free development tools, the FlashDevelop IDE is free > open-source and quite good for developing source code for the > FlashPlayer. The various development kits (SDK) from Adobe and 3rd > parties for Flash development (ActionScript, Flex, AIR, Away3d, > etc.) are free downloads. Even if any of these tools were usable for the creation of Flash content (my impression is that they aren't), none of them run under the same operating system as Sugar, which makes them unavailable as editors for learners using Sugar (most of whom currently use Sugar on the OLPC XO). My argument is that a learning environment whose reason for existing is to encourage the creation and appropriation of content by learners should not attempt to accomplish this using a platform that provides *no method* for the learners using it to create or appropriate content! Thanks, - Chris. -- Chris Ball ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
Hi, > When the primary mission - educating the world's least served children > - comes into conflict with Software Freedom, which one wins? How do > you explain that to the deployments? This is a fine question. Here's my shot at it. First, I think it would be a mistake to think that we're the only group of people, or the only software project, interested in educating these children. It would be helpful for me, then, if we could be more specific about what we in particular are trying to do (although it contains the risk that we won't agree on that). It seems to me that Sugar exists because we claim at least the following failings of most educational software projects: * they don't allow the knowledge they contain to be *appropriated*. For example, translated into other languages or cultures so that it can be useful for the entire world, or modified, commented on and discussed. They might choose to disallow this technically (by not providing a method to perform the appropriation) or socially (by actively disallowing it). * they don't allow children to be *creators*, and not just consumers. We believe, as a consensus, that the best way to learn is by creation and problem-solving rather than by being dictated to. * they don't allow learning to be *collaborated upon*, critiqued, and conducted jointly. I'm sure this is less eloquent than the text that's already been written on our goals, but it's a start. What follows from it is that we should build software that: * is eminently modifiable by all, so that it can be appropriated into areas of the world and use cases that its authors did not consider. * should allow not just the consumption of content, but its outright creation. * should provide for pervasive sharing. Why did I just repeat all of this? It makes it easy for me to see that a system like Flash is not (yet) appropriate software for learning as we envision it, because it would not support our strategy of _how_ to achieve education of the world's children, and that strategy is our reason for not sitting back and letting the rest of the software projects out there solve the problem for us. For this reason, I would support having Sugar Labs advocate against the use of Flash, and think I can do this in an intellectually honest way. This doesn't mean I would stop someone from writing a Flash player wrapper if they want to, and it means I would likely change my mind if free Flash players and editors became more available. Thanks, - Chris. -- Chris Ball ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
Wade Brainerd wrote: > just talking about shipping and supporting a 200 line > Gnash-based-activity launcher script, which can also launch Adobe if > it happens to be installed. Assuming you can talk Adobe into giving you a standalone version of their plugin... - rob - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
On Mon, Jan 5, 2009 at 12:07 PM, Benjamin M. Schwartz wrote: > Wade Brainerd wrote: >> >> I think the template should be built into and supported by the Sugar >> dev team, rather than something that has to be copied around. > > I strongly disagree. We should send the clearest possible message that SWF, > a language with no good free spec and no good free interpreter, is not > recommended, even if it is supported. Software Freedom is a key part of the > Sugar labs mission, both officially and in fact. When the primary mission - educating the world's least served children - comes into conflict with Software Freedom, which one wins? How do you explain that to the deployments? Anyway, this is such a gray area to be taking a stand in. We are just talking about shipping and supporting a 200 line Gnash-based-activity launcher script, which can also launch Adobe if it happens to be installed. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
Hi, > This might be of interest: Salasaga is a GTK/Gnome based IDE used > to create eLearning for applications. With it, you take screenshots > of your applications, add highlights, text and external images, > then generate learning objects. Present output is in swf (flash) > format. Here's another app that appeared in my RSS reader today, I haven't tried it; it seems to contain some of the ideas Bryan's interested in, though: http://www.blueskyonmars.com/2009/01/05/build-desktop-apps-with-web-ui-and-python/ http://titaniumapp.com/ - Chris. -- Chris Ball ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
Benjamin M. Schwartz wrote: > I strongly disagree. We should send the clearest possible message that > SWF, a language with no good free spec and no good free interpreter, is Just as a warning, Adobe is probably this year going to push SWF as an official standard, ala OOXML... at least that's the rumor... >> A nice additional feature would be to make use of Jordan's screen >> resolution dropper on the XO to allow Flash activities to run at >> 600x450, which would likely quadruple performance. This is why we've been adding XVideo support, which has not been a trivial task as it turns out. > We can do even better. > http://wiki.gnashdev.org/Release_0.8.5#Release_Goals shows XVideo > scaling support as one of the goals for the next Gnash, due in a month. Yep, hopefully the code will stabilize over the next week now that the holiday's are over. The Code freeze starts after FOSDEM, the release itself won't be out till late Feb. It will also have support for the MIT-SHM extension, which works now, and also helps with performance issues. We hope the combination of these two performance hacks helps on low end hardware like the XO. - rob - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
Bert Freudenberg wrote: > IMHO that activity should be a wrapper for Gnash, perhaps as a native > GTK+ application, without the browser baggage (maybe such a stand-alone > player does exist already?). Since the content is authored specifically As Gnash was created originally as the UI layer for a stereo, it's always run standalone. I only made an additional plugin since most people are used to only running flash in their browser. > for Sugar (and in Nepal's case even more specifically for Sugar on the > OLPC XO-1) it can easily be tuned to work well in Gnash. Hopefully > Gnash's current limitations are well documented so authors can avoid > pitfalls. That "sugarized SWF player" could even be extended to > integrate nicely with the Journal (being able to do that is the point of > having a free implementation after all) - there is no need to be > compatible with Adobe's Flash player. Exactly. If the people creating he content work with us a little, and test with Gnash, the flash content will always work fine. You don't need any of the features of the latest flash anyway. At the same time, we need to figure out how to keep up to data builds for Sugar, as much of the problem has been old versions of Gnash. - rob - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
David Van Assche wrote: > Salasaga is a GTK/Gnome based IDE used to create eLearning for > applications. With it, you take screenshots of your applications, > add highlights, text and external images, then generate learning > objects. Present output is in swf (flash) format. I've talked to their developers. Salasaga is a good tool for creating instructional design software, namely lots of screenshots. It's not much for animations. They thought adding a SWF backend would be interesting, it's not in their roadmap. - rob - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
On Jan 4, 2009, at 9:23 PM, Wade Brainerd wrote: > Personally, I don't believe that Sugar Labs the organization needs > to be concerned with any of these four points. Ahh, but a recurring question from existing Sugar deployments is how to get Flash, why Flash doesn't run faster, etc. > The question is whether the Sugar *software* is flexible enough to > adapt to the needs of its users. Who are we to say what they > should install, and what tools they should use to make their content? The question is what answer you provide to this crucial question. How crucial ? Any (non-x86) processor design hoping to for MID/ settop/laptop market penetration is paying Adobe to support them from day one. One day, we hope they will instead pay someone to port Gnash + codecs instead... > Currently Sugar is incapable of running software which is not > specifically designed for it. Sugar runs simpler SWF applications just fine, through the Browser. They don't have to be "designed" for Sugar. > This precludes smaller organizations who cannot design custom Sugar > activities from producing good content. Once the Sugar software is > more flexible and able to run arbitrary programs (Gnash, Flash, > Silverlight, GTK, Qt) without massive time investment and hacking > on the part of the content producers, the other questions won't > even reach this list. > > Best regards, > Wade > > On Sun, Jan 4, 2009 at 8:38 PM, David Farning > wrote: > Bryan Berry started a great thread about activity development a few > days ago. In the initial post he proposed using flash as means of > developing content. Before taking the thread any farther I though we > should stop and look at what flash actually is. > > The term flash is often interchangeably used as: > 1. A brand > 2. A player > 3. A development environment > 4. A protocol > > Yep, confusing. As we continue the discussion, I thought we should > look at how 'flash' relates to Sugar and to more generally to OLPC and > Open Source. I have CCed MaryBeth from Open Media Now and Rob from > Gnash to help clarify the many shortcomings in my explanations. > > First, the brand - > Flash is primarily a brand. It was originally created by MacroMedia > and has been purchased by Adobe. The brand consists of the player, > IDE, protocol, and the support and marketing provided by Adobe. As a > brand, Flash is competing head-to-head with Microsoft's Silverlight. > > Second, the player - > The most visible part of flash is the player. The _Adobe_Flash_Player > is a proprietary product which is developed, supported, and > distributed by Adobe. Currently, the Adobe Flash Player can only be > distributed with Adobe's permission. Binary code for the player can > be downloaded for most operating systems and distributions. > > Third party redistribution is strictly prohibited without permission. > As such it would not be possible for Sugar Labs to distribute the > Adobe_Flash_Player in its code bundles. Deployments can, and often > do, add the Player as an available activity. The Player can be > legally redistributed over an organization's intra-net. > > Third, the authoring tools - > Adobe's business model is to give away the player and sell the > authoring tools. As a result, Adobe sells several very good, yet, > expensive authoring tools. Adobe's development tool costs > approximately $750 US. > > Fourth, the Standards - > Flash deliverables come in two formats .swf and .flv. Swf and > ActionScript, the development language use to create .swfs have been > open sourced. I believe that the ActionScript source code is jointly > held by Adobe and Mozilla. There are possible legal questions about > the patent encumberment status of some of the media codecs used in > swfs and flvs. We would need clarification from the Software Freedom > Conservancy on these issues. > > So, counting backwards how does this affect Sugar Lab? > Fourth, the Standards - > We need to wait for feedback from the SFC and Open Media Now. > > Third, the authoring tools - > Adobe has done a very effective job eliminating the competition for > flash authoring tools. http://osflash.org/ has a number of open > source development tools. I am not enough of a flash developer to > judge if the authoring products are mature enough to be useful or not. > Are there any Flash developers out there, can you judge the quality > of some of these products? > > Second, the player - > The Free Software Foundation has flash player project called Gnash. > The project is makin slow yet steady progress towards being a fully > capable swf player. The project suffers from lack of support. Many > Open Source users either download the Adobe player or forgo using > flash. The itch factor is pretty low. > > As a product, Gnash is approaching, yet is not yet ready for, prime > time. I spent New Years Day with my sister's kids( ages 11, 7, and 4) > looking at their favorites sites under Ubuntu/Flash, Ubuntu/Gnas
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
On Mon, 2009-01-05 at 16:01 +0100, David Van Assche wrote: > This might be of interest: > > Salasaga is a GTK/Gnome based IDE used to create eLearning for > applications. With it, you take screenshots of your applications, > add highlights, text and external images, then generate learning > objects. Present output is in swf (flash) format. > > It would certainly be useful for making flash based learning objects > for Moodle. The site for the soft is here: > http://www.salasaga.org/ > > kind Regards, > David Van Assche This looks extremely neat. Thanks for the link David! -- 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
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
Wade Brainerd wrote: > I think the template should be built into and supported by the Sugar > dev team, rather than something that has to be copied around. I strongly disagree. We should send the clearest possible message that SWF, a language with no good free spec and no good free interpreter, is not recommended, even if it is supported. Software Freedom is a key part of the Sugar labs mission, both officially and in fact. > A nice additional feature would be to make use of Jordan's screen > resolution dropper on the XO to allow Flash activities to run at > 600x450, which would likely quadruple performance. We can do even better. http://wiki.gnashdev.org/Release_0.8.5#Release_Goals shows XVideo scaling support as one of the goals for the next Gnash, due in a month. --Ben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
This might be of interest: Salasaga is a GTK/Gnome based IDE used to create eLearning for applications. With it, you take screenshots of your applications, add highlights, text and external images, then generate learning objects. Present output is in swf (flash) format. It would certainly be useful for making flash based learning objects for Moodle. The site for the soft is here: http://www.salasaga.org/ kind Regards, David Van Assche On Mon, Jan 5, 2009 at 3:16 PM, Wade Brainerd wrote: > On Mon, Jan 5, 2009 at 7:15 AM, Bert Freudenberg wrote: >> On 05.01.2009, at 05:24, John Watlington wrote: >> >>> On Jan 4, 2009, at 9:23 PM, Wade Brainerd wrote: Currently Sugar is incapable of running software which is not specifically designed for it. >>> >>> Sugar runs simpler SWF applications just fine, through the Browser. >>> They don't have to be "designed" for Sugar. >> >> >> I think this goes besides the original point of Bryan. He is well aware that >> software needs to be specifically designed for Sugar, and wether this is >> good or bad is not the current debate. The point is what tools one can use >> to implement a proper Sugar activity. Bryan says the tools many content >> developers are familiar with are HTML, Javascript, and Flash. > > I agree completely - I proposed a swf-activity launcher script as the > solution, in my initial response to Bryan. > >> I think it would be relatively easy to come up with an activity template >> that just has a subdirectory for SWF content. Creating an SWF activity then >> would involve copying the template, editing the meta data, putting the SWF >> content into the directory, zipping it up and voila, a nice XO bundle. That >> process could easily be done by a script, even on Windows. > > I think the template should be built into and supported by the Sugar > dev team, rather than something that has to be copied around. > > That way it's able to be updated and improved over time, and as better > Flash solutions become available we can incorporate them easily. > > I agree with the rest of Bert's plan. It should be a PyGTK activity > with just an activity toolbar, which launches Gnash or Adobe Flash > into its canvas. It should also find the Flash persistence database > and copy it to/from the Journal. > > A nice additional feature would be to make use of Jordan's screen > resolution dropper on the XO to allow Flash activities to run at > 600x450, which would likely quadruple performance. > > -Wade > ___ > IAEP -- It's An Education Project (not a laptop project!) > i...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
On Mon, Jan 5, 2009 at 7:15 AM, Bert Freudenberg wrote: > On 05.01.2009, at 05:24, John Watlington wrote: > >> On Jan 4, 2009, at 9:23 PM, Wade Brainerd wrote: >>> >>> Currently Sugar is incapable of running software which is not >>> specifically designed for it. >> >> Sugar runs simpler SWF applications just fine, through the Browser. >> They don't have to be "designed" for Sugar. > > > I think this goes besides the original point of Bryan. He is well aware that > software needs to be specifically designed for Sugar, and wether this is > good or bad is not the current debate. The point is what tools one can use > to implement a proper Sugar activity. Bryan says the tools many content > developers are familiar with are HTML, Javascript, and Flash. I agree completely - I proposed a swf-activity launcher script as the solution, in my initial response to Bryan. > I think it would be relatively easy to come up with an activity template > that just has a subdirectory for SWF content. Creating an SWF activity then > would involve copying the template, editing the meta data, putting the SWF > content into the directory, zipping it up and voila, a nice XO bundle. That > process could easily be done by a script, even on Windows. I think the template should be built into and supported by the Sugar dev team, rather than something that has to be copied around. That way it's able to be updated and improved over time, and as better Flash solutions become available we can incorporate them easily. I agree with the rest of Bert's plan. It should be a PyGTK activity with just an activity toolbar, which launches Gnash or Adobe Flash into its canvas. It should also find the Flash persistence database and copy it to/from the Journal. A nice additional feature would be to make use of Jordan's screen resolution dropper on the XO to allow Flash activities to run at 600x450, which would likely quadruple performance. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
On Sun, Jan 4, 2009 at 11:24 PM, John Watlington wrote: > On Jan 4, 2009, at 9:23 PM, Wade Brainerd wrote: >> Personally, I don't believe that Sugar Labs the organization needs to be >> concerned with any of these four points. > > Ahh, but a recurring question from existing Sugar deployments is how to get > Flash, why Flash doesn't run faster, etc. This appears to contradict the following statement. >> Currently Sugar is incapable of running software which is not specifically >> designed for it. > > Sugar runs simpler SWF applications just fine, through the Browser. They > don't have to be > "designed" for Sugar. This thread isn't about simpler SWF files (punch the monkey, etc). It's about learning activities written in Flash. OTOH, if web games etc get better as a result, great. >> The question is whether the Sugar *software* is flexible enough to adapt to >> the needs of its users. Who are we to say what they should install, and >> what tools they should use to make their content? > >The question is what answer you provide to this crucial question. It's not my question to answer, nor Sugar Labs. It's a good idea to support other OSS software, but not when it runs counter to the mission of the project. Macromedia created, supported and marketed Flash. They deserve to make some money from it. Gnash will be a wonderful solution when it's ready for prime time. But it's up to the deployments (the practicality folks) to decide what software to use, we just have to make it work with the rest of our system. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
On 05.01.2009, at 05:24, John Watlington wrote: > On Jan 4, 2009, at 9:23 PM, Wade Brainerd wrote: >> Currently Sugar is incapable of running software which is not >> specifically designed for it. > Sugar runs simpler SWF applications just fine, through the Browser. > They don't have to be "designed" for Sugar. I think this goes besides the original point of Bryan. He is well aware that software needs to be specifically designed for Sugar, and wether this is good or bad is not the current debate. The point is what tools one can use to implement a proper Sugar activity. Bryan says the tools many content developers are familiar with are HTML, Javascript, and Flash. So how could an activity look like that can be authored primarily using Adobe's Flash tools? I think it would be relatively easy to come up with an activity template that just has a subdirectory for SWF content. Creating an SWF activity then would involve copying the template, editing the meta data, putting the SWF content into the directory, zipping it up and voila, a nice XO bundle. That process could easily be done by a script, even on Windows. IMHO that activity should be a wrapper for Gnash, perhaps as a native GTK+ application, without the browser baggage (maybe such a stand- alone player does exist already?). Since the content is authored specifically for Sugar (and in Nepal's case even more specifically for Sugar on the OLPC XO-1) it can easily be tuned to work well in Gnash. Hopefully Gnash's current limitations are well documented so authors can avoid pitfalls. That "sugarized SWF player" could even be extended to integrate nicely with the Journal (being able to do that is the point of having a free implementation after all) - there is no need to be compatible with Adobe's Flash player. My 1/50 € ... - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
I should add one assumption that I'm making, which is that Flash will never be considered the *primary* content authoring solution for Sugar activities. If it were to become so, given the current state as outlined by David's 4 points, there needs to be significant support by Sugar Labs for the Flash development tools, financially and with code. But from my perspective, the challenges associated with making it a primary content authoring system are so large as to be not worth pursuing when a few simple tweaks to the current software stack would get you 90% of the way there. Cheers, -Wade On Sun, Jan 4, 2009 at 9:23 PM, Wade Brainerd wrote: > Personally, I don't believe that Sugar Labs the organization needs to be > concerned with any of these four points. > > The question is whether the Sugar *software* is flexible enough to adapt to > the needs of its users. Who are we to say what they should install, and > what tools they should use to make their content? > > Currently Sugar is incapable of running software which is not specifically > designed for it. This precludes smaller organizations who cannot design > custom Sugar activities from producing good content. Once the Sugar > software is more flexible and able to run arbitrary programs (Gnash, Flash, > Silverlight, GTK, Qt) without massive time investment and hacking on the > part of the content producers, the other questions won't even reach this > list. > > Best regards, > Wade > > On Sun, Jan 4, 2009 at 8:38 PM, David Farning wrote: > >> Bryan Berry started a great thread about activity development a few >> days ago. In the initial post he proposed using flash as means of >> developing content. Before taking the thread any farther I though we >> should stop and look at what flash actually is. >> >> The term flash is often interchangeably used as: >> 1. A brand >> 2. A player >> 3. A development environment >> 4. A protocol >> >> Yep, confusing. As we continue the discussion, I thought we should >> look at how 'flash' relates to Sugar and to more generally to OLPC and >> Open Source. I have CCed MaryBeth from Open Media Now and Rob from >> Gnash to help clarify the many shortcomings in my explanations. >> >> First, the brand - >> Flash is primarily a brand. It was originally created by MacroMedia >> and has been purchased by Adobe. The brand consists of the player, >> IDE, protocol, and the support and marketing provided by Adobe. As a >> brand, Flash is competing head-to-head with Microsoft's Silverlight. >> >> Second, the player - >> The most visible part of flash is the player. The _Adobe_Flash_Player >> is a proprietary product which is developed, supported, and >> distributed by Adobe. Currently, the Adobe Flash Player can only be >> distributed with Adobe's permission. Binary code for the player can >> be downloaded for most operating systems and distributions. >> >> Third party redistribution is strictly prohibited without permission. >> As such it would not be possible for Sugar Labs to distribute the >> Adobe_Flash_Player in its code bundles. Deployments can, and often >> do, add the Player as an available activity. The Player can be >> legally redistributed over an organization's intra-net. >> >> Third, the authoring tools - >> Adobe's business model is to give away the player and sell the >> authoring tools. As a result, Adobe sells several very good, yet, >> expensive authoring tools. Adobe's development tool costs >> approximately $750 US. >> >> Fourth, the Standards - >> Flash deliverables come in two formats .swf and .flv. Swf and >> ActionScript, the development language use to create .swfs have been >> open sourced. I believe that the ActionScript source code is jointly >> held by Adobe and Mozilla. There are possible legal questions about >> the patent encumberment status of some of the media codecs used in >> swfs and flvs. We would need clarification from the Software Freedom >> Conservancy on these issues. >> >> So, counting backwards how does this affect Sugar Lab? >> Fourth, the Standards - >> We need to wait for feedback from the SFC and Open Media Now. >> >> Third, the authoring tools - >> Adobe has done a very effective job eliminating the competition for >> flash authoring tools. http://osflash.org/ has a number of open >> source development tools. I am not enough of a flash developer to >> judge if the authoring products are mature enough to be useful or not. >> Are there any Flash developers out there, can you judge the quality >> of some of these products? >> >> Second, the player - >> The Free Software Foundation has flash player project called Gnash. >> The project is makin slow yet steady progress towards being a fully >> capable swf player. The project suffers from lack of support. Many >> Open Source users either download the Adobe player or forgo using >> flash. The itch factor is pretty low. >> >> As a product, Gnash is approaching, yet is not yet ready for, prime >> time. I spent N
Re: [Sugar-devel] [IAEP] Flash at Sugar Labs
Personally, I don't believe that Sugar Labs the organization needs to be concerned with any of these four points. The question is whether the Sugar *software* is flexible enough to adapt to the needs of its users. Who are we to say what they should install, and what tools they should use to make their content? Currently Sugar is incapable of running software which is not specifically designed for it. This precludes smaller organizations who cannot design custom Sugar activities from producing good content. Once the Sugar software is more flexible and able to run arbitrary programs (Gnash, Flash, Silverlight, GTK, Qt) without massive time investment and hacking on the part of the content producers, the other questions won't even reach this list. Best regards, Wade On Sun, Jan 4, 2009 at 8:38 PM, David Farning wrote: > Bryan Berry started a great thread about activity development a few > days ago. In the initial post he proposed using flash as means of > developing content. Before taking the thread any farther I though we > should stop and look at what flash actually is. > > The term flash is often interchangeably used as: > 1. A brand > 2. A player > 3. A development environment > 4. A protocol > > Yep, confusing. As we continue the discussion, I thought we should > look at how 'flash' relates to Sugar and to more generally to OLPC and > Open Source. I have CCed MaryBeth from Open Media Now and Rob from > Gnash to help clarify the many shortcomings in my explanations. > > First, the brand - > Flash is primarily a brand. It was originally created by MacroMedia > and has been purchased by Adobe. The brand consists of the player, > IDE, protocol, and the support and marketing provided by Adobe. As a > brand, Flash is competing head-to-head with Microsoft's Silverlight. > > Second, the player - > The most visible part of flash is the player. The _Adobe_Flash_Player > is a proprietary product which is developed, supported, and > distributed by Adobe. Currently, the Adobe Flash Player can only be > distributed with Adobe's permission. Binary code for the player can > be downloaded for most operating systems and distributions. > > Third party redistribution is strictly prohibited without permission. > As such it would not be possible for Sugar Labs to distribute the > Adobe_Flash_Player in its code bundles. Deployments can, and often > do, add the Player as an available activity. The Player can be > legally redistributed over an organization's intra-net. > > Third, the authoring tools - > Adobe's business model is to give away the player and sell the > authoring tools. As a result, Adobe sells several very good, yet, > expensive authoring tools. Adobe's development tool costs > approximately $750 US. > > Fourth, the Standards - > Flash deliverables come in two formats .swf and .flv. Swf and > ActionScript, the development language use to create .swfs have been > open sourced. I believe that the ActionScript source code is jointly > held by Adobe and Mozilla. There are possible legal questions about > the patent encumberment status of some of the media codecs used in > swfs and flvs. We would need clarification from the Software Freedom > Conservancy on these issues. > > So, counting backwards how does this affect Sugar Lab? > Fourth, the Standards - > We need to wait for feedback from the SFC and Open Media Now. > > Third, the authoring tools - > Adobe has done a very effective job eliminating the competition for > flash authoring tools. http://osflash.org/ has a number of open > source development tools. I am not enough of a flash developer to > judge if the authoring products are mature enough to be useful or not. > Are there any Flash developers out there, can you judge the quality > of some of these products? > > Second, the player - > The Free Software Foundation has flash player project called Gnash. > The project is makin slow yet steady progress towards being a fully > capable swf player. The project suffers from lack of support. Many > Open Source users either download the Adobe player or forgo using > flash. The itch factor is pretty low. > > As a product, Gnash is approaching, yet is not yet ready for, prime > time. I spent New Years Day with my sister's kids( ages 11, 7, and 4) > looking at their favorites sites under Ubuntu/Flash, Ubuntu/Gnash, > Xo/Flash, and Xo,Flash. I bet that was the first time they have ever > heard a adult tell them to, 'come on, play it again, just one more > time, please...' about their favorite games:) > > There was a steady decrease in the availability and usability of sites > with Xo and Gnash. We need to wait for feedback from Gnash about the > product's technical limitations and the project's development > limitations. > > Finally, the brand - > Adobe has recently asked Gnash to call their player a SWF player > rather than a flash player:) > > I appreciate your feedback on the technical aspect of Bryan's propose. > In the next few day
