Re: [IAEP] Calendar goodness
On Tue, Nov 11, 2008 at 5:48 AM, David Farning [EMAIL PROTECTED] wrote: Check out the new wiki feature Bernie add to w.s.o. http://sugarlabs.org/go/WikiTeam/Meetings We can now embed gcalendars directly into the wiki:) I added a page for a calendar of conferences of interest to our communities. http://sugarlabs.org/go/Events thanks david ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name And Children are my nation. The Cosmos is my dwelling place, The Truth my destination. http://wiki.sugarlabs.org/go/User:Mokurai ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Common Sugar distribution package contents.
On Wed, Dec 3, 2008 at 19:15, Jonas Smedegaard [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Dec 03, 2008 at 08:36:42AM -0800, C.W. Holeman II wrote: http://sugarlabs.org/go/Sugar_Application_Stack: * Library Collections (e.g., for the Browse Activity) * Sugar Activities (Browse, Read, Write, Record Turtle Art) * Sugar * Operating System (Linux, MacOSX, MSWindows) * Hardware Platform ( XO-1, EEE PC, Classmate, XO-2) Libraries are distributed in collections. Activities are distributed in bundles. Sugar is distributed in various kinds of packaging. The library collections and activity bundle formats for Sugar are in a format that is common across all OS/Hardware platforms. Sugar is distributed in formats that depend upon the OS/Hardware platform. The contents of activity bundle like Turtle Art or Browse is the same across all OS/Hardware platforms. The performance of Sugar on various OS/Hardware platforms varies. This should only be for issues that are dependent upon the underlying hardware and OS. It should not be the case for Sugar, Activities and libraries. There should be a common or core set of Activities and Library Collections that are in every Sugar distribution regardless of the kind of packaging the OS uses. There should be documentation on what the common or core Sugar must always contain. The packagers need this information. There may be additional optional packages also defined that are intended to work on all systems. This is needed to promote Sugar as a friendly environment for outsiders to become insiders. Suggestion: Encourage, but do not mandate, distributions to follow the Glucose/Fructose grouping of packages as documented at http://sugarlabs.org/go/DevelopmentTeam/Source_Code and ecourage (not mandate) releasing one of the following (prioritized - first is best): Sure, the whole point behind Glucose/Fructose is to have a collection of releases that are done together, tested to work together, and easy to package because the tarballs are all in a known location. 1) All branches (0.81, 0.82 and 0.83 currently) 2) All stable branches (0.82 currently) 3) Only latest stable branch (0.82 currently) This is releated to the recent discussion on whether Sugarlabs would rather that Debian-edu) rip out and avoid Sugar from its next release than release with software not matching latest stable branch. It is purely a recommendation, based on the presumed support issues. Sugar Labs is basically a community, more than it is an organisation. The community was asked, and the community responded. If the likely answer to every problem with the debian sugar packages is oh, you're using an old unsupported unstable development version of Sugar, upgrade to 0.82 then is there any point in shipping 0.81? Will anybody actually use the 0.81 packages for a deployment? It's your call. Must all parts of Glucose/Fructose be included in a distribution? Must all parts of Glucose/Fructose be installed together? Must all parts of Glucose/Fructose be no older than official release? Must all parts of Glucose/Fructose be no newer than official release? There are no rules. The answer to these questions is obviously no. What if a distribution does not obey your wish? Do you want to protect your name like Mozilla does (leading to Debian renaming its web browser to Iceweasel to be allowed to independently apply security patches)? Or do you perhaps want to only protect your own official binary releases like [Scratch]? As I said, it's purely a recommendation. Feel free to distribute what you want - but the first place the users come for support is (in my experience) the Sugar community, who is likely to say for optimal experience, make sure you run the latest stable version. - Jonas Regards Morgan ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Color combos for the logo
Ciao, I was wondering if someone could upload more bitmaps of the logo in different color combos: http://sugarlabs.org/go/MarketingTeam/Logo The idea was to use a different one every time, so we should have a bit more choice when we need to quickly pick one for a new web site. Please, use the same resolution (2997x646), depth and format of the existing ones. -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Common Sugar distribution package contents.
On Thu, Dec 4, 2008 at 9:53 AM, Morgan Collett [EMAIL PROTECTED] wrote: On Wed, Dec 3, 2008 at 19:15, Jonas Smedegaard [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Dec 03, 2008 at 08:36:42AM -0800, C.W. Holeman II wrote: http://sugarlabs.org/go/Sugar_Application_Stack: * Library Collections (e.g., for the Browse Activity) * Sugar Activities (Browse, Read, Write, Record Turtle Art) * Sugar * Operating System (Linux, MacOSX, MSWindows) * Hardware Platform ( XO-1, EEE PC, Classmate, XO-2) Libraries are distributed in collections. Activities are distributed in bundles. Sugar is distributed in various kinds of packaging. The library collections and activity bundle formats for Sugar are in a format that is common across all OS/Hardware platforms. Sugar is distributed in formats that depend upon the OS/Hardware platform. The contents of activity bundle like Turtle Art or Browse is the same across all OS/Hardware platforms. The performance of Sugar on various OS/Hardware platforms varies. This should only be for issues that are dependent upon the underlying hardware and OS. It should not be the case for Sugar, Activities and libraries. There should be a common or core set of Activities and Library Collections that are in every Sugar distribution regardless of the kind of packaging the OS uses. There should be documentation on what the common or core Sugar must always contain. The packagers need this information. There may be additional optional packages also defined that are intended to work on all systems. This is needed to promote Sugar as a friendly environment for outsiders to become insiders. Suggestion: Encourage, but do not mandate, distributions to follow the Glucose/Fructose grouping of packages as documented at http://sugarlabs.org/go/DevelopmentTeam/Source_Code and ecourage (not mandate) releasing one of the following (prioritized - first is best): Sure, the whole point behind Glucose/Fructose is to have a collection of releases that are done together, tested to work together, and easy to package because the tarballs are all in a known location. 1) All branches (0.81, 0.82 and 0.83 currently) 2) All stable branches (0.82 currently) 3) Only latest stable branch (0.82 currently) This is releated to the recent discussion on whether Sugarlabs would rather that Debian-edu) rip out and avoid Sugar from its next release than release with software not matching latest stable branch. It is purely a recommendation, based on the presumed support issues. Sugar Labs is basically a community, more than it is an organisation. The community was asked, and the community responded. If the likely answer to every problem with the debian sugar packages is oh, you're using an old unsupported unstable development version of Sugar, upgrade to 0.82 then is there any point in shipping 0.81? Will anybody actually use the 0.81 packages for a deployment? It's your call. Must all parts of Glucose/Fructose be included in a distribution? Must all parts of Glucose/Fructose be installed together? Must all parts of Glucose/Fructose be no older than official release? Must all parts of Glucose/Fructose be no newer than official release? There are no rules. The answer to these questions is obviously no. What if a distribution does not obey your wish? Do you want to protect your name like Mozilla does (leading to Debian renaming its web browser to Iceweasel to be allowed to independently apply security patches)? Or do you perhaps want to only protect your own official binary releases like [Scratch]? As I said, it's purely a recommendation. Feel free to distribute what you want - but the first place the users come for support is (in my experience) the Sugar community, who is likely to say for optimal experience, make sure you run the latest stable version. I agree with this, in this moment. But I can see a not-so-far future where user support for Sugar will be given mainly by local communities, so we can better respond to different languages, cultures and specifics of Sugar as deployed in one geographical area. And that will certainly include different versions of Sugar running in different versions (and derivatives) of distros. Global organizations like SugarLabs and Debian will work so those local groups have a quality platform on which to base their products, but user support will be mainly given by local groups. But for now, it's certainly how Morgan said. Regards, Tomeu ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Fwd: [OLPC-SF] Not new, but needs to be addressed
good responses to leigh blackall's complaints by Jim Tittsler and David Leeming on this Tuvaluans on Wikieducator thread (scroll down) http://groups.google.co.nz/group/wikieducator/browse_thread/thread/410a6bb8eaf5aa66 (pointed out by Leigh himself on his blog) On Thu, Dec 4, 2008 at 4:39 AM, Eben Eliason [EMAIL PROTECTED] wrote: Good summary. On Wed, Dec 3, 2008 at 7:17 AM, Jameson Quinn [EMAIL PROTECTED] wrote: Here is my list of complaints from that evaluation, which was obviously using a 600-series OS version. not traditional desktop metaphor Fact. no tabbed browsing I have a proposal for this which I've been meaning to mockup. I'm adding it to my todo list now. flaky wireless A lot better, these days. some bad machines: difficulty turning on and peeling mousepad. flaky mouse has a mouse instead of mouse-alternatives (?) Hardware. (Still important, being worked on.) popup menus too slow This is something we should look into. Actually, we've slowed down their appearance since then, because we found that people were often waiting for the menu, instead of clicking directly on the icon/button directly. We've also added the right-click to reveal the palette immediately. I think the current state is reasonable, but more feedback on this is welcomed. activity startup too slow Improving a little. see address in browser bar should be easier (fixed) Yup. hard to save to USB. Should be accessible from within an activity. Yup. scroll bars too small, especially for subsidiary panes (interesting issue for grab key, BTW) Right. The grab key continually eludes. I know Erik worked on it for a bit, but I don't know the current status or if it's possible to roll it into a build soon. If we aren't going to have the grab key, we truly are going to have to increase the size of the scroll bars. I may have missed a few, but I think that most of these are either already the focus of effort (and progress) or have been decided against by many here. The one I bolded is I think a useful one: why not have a keep to USB and keep to SD option in the keep dropdown menu in the activity toolbar? You're absolutely right, and that has definitely been the plan. External devices have never gotten any polish; hopefully as we redesign the manner in which they work and interact with the Journal we can also add these types of features. - Eben Jameson On Wed, Dec 3, 2008 at 2:53 AM, Edward Cherlin [EMAIL PROTECTED] wrote: FYI. -- Forwarded message -- From: Valerie Taylor [EMAIL PROTECTED] Date: Mon, Dec 1, 2008 at 7:13 AM Subject: [OLPC-SF] Not new, but needs to be addressed To: [EMAIL PROTECTED] This just in from a well-meaning colleague who was using XOs. There are lots of issues identified here. There is a serious failure-to-communicate. These are real concerns for many people and this is what they hear. It is easy to dismiss this as Leigh's problem, but it isn't his alone. Everyone of us associated with OLPC needs to do a better job at bridging this gap. Are there good sources of information that address these issues and guidelines that would ease the transition from PC to XO in situations like this? http://learnonline.wordpress.com/2008/12/01/my-experience-with-olpc-in-tuvalu/ ..Valerie ___ OLPC-SF mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/olpc-sf -- Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name And Children are my nation. The Cosmos is my dwelling place, The Truth my destination. http://wiki.sugarlabs.org/go/User:Mokurai ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Calendar goodness
On 04.12.2008, at 17:08, David Farning wrote: On Fri, Dec 5, 2008 at 2:09 AM, Edward Cherlin [EMAIL PROTECTED] wrote: On Tue, Nov 11, 2008 at 5:48 AM, David Farning [EMAIL PROTECTED] wrote: Check out the new wiki feature Bernie add to w.s.o. http://sugarlabs.org/go/WikiTeam/Meetings We can now embed gcalendars directly into the wiki:) I added a page for a calendar of conferences of interest to our communities. http://sugarlabs.org/go/Events Edward do you know if it is possible to embede a weekly gcalendar? A weekly calendar would be more useful and take up less space on some of the team pages. I just never figured out how to do it. Oh. There actually is something on that page, if you try Firefox. It's blank in Safari, so I wondered what the fuzz is about ... - Bert - ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Calendar goodness
On Thu, Dec 4, 2008 at 11:08, David Farning [EMAIL PROTECTED] wrote: On Fri, Dec 5, 2008 at 2:09 AM, Edward Cherlin [EMAIL PROTECTED] wrote: On Tue, Nov 11, 2008 at 5:48 AM, David Farning [EMAIL PROTECTED] wrote: Check out the new wiki feature Bernie add to w.s.o. http://sugarlabs.org/go/WikiTeam/Meetings We can now embed gcalendars directly into the wiki:) I added a page for a calendar of conferences of interest to our communities. http://sugarlabs.org/go/Events Edward do you know if it is possible to embede a weekly gcalendar? A weekly calendar would be more useful and take up less space on some of the team pages. I just never figured out how to do it. It would appear this isn't likely to be do-able... According to the source (http://www.mediawiki.org/wiki/Extension:GoogleCalendar): Problems with this extension [edit] Ampersand problem Google allows extra features like custom sizing of the calendar, viewing other calendars within the same iframe and removing the google logo. Eg. Adding chrome=NAVIGATION removes the google logo. However the problem with this is that it requires a pure and when the iframe is written into the page the gets converted to an amp; in the html page source, which is the ampersand problem. And so the iframe cannot recognize the query after the amp; because it needs a pure . Thus the extra google calendar features do not work correctly when viewed using this extension. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Running local Sugar workshops
Maybe we advertise at our pilot schools and at HGSE and the other ed schools in the area. If we even got only 5-10 teacherish types it would be a success and that really shouldn't be hard. Well, the teachers/students/parents from the pilot schools organizing the workshop should be the ones advertising for participants (focused on teachers as attendees?) from the pilot schools, HGSE, and other ed schools in the area, but yes. :) How long a workshop? What time and day would be best for our audience? Let's say either a full day or a half day, and let the people running the workshop decide the rest. We should be able to grab space as part of the FUDCON and general conferences right? I think so? I'm not planning either so I don't actually know, but we can find *some* space, FUDCON or not; it'll happen. --Mel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Local Labs - Self Replicating
How do we spread and expand Sugar's reach? How about designing Sugar Labs to self replicate? We are getting pretty close. How did Sugar Labs start? With a mission, a vision, some values, a wiki, a mailing list, and a handful of passionate people who shared the mission, vision and values. Sugar Labs then leveraged the Sugar code base and much of its original infrastructure from OLPC. How do you start a Local Labs? The same way:) From a 'people' point of view, a Local Lab is a collection of people, located in a geographical area, who share Sugar Lab's mission (or a sub-set of the mission), vision, and values. From an 'organizational' point of view, a Local Lab can take Sugar Labs team structure[1] and modify it to meet local needs. If Sugar Labs - Colombia is not interested in development, that is fine. The development team can be left as a stub and all of the effort can be shifted into the deployment team or vice versa. david 1. http://sugarlabs.org/go/Sugar_Labs/Teams ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
