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
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 c...@laptop.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
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 wad...@gmail.com wrote: On Mon, Jan 5, 2009 at 7:15 AM, Bert Freudenberg b...@freudenbergs.de 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 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
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
On Mon, Jan 5, 2009 at 7:15 AM, Bert Freudenberg b...@freudenbergs.de 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
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
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 c...@laptop.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
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 dfarn...@sugarlabs.orgwrote: 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 days, I will try to summarize the (1) organization/development and
