Re: [sugar] Injecting Code into main Sugar GUI routine
On 7/6/08, Zach Riggle [EMAIL PROTECTED] wrote: I am a student working on a Google Summer of Code project, sugarbot (more information here: http://code.google.com/p/sugarbot/). I am currently at a stage where I need to be able to hook into the Sugar GUI, to automate the process of launching Activities (e.g. simulate a mouse-click on the activity list, scroll down, click on the Activity name). The process of automating the GUI is straightforward and should not be a problem, however I do not know where the best location would be to inject my code, or if there would be a way to create a launcher that, in turn, launched the Sugar interface inside of its own process. How do you plan to simulate the UI events? Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] super user privileges for speech-dispatcher and location of configuration files for olpc
Hemant Goyal wrote: Hi, We want to run the speech-dispatcher daemon service on the XO for providing a speech synthesis environment in the laptop. For our purpose we want to modify the configuration file of speech-dispatcher in /etc/speech-dispatcher/speechd.conf from sugar-control panel. sugar-control panel requires the configuration file to be user writable (which is not the case with the file in /etc/speech-dispatcher). The idea that we are getting at the moment is to maintain a copy of /etc/speech-dispatcher/speechd.conf somewhere in /home/olpc/.folder/speechd.conf. and start the daemon service by pointing to this directory instead of /etc/speech-dispatcher. This would allow us to modify the configuration file from sugar-control panel. I have been thinking a bit about this. When we have a copy in home and this is read by a daemon that is run as root this sounds be odd. Maybe we can run the daemon in the user session to accomplish this. Can someone with a deeper knowledge on this issue comment? Thanks, Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Injecting Code into main Sugar GUI routine
On Mon, Jul 7, 2008 at 11:23 AM, Zach Riggle [EMAIL PROTECTED] wrote: I would prefer not to modify the code to Sugar directly. I was thinking of an approach that would allow me to launch sugar-jhbuild /inside/ of a running Python script. This way, I can use the GUI hooks that I already have (and don't have to worry about breaking the code). However, Sugar seems a bit fork-happy. From where is main.py called? Ok, then see bin/sugar-emulator and src/emulator.py, that ultimately calls src/main.py. Perhaps we should move the call to gtk.main() outside main.py, so people like you can initialize the shell, do something else, and then call themselves the main loop. Hope you have enough pointers for now, if you need to change some of the sugar code to better accomodate your use case, feel free to propose those changes or if they are simple enough, just post a patch. Regards, Tomeu On Jul 7, 2008, at 3:04 AM, Tomeu Vizoso wrote: Hi Zach, On Mon, Jul 7, 2008 at 12:20 AM, Zach Riggle [EMAIL PROTECTED] wrote: I am a student working on a Google Summer of Code project, sugarbot (more information here: http://code.google.com/p/sugarbot/). I am currently at a stage where I need to be able to hook into the Sugar GUI, to automate the process of launching Activities (e.g. simulate a mouse-click on the activity list, scroll down, click on the Activity name). The process of automating the GUI is straightforward and should not be a problem, however I do not know where the best location would be to inject my code, or if there would be a way to create a launcher that, in turn, launched the Sugar interface inside of its own process. Depends a bit on what that injected code would do. Supposing you want to run it after everything has already been set up, try putting your code in src/main.py, probably just before the main loop is started (but outside the try..except block). http://dev.laptop.org/git?p=sugar;a=blob;f=src/main.py Additionally, if anyone can point me in the direction of any materials related to the Sugar startup procedures/process, it would be greatly appreciated. Sorry, we have very little docs right now, but any help is appreciated. Good luck, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Problem with Activity Development
Hi Due to the git repository structure I have to keep a different directory structure than the default directory as recommended by the wiki.The contents of the manifest file are mentioned here src/question.xml src/viewer2.py src/connection.py src/EducationalToolkitActivity.py src/parse.py src/model.py src/notebook.py src/model.pyc src/answer.xml src/parse.pyc data/teacher.gif data/sample.xml data/teacher orig.png data/true.png data/false.png data/button.png data/test.xml data/teacher.png setup.py MANIFEST activity/activity-EducationalToolkit.svg activity/activity.info diagram/system_dia.png diagram/Use_Case2.dia diagram/system_dia3.dia diagram/Use_Case2.png diagram/system_dia3.png diagram/Use_Case1.png diagram/Use_Case1.dia diagram/Connection.dia diagram/system_dia2.png diagram/system_dia2.dia diagram/system_dia.dia EducationalToolkitActivity.py imports parse and model .py But tle log shows module missing.I have also edited the activity-info file.But still it shows No module named as parse Thanks -- Ankuj Gupta ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] (another) WebKit port of Browse
Hi Folks, I spent a couple hours yesterday taking out Gecko from Browse, and putting in WebKit. Luckily, this was made easy by some PyWebKitGtk bindings from Jan Alonzo (cc'ed). The example included with the bindings is actually based off WebKit ;). Some initial documentation is here: http://wiki.laptop.org/go/Browse/WebKit things work pretty well in general, but gmail chokes, possibly due to gnash. if you just want to try it (on an F9 based joyride), the bundle is: http://dev.laptop.org/~bobbyp/Browse-92.xo yours, Bobby Powers Intern Extroadinare (irc: nteon) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Sugar Digest 2008-07-07
=== Sugar Digest === 1. Milan update: Minutes of the Sugar Labs meeting are posted in the wiki (Please see http://wiki.sugarlabs.org/go/Sugar_Labs/Meeting_Minutes-30-06-2008). Topics covered in the meeting included: * Governance and the Software Freedom Conservancy * What are we (Sugar Labs) trying to accomplish? * Sugar distributions: what are the issues? * Sugar Labs look and feel: a graphic design review * Sugar on mobile phones: is it possible? does it make sense? * Sugar Labs: models of support * Fund-raising: how much and from whom? One byproduct of the meeting was further refinement of the Sugar Labs governance pages in the wiki (Please see http://wiki.sugarlabs.org/go/Sugar_Labs/Governance) and the accumulation of an initial membership list for Sugar Labs (Please see http://wiki.sugarlabs.org/go/Sugar_Labs/initial_members_list). 2. Intercambio de experiencias (Exchange of experiences): There is starting to be a nice exchange of classroom experiences among teachers on the olpc-sur mailing list (in Spanish). Teachers helping teachers. 3. Regional efforts: There are a number of people discussing regional programs for Sugar development and support. Such programs are in line with the Sugar Labs vision. It is extremely important to push development and support into the hands of local organizations because: (1) it scales; (2) the detailed knowledge is local; (3) it helps the local economy; (4) it sets in motion independent agencies with a common goal and yet autonomy of action, which leads to innovation. Please bring these discussions to the Education mailing list so that we can leverage each other's ideas. 4. What works? What doesn't?: Roy Zimmermann is working in collaboration with the World Bank on a USAID-funded project to analyze the role of ICT on education in developing countries. If you have examples you think should be included in his survey, please upload them to www.ictimpact.org. === Community jams and meetups === 5. India Day: There will be an OLPC Day in India on 4 August in a venue to be determined. On the agenda is a discussion on learning by David Cavallo. ===Tech Talk=== 6. Development release: Today (Monday, 7 July) is the date for the next development release. Simon Schampijer asks maintainers to please provide source code tarballs by the end of the day for the following modules: http://wiki.sugarlabs.org/go/ReleaseTeam/Roadmap#Glucose_Modules http://wiki.sugarlabs.org/go/ReleaseTeam/Roadmap#Fructose_Modules And to please announce them as explained here: http://wiki.sugarlabs.org/go/ReleaseTeam#Module_release 7. SocialCalc: KS Preeti has done a thorough review of the latest release of SocialCalc. Such feedback is enormously helpful to developers. Please help us by reviewing your favorite Activities and filing detailed reports either to the wiki or the Sugar list. 8. Gears: David Van Assche continues to make progress on getting Google Gears running under Sugar. 9. Xterm: Michael Stone posted Blake Setlow's recipe for increasing the font size in an xterm window: LANG=C xterm -fa DejaVu LGC Sans Mono -fs 8 +sb 10. Etoys Quickguides: Ted Kaehler reports that the PDF file containing all of the Etoys QuickGuides is now only 4MB (instead of 22MB) thanks to a suggestion by Tim Falconer (See 11. ReviewBoard: Sayamindu Dasgupta has set up an instance of ReviewBoard at http://xenguest1.laptop.org/ for exploring. A basic workflow for using ReviewBoard is available online (http://code.google.com/p/reviewboard/wiki/UserBasics). 12. Misc: Tomeu Vizoso reviewed and pushed out patches this week and has begun working on Journal object transfer. Marco Pesenti Gritti is taking a well-deserved vacation. Daniel Drake addressed issues associated with the Fedora 9 rebase and has some code that brings the Record activity back into a somewhat usable state. === Sugar Labs === 13. Self-organizing map (SOM): Gary Martin has generated another SOM from the past week of discussion on the IAEP mailing list (Please see http://wiki.sugarlabs.org/go/Image:2008-June-28-July-4-som.jpg). -walter ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar Digest 2008-07-07
On Mon, Jul 7, 2008 at 6:54 PM, Walter Bender [EMAIL PROTECTED] wrote: 12. Misc: Tomeu Vizoso reviewed and pushed out patches this week and has begun working on Journal object transfer. Unfortunately, not yet. I have it in my TODO list because I tried to start work on this for the 0.82 release, but there was not enough time. These days I'm just fixing bugs, reviewing patches and doing new source releases for Sugar and rpms for OLPC. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] An activity for etymology?
Here's an idea for an activity. An activity that takes a word in a local language and shows its etymological map as the word travels across cultures, perhaps with an overlay of the world map. For example, the word Sugar (no pun intended) has an interesting etymological evolution. From Wikipedia: In the case of sugar, the etymology http://en.wikipedia.org/wiki/Etymology reflects the spread of the commodity. The English http://en.wikipedia.org/wiki/English_language word sugar originates from the Arabic http://en.wikipedia.org/wiki/Arabic_language and Persian http://en.wikipedia.org/wiki/Persian_language word /shakar/,^[4] http://en.wikipedia.org/wiki/Sugar#cite_note-3 itself derived from Sanskrit http://en.wikipedia.org/wiki/Sanskrit /Sharkara/.^[5] http://en.wikipedia.org/wiki/Sugar#cite_note-Hassan-4 It came to English by way of French http://en.wikipedia.org/wiki/French_language, Spanish http://en.wikipedia.org/wiki/Spanish_language and/or Italian http://en.wikipedia.org/wiki/Italian_language, which derived their word for sugar from the Arabic and Persian /shakar/ (whence the Portuguese http://en.wikipedia.org/wiki/Portuguese_language word /açúcar/, the Spanish word /azúcar/, the Italian word /zucchero/, the Old French word /zuchre/ and the contemporary French word /sucre/). (Compare the OED http://en.wikipedia.org/wiki/Oxford_English_Dictionary.) The Greek http://en.wikipedia.org/wiki/Greek_language word for sugar, /zahari/, means pebble. So, sharkara (sanskrit)- shakar (arabic)- sucre (French) and so on. On my recent trip to Italy, I saw something that provoked an Aha! moment. I was in my hotel room, and the information posted on the door had the word Room Chamber and Camera. I quickly realized why a photo-taking device was called Camera (a small dark chamber), but a few seconds later I realized that in Hindi, a room is called Kamaraa. Its a word I've used all my life, without realizing where it came from. I am still not sure if the etymology is connected. but kamaraa is likely of Urdu/Persian/Arabic origin, and hence it must have traveled across cultures from Europe to India. More at http://www.etymonline.com/index.php?term=camera Of course, there are more popular ones such as shampoo (http://www.etymonline.com/index.php?term=shampoo), juggernaut (http://www.etymonline.com/index.php?term=juggernaut), etc. but the kamaraa-camera link for me was very exciting. I think many children will find such discoveries exciting too! Sameer -- Dr. Sameer Verma, Ph.D. Associate Professor of Information Systems San Francisco State University San Francisco CA 94132 USA http://verma.sfsu.edu/ http://opensource.sfsu.edu/ ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Terminal-13 is out
Hello everyone. A new version (version 13) of Terminal Activity has been released. You can get the sources at http://dev.laptop.org/pub/sugar/sources/terminal-activity/Terminal-13.tar.bz2 This release contains new translations from our translator community. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] read-activity v47 is out
Hi all, a new release of the Read activity has been made: http://dev.laptop.org/pub/sugar/sources/read-activity/read-activity-47.tar.bz2 Contains translation updates and some new languages. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] journal-activity 94 is out
Hi, a new release is out: http://dev.laptop.org/pub/sugar/sources/journal-activity/journal-activity-94.tar.bz2 Changes from release 92 (93 wasn't publicly released) contain some small bug fixes and translations for some new languages. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] sugar-datastore 0.8.3 released
Hi, version 0.8.3 of sugar-datastore has been released: http://dev.laptop.org/pub/sugar/sources/sugar-datastore/sugar-datastore-0.8.3.tar.bz2 Since the last release, two scripts have been added that allow for adding and retrieving items from the command line, these scripts have been contributed by Reinier Heeres and Philip Bordelon. Thanks! Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] sugar-toolkit 0.81.6 has been released
Hi all, a new sugar-toolkit release is available at: http://dev.laptop.org/pub/sugar/sources/sugar-toolkit/sugar-toolkit-0.81.6.tar.bz2 This release contains lots of bug fixes as well as translations for new languages and some updates to existing ones. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] sugar-base 0.81.2 is out!
Hi all, a new release of sugar-base can be found here: http://dev.laptop.org/pub/sugar/sources/sugar-base/sugar-base-0.81.2.tar.bz2 In this release, sugar-base has gained its own translation module and some languages have already been contributed. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Chat-42 released
I've released Chat-42, available at: http://dev.laptop.org/pub/sugar/sources/chat-activity/Chat-42.tar.bz2 http://dev.laptop.org/~morgan/bundles/Chat-42.xo NEWS: * #6036: Show timestamp as elapsed time instead of date (morgs) * Updated translations: fr, mvo, pis, af, sd, pap, tpi, ar, de Regards Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Feature/string freeze exception.
Hi, I'd like a Sugar freeze exception for the changes being discussed in: http://dev.laptop.org/ticket/7434 Thanks, - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Feature/string freeze exception.
On Mon, Jul 7, 2008 at 9:26 PM, Chris Ball [EMAIL PROTECTED] wrote: Hi, I'd like a Sugar freeze exception for the changes being discussed in: http://dev.laptop.org/ticket/7434 In my opinion, it's important for sugarlabs to get this feature in because it will significantly improve the usability of the OLPC platform, the only shipment of Sugar existing today. Eben, are you ok with the changes to the UI? Sayamadindu, how can we add these strings without disrupting too much the translation efforts? Any other opinions? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Feature/string freeze exception.
I agree. Seems like an important usability feature that should be there and there is low risk. -walter On Mon, Jul 7, 2008 at 3:53 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Mon, Jul 7, 2008 at 9:26 PM, Chris Ball [EMAIL PROTECTED] wrote: Hi, I'd like a Sugar freeze exception for the changes being discussed in: http://dev.laptop.org/ticket/7434 In my opinion, it's important for sugarlabs to get this feature in because it will significantly improve the usability of the OLPC platform, the only shipment of Sugar existing today. Eben, are you ok with the changes to the UI? Sayamadindu, how can we add these strings without disrupting too much the translation efforts? Any other opinions? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar mtg reminder, 3rd July 2008 --- 17.00 UTC ---, irc.freenode.net, #sugar-meeting
Hi All, Very nice schedule and patch submission guidelines! Its great work and very helpful in showing how to create a transparent process that encourages people to participate. A few questions is the new Sugar GUI available in Spanish, how about other languages? Can you add a step in the process to explain when other languages will be available (BTW Sayamindu is working on translation process/steps for the XO overall and you should probably review that when its available). The reason I'm asking is that I want to track when I can share the new GUI with some key deployments. Thanks, Greg S Date: Thu, 03 Jul 2008 13:29:15 +0200 From: Simon Schampijer [EMAIL PROTECTED] Subject: [sugar] Sugar mtg reminder, 3rd July 2008 --- 17.00 UTC --- irc.freenode.net, #sugar-meeting To: Sugar List [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Todays meeting will feature: Topics: What's left for the upcoming release: http://wiki.sugarlabs.org/go/ReleaseTeam/Roadmap#Schedule Changes in the review process: http://wiki.sugarlabs.org/go/DevelopmentTeam/CodeReview#Patch_submission Best, Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] sugar 0.81.6 has been released
Hello, sugar 0.81.6 is out! The sources can be found here: http://dev.laptop.org/pub/sugar/sources/sugar/sugar-0.81.6.tar.bz2 * #7438 sugar shuts down when you click Restart * #7365 Invites not working * #7248 Speaker device has inconsistent behavior * #7339 CPU Spins after starting an activity * #7015 Add proper alignment support to the tray control * #5613 Cannot set non-ASCII nick name * #7046 Deleting activity bundle with journal leaves it showing in Home list view until reboot * #7391 Make the search field in Home reveal the list view * #7248 Speaker device has inconsistent behavior * #7272 Notifications are redundant with new launching feedback * #7273 Activity icons remain colored after launch (Note: this list was generated with the new release report tool ./sugar-jhbuild report -t release sugar-0.81.6) Thanks as well to the translation team for adding new languages and updating existing ones. Best, Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Relationships w/ upstream.
Since a conversation on IRC got unexpectedly heated, let me restate my personal philosophy for OLPC's relationships with upstream: (a) I believe that we should put OLPC's goals *first*, and endeavor to ensure that we are always meeting the actual needs of our clients, forking whenever upstream's goals/process/schedule interfere with OLPC's ability to actually ship software responsive to its needs and its client's needs. (b) That said, I acknowledge that forks have a huge long-term cost, and that in order to effectively develop software with a small group of developers we can't afford to keep paying fork costs over and over again. Thus, we also have a responsibility to work closely with upstream to prevent the necessity of a fork. These goals are in conflict, and my position in arguments has changed over time, depending on whether the other side is being adequately represented. These days, I rely on Dennis Gilmore to hold firm to the forks must be prevented at all costs side of the argument, which frees me to make the OLPC's goals first argument -- the compromises between Dennis and I then chart the middle ground between the two conflicting goals: ensuring that we don't let process bureaucracy prevent us from actually solving problems, while at the same time ensuring that our zeal to fix it, and fast doesn't prevent us from making the investments in upstream needed to reduce our long-term costs. To the extent that sugarlabs is going to operate as a true upstream, they need to be cognizant of the fact that OLPC will at times put its goals/process ahead of upstream's goals/process. In theory, this means that OLPC would probably fork sugarlab's upstream packages so that it can, for example, make important changes to sugar that conflict with upstream's goals. This is complicated by the fact that the same people would currently maintain both the upstream sugar packages and the OLPC forked packages, and they may find it difficult to wear two different hats at the same time: evaluating a potential patch in terms of is it best for sugarlabs on one hand, and in terms of is it best for OLPC on the other. At the moment, I've been assured that upstream does *not* want to fork sugar, and in fact will go out of its way, making special exceptions for OLPC patches which conflict with sugar freezes. So this email is not particularly responding to a *present* problem: it is instead pointing out the possibility of future conflict, and noting that sugarlabs folks should not be surprised to find that OLPC's goals/needs conflict with their own, and that OLPC may in the future even fork sugar. This is not because we are attributing malign intent to the sugar developers (as was claimed at one point) -- in fact, the very opposite: the purpose of creating an OLPC-specific fork would be to allow sugar to better pursue its independent schedules. In this way, ultimately, sugar would be treated just like all the rest of our upstreams. That said, forks cost a lot. I hope we will not have to fork sugar, even in minor ways, anytime soon. --scott (Context: current high-priority sugar bugs for 8.2: http://dev.laptop.org/ticket/7380, http://dev.laptop.org/ticket/7381; fixing these might conflict with sugar's self-imposed string freeze, even though 8.2 has not yet frozen its strings.) -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Feature/string freeze exception.
Hi, In my opinion, it's important for sugarlabs to get this feature in because it will significantly improve the usability of the OLPC platform, the only shipment of Sugar existing today. Thanks. Eben, are you ok with the changes to the UI? Sayamadindu, how can we add these strings without disrupting too much the translation efforts? I don't think the UI is necessarily final. In OLPC terms, I'm offering this patch just before feature freeze happens -- it exposes the feature we need, but the UI or strings might change, and we might add something to the battery panel applet as well. It sounds like the level of OLPC's current freeze (wanting new features in the build for testing that aren't necessarily ready to ship) doesn't match well with the Sugar roadmap; I'm not sure how to resolve that. (With that in mind, I don't think we should mobilize translators for these strings yet. I think they're unlikely to stay as-is.) - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Relationships w/ upstream.
To the extent that sugarlabs is going to operate as a true upstream, they need to be cognizant of the fact that OLPC will at times put its goals/process ahead of upstream's goals/process. I'll be presumptuous and speak on behalf of upstream. Sugar developers are cognizant of the needs of OLPC and will go out of their way to make sure that the (by far) largest Sugar deployment is successful. Has this been questioned? At the moment, I've been assured that upstream does *not* want to fork sugar, and in fact will go out of its way, making special exceptions for OLPC patches which conflict with sugar freezes. At present, there is no reason to fork Sugar that I am aware of and as with any project, there is a mechanism for requesting special exceptions, for example CJB's request regarding OHM and the Sugar Control Panel. It is hard to tell from #7381 what the heated discussion on IRC may have been about. There is certainly not consensus regarding the merits of the free-form Home View, but it is being accepted upstream, AFAIK. We do plan some user studies of this View, the results of which may (or may not) be compelling evidence to reopen this decision. -walter ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Relationships w/ upstream.
On Mon, Jul 7, 2008 at 5:37 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Since a conversation on IRC got unexpectedly heated, let me restate my personal philosophy for OLPC's relationships with upstream: I am surprised this got heated, you are right, and this isn't even controversial. This tension - fork / innovate ahead of upstream is a prevalent practice in FOSS. OLPC is a participant with a relatively well defined client and use scenarios/cases and we innovate and customise (at our cost) in ways that upstreams cannot or do not want to risk. If it pans out, the upstream can take it, if the feature / patch / ugly hack doesn't pan out, don't take it. Failure for free (for the upstream). Our incentives are clear - we want to bet carefully, and to win (in terms of forks that work out well enough that some version of it gets merged in upstream). To the extent that sugarlabs is going to operate as a true upstream, they need to be cognizant of the fact that OLPC will at times put its ... At the moment, I've been assured that upstream does *not* want to fork sugar, and in fact will go out of its way, making special exceptions for OLPC patches which conflict with sugar freezes. So this email is I though we were still our own upstream wrt sugar, but great to hear things are looking better for Sugarlabs. Probably means the sugar team gets larger :-) That said, forks cost a lot. Definitely. I am all for picking carefully which ones to go for :-) cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Relationships w/ upstream.
On Mon, Jul 7, 2008 at 4:56 PM, Walter Bender [EMAIL PROTECTED] wrote: I'll be presumptuous and speak on behalf of upstream. Sugar developers are cognizant of the needs of OLPC and will go out of their way to make sure that the (by far) largest Sugar deployment is successful. Has this been questioned? No, and it's good to hear regardless. At the moment, I've been assured that upstream does *not* want to fork sugar, and in fact will go out of its way, making special exceptions for OLPC patches which conflict with sugar freezes. At present, there is no reason to fork Sugar that I am aware of and as with any project, there is a mechanism for requesting special exceptions, for example CJB's request regarding OHM and the Sugar Control Panel. It is hard to tell from #7381 what the heated discussion on IRC may have been about. There is certainly not consensus regarding the merits of the free-form Home View, but it is being accepted upstream, AFAIK. We do plan some user studies of this View, the results of which may (or may not) be compelling evidence to reopen this decision. Yes, things are going well right now, and the current issues are not problematic. I was just trying to preemptively communicate expectations, so that any future minor fork of sugar is not seen as adversarial, but instead a natural solution to allow decoupled development -- in the same way we use small forks to handle such issues in other components (such as telepathy, initscripts, etc). I think we're all agreed that even small forks have large long-term costs, and we'd prefer to avoid them where at all possible -- which we all agree seems to be the case at present. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Relationships w/ upstream.
On 7/7/08, C. Scott Ananian [EMAIL PROTECTED] wrote: On Mon, Jul 7, 2008 at 4:56 PM, Walter Bender [EMAIL PROTECTED] wrote: I'll be presumptuous and speak on behalf of upstream. Sugar developers are cognizant of the needs of OLPC and will go out of their way to make sure that the (by far) largest Sugar deployment is successful. Has this been questioned? No, and it's good to hear regardless. +1 on what walter said. At the moment, I've been assured that upstream does *not* want to fork sugar, and in fact will go out of its way, making special exceptions for OLPC patches which conflict with sugar freezes. At present, there is no reason to fork Sugar that I am aware of and as with any project, there is a mechanism for requesting special exceptions, for example CJB's request regarding OHM and the Sugar Control Panel. It is hard to tell from #7381 what the heated discussion on IRC may have been about. There is certainly not consensus regarding the merits of the free-form Home View, but it is being accepted upstream, AFAIK. We do plan some user studies of this View, the results of which may (or may not) be compelling evidence to reopen this decision. Yes, things are going well right now, and the current issues are not problematic. I was just trying to preemptively communicate expectations, so that any future minor fork of sugar is not seen as adversarial, but instead a natural solution to allow decoupled development -- in the same way we use small forks to handle such issues in other components (such as telepathy, initscripts, etc). That makes totally sense to me. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Relationships w/ upstream.
On Mon, Jul 7, 2008 at 6:17 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: I think we're all agreed that even small forks have large long-term costs, and we'd prefer to avoid them where at all possible -- which we all agree seems to be the case at present. Here I disagree - small and medium sized forks can be low cost, and highly dynamic, specially when you are using a merge-friendly SCM (git!). The last 6 years of my life have been working with projects that ran ahead of their upstreams -- mostly moodle -- and things were horribly painful before git. Once git was usable, it just became a matter of a bit of discipline. - Long term forks are death, short term forks are opportunity. - Sugar isn't a forking problem :-) as olpc team and sugar team overlap significantly. - I think we are overstressing about a bunch of strings. People rightly say that forks are costly and nightmarish, but they are talking about a few thousand patches, and deltas of 10K lines, that when merged resulted in a few hundred gnarly conflicts. Strings you say? I landed 130 patches worth 4K lines of diff between 1.8 and 1.9 of moodle, rewriting one of the core libs completely :-) cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Browse 92 has been released
Hello, a new Browse activity is out! sources: http://dev.laptop.org/pub/sugar/sources/web-activity/Browse-92.tar.bz2 packaged: http://dev.laptop.org/~erikos/bundles/Browse-92.xo Note: The name change! The new bundlebuilder kindly forced me too ;) News: * #7281 Browse autocompletion should allow editing of suggestions * #7427 Downloads broken in Browse (interface change) * #7280 Browse autocompletion makes it impossible to type some URLs Thanks as well to the translation team for adding new languages and updating existing ones. Regards, Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Relationships w/ upstream.
On Mon, Jul 7, 2008 at 5:29 PM, Martin Langhoff [EMAIL PROTECTED] wrote: On Mon, Jul 7, 2008 at 6:17 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: I think we're all agreed that even small forks have large long-term costs, and we'd prefer to avoid them where at all possible -- which we all agree seems to be the case at present. Here I disagree - small and medium sized forks can be low cost, and highly dynamic, specially when you are using a merge-friendly SCM (git!). I have at various times longed for a way to make small forks from upstream less painful, so that we can use them more aggressively. But, putting on my other hat (the Dennis hat), I'd say that there's a big difference between no fork and some fork, even though (as you point out) there may be very little difference between a small and medium fork, once you've got one. There's a lot of mental and bookkeeping overhead to make sure that your small fork stays in place, gets updated properly, that end users can distinguish between the forked version and upstream when they do maintenance or development, etc, etc. - I think we are overstressing about a bunch of strings. People We are probably overstressing. And I probably overreacted on IRC, triggering the conflict in the first place. We all seem to agree now, at least. =) --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Relationships w/ upstream.
On Mon, 2008-07-07 at 16:37 -0400, C. Scott Ananian wrote: Since a conversation on IRC got unexpectedly heated, let me restate my personal philosophy for OLPC's relationships with upstream: (a) I believe that we should put OLPC's goals *first*, and endeavor to ensure that we are always meeting the actual needs of our clients, forking whenever upstream's goals/process/schedule interfere with OLPC's ability to actually ship software responsive to its needs and its client's needs. (b) That said, I acknowledge that forks have a huge long-term cost, and that in order to effectively develop software with a small group of developers we can't afford to keep paying fork costs over and over again. Thus, we also have a responsibility to work closely with upstream to prevent the necessity of a fork. I don't think we need to worry very much about this issue. Once we, OLPC and SL, get our release schedules and process worked out. These issues will work themselves out. Pretty soon, Sugar Labs will be pushing a new release out every six months. There was a thread a few weeks ago about OLPC releasing every six months and SL basing our release on the lead time OLPC needs do prepare a Sugar tarball for release. To keep things in perspective, remember the horrendous release problems Debian had a few years ago:) They seem to have gotten them pretty well resolved lately. dfarning ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Mon, Jul 7, 2008 at 12:39 PM, Bobby Powers [EMAIL PROTECTED] wrote: I spent a couple hours yesterday taking out Gecko from Browse, and putting in WebKit. Luckily, this was made easy by some PyWebKitGtk Just repeating in public what I leaned over and told m_stone and cjb: I'd rather see us just give up on Browse and ship and appropriately configured Firefox. I just can't see OLPC devoting enough developer resources long-term to maintain a competitive browser. I understand that the major benefit of WebKit is speed and (memory, NAND) size. I'd like to see a quantitative comparison against both our current gecko-based browser and against firefox, so that we can make a more informed decision re: whether it is still to our benefit to ship a bespoke browser. --scott (mstone reports that 'yum install firefox' and 'firefox' is a decent basis for comparison, although we can tweak firefox's configuration and package it as an RPM to get a nicer sugar lookfeel if we really wanted to pursue this route.) -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
Why does automatic authentication require a custom browser? Client certificates work well for this function in ordinary web applications (assuming a properly configured server). As to collaborative browsing, that use case should be balanced against all the available applications that having a standard Firefox enables painlessly. Where is a user story of collaborative browsing (as contrasted to a shared bookmark repository) documented? On Mon, Jul 7, 2008 at 3:10 PM, Martin Langhoff [EMAIL PROTECTED] wrote: On Mon, Jul 7, 2008 at 6:56 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: I'd rather see us just give up on Browse and ship and appropriately configured Firefox. I just can't see OLPC devoting enough developer Not so fast! The XS deliverables need a custom browser on the XO for reasons we were discussing last Thursday :-) If we want - automagic authentication with the XS - collaborative browsing (which can get better than what we have) we need a custom, bespoke, forked, evil, lasers-on-sharkies-heads browser. Call it Betty if you want, but we need it. m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel -- Frisbeetarianism is the belief that when you die, your soul goes up on the roof and gets stuck -- George Carlin ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
Client certs can be used for authentication with no changes to a Firefox browser or an Apache server. GTK based as well as web based software to create certs also already exists. What sort of patch are you looking for? I could certainly provide a page running in an apache server to validate a request for and implant a client cert in a Firefox browser. The issue of certificate creation needs a little more discussion, not because it is difficult or requires a lot of new software to execute, but because it is important to be clear about the requirements. When you describe the overhead, do you mean the overhead of creating the certs? Examining them when someone first logs on? I raised this alternative because you said that a bespoke browser was a requirement to have automatic authentication with the school server. To me, the benefits of running a standard browser are so substantial that this trade off should be considered. On Mon, Jul 7, 2008 at 3:39 PM, Martin Langhoff [EMAIL PROTECTED] wrote: On Mon, Jul 7, 2008 at 7:20 PM, Carol Lerche [EMAIL PROTECTED] wrote: Why does automatic authentication require a custom browser? Client certificates work well for this function in ordinary web applications (assuming a properly configured server). I haven't delved into this deeply yet, but I suspect that, while I am fond of client certs, they won't work - SSL network and CPU overhead and sidestepping PKI madness for server certs. More on this when I get to implement it. Now, anyone who wants to have a strong say on how I am developing this is free to start implementing it ahead of me, and showing me some fantastic patches :-) cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- Frisbeetarianism is the belief that when you die, your soul goes up on the roof and gets stuck -- George Carlin ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
The UI seems pretty important to me, but obviously that's a matter of taste. Not everyone likes tabbed browsing. Correct operation of websites that fail with the extant browser. Direct availability of plugins and addons. One example: scrapbook, a superb research tool. Another example Google Gears (according to a recent mail being ported, presumably because the browser is not standard). I am not familiar with the Firefox codebase, and perhaps all these things are directly available so long as the Firefox 3 engine is there, but if so, there desperately needs to be a detailed body of documentation telling how to access these capabilities. On Mon, Jul 7, 2008 at 3:56 PM, Bobby Powers [EMAIL PROTECTED] wrote: 2008/7/7 Carol Lerche [EMAIL PROTECTED]: Client certs can be used for authentication with no changes to a Firefox browser or an Apache server. GTK based as well as web based software to create certs also already exists. What sort of patch are you looking for? I could certainly provide a page running in an apache server to validate a request for and implant a client cert in a Firefox browser. The issue of certificate creation needs a little more discussion, not because it is difficult or requires a lot of new software to execute, but because it is important to be clear about the requirements. When you describe the overhead, do you mean the overhead of creating the certs? Examining them when someone first logs on? I raised this alternative because you said that a bespoke browser was a requirement to have automatic authentication with the school server. To me, the benefits of running a standard browser are so substantial that this trade off should be considered. Can you explain these benefits? Both Gecko and WebKit are standard browser engines. I don't see much to be gained from a UI perspective (which presumably is what you're taking about?) by switching to FF3. Performance is the only compelling reason I see. Bobby On Mon, Jul 7, 2008 at 3:39 PM, Martin Langhoff [EMAIL PROTECTED] wrote: On Mon, Jul 7, 2008 at 7:20 PM, Carol Lerche [EMAIL PROTECTED] wrote: Why does automatic authentication require a custom browser? Client certificates work well for this function in ordinary web applications (assuming a properly configured server). I haven't delved into this deeply yet, but I suspect that, while I am fond of client certs, they won't work - SSL network and CPU overhead and sidestepping PKI madness for server certs. More on this when I get to implement it. Now, anyone who wants to have a strong say on how I am developing this is free to start implementing it ahead of me, and showing me some fantastic patches :-) cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- Frisbeetarianism is the belief that when you die, your soul goes up on the roof and gets stuck -- George Carlin ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel -- Frisbeetarianism is the belief that when you die, your soul goes up on the roof and gets stuck -- George Carlin ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
Carol, give me some credit :-) I know that FF works well with client certs and apache has no problem with it. I've been coding apache/ssl aware apps since '98... What sort of patch are you looking for? Well, there is quite a bit of thinking that needs to happen here, and I am working on something else at the moment. So, these are quick notes - XS installs/deployments will be done in so many different scenarios that we cannot address the promises needed the conventional PKI infrastructure. We need a good strategy to sidestep the PKI requirements of full blown SSL. A few weird schemes come to mind, all nasty :-) - SSL overhead at the network layer is very significant. Network bandwidth and latency on the local link are valuable resources. - SSL CPU overhead at the XS end is moderately significant. And then there is the huge work to chop the Firefox interface into something that fits our UI guidelines (and our screen) - I don't claim to know about that part, but you can imagine that *that* part of the problem is enough to make wise hackers declare that maintaining Browse for the long term is Just Fine. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Mon, Jul 7, 2008 at 7:06 PM, Carol Lerche [EMAIL PROTECTED] wrote: The UI seems pretty important to me, but obviously that's a matter of taste. Not everyone likes tabbed browsing. Correct operation of websites that fail with the extant browser. Direct availability of plugins and addons. One example: scrapbook, a superb research tool. Another example Google Gears (according to a recent mail being ported, presumably because the browser is not standard). I am not familiar with the Firefox codebase, and perhaps all these things are directly available so long as the Firefox 3 engine is there, but if so, there desperately needs to be a detailed body of documentation telling how to access these capabilities. Carol - I created a page on the wiki to list these problem sites. Can you please record these sites there? http://wiki.laptop.org/go/Browse/ProblemSites And, to be fair, Gears is not (only) a website, its a browser plug-in that allows you to interact with certain websites offline. (and I do think someone is working on porting it as you said). Bobby On Mon, Jul 7, 2008 at 3:56 PM, Bobby Powers [EMAIL PROTECTED] wrote: 2008/7/7 Carol Lerche [EMAIL PROTECTED]: Client certs can be used for authentication with no changes to a Firefox browser or an Apache server. GTK based as well as web based software to create certs also already exists. What sort of patch are you looking for? I could certainly provide a page running in an apache server to validate a request for and implant a client cert in a Firefox browser. The issue of certificate creation needs a little more discussion, not because it is difficult or requires a lot of new software to execute, but because it is important to be clear about the requirements. When you describe the overhead, do you mean the overhead of creating the certs? Examining them when someone first logs on? I raised this alternative because you said that a bespoke browser was a requirement to have automatic authentication with the school server. To me, the benefits of running a standard browser are so substantial that this trade off should be considered. Can you explain these benefits? Both Gecko and WebKit are standard browser engines. I don't see much to be gained from a UI perspective (which presumably is what you're taking about?) by switching to FF3. Performance is the only compelling reason I see. Bobby On Mon, Jul 7, 2008 at 3:39 PM, Martin Langhoff [EMAIL PROTECTED] wrote: On Mon, Jul 7, 2008 at 7:20 PM, Carol Lerche [EMAIL PROTECTED] wrote: Why does automatic authentication require a custom browser? Client certificates work well for this function in ordinary web applications (assuming a properly configured server). I haven't delved into this deeply yet, but I suspect that, while I am fond of client certs, they won't work - SSL network and CPU overhead and sidestepping PKI madness for server certs. More on this when I get to implement it. Now, anyone who wants to have a strong say on how I am developing this is free to start implementing it ahead of me, and showing me some fantastic patches :-) cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- Frisbeetarianism is the belief that when you die, your soul goes up on the roof and gets stuck -- George Carlin ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel -- Frisbeetarianism is the belief that when you die, your soul goes up on the roof and gets stuck -- George Carlin ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Fwd: (another) WebKit port of Browse
Sorry Bobby and others...I went from an offlist reply to a more general reply and omitted recipients. Google Gears is interesting in so far as it is a plug-in that supports offline use of the school server, and as such is being directly ported. My point was exactly that it is a plugin. There are other plugins that are educationally useful. Scrapbook was my example. I think it makes research on the web far more productive and the resultant work more rigorous. How do you run such plugins and add-ons from the current browse activity without a development effort? If you know, please provide information and I will experiment and post a wiki page. If it is not possible, that's my point. Martin -- You state that ssl at the network layer is significant. The question is when and how much must ssl be used to authenticate with client certs? I believe it only needs to be used during initial authentication and again when properly designed cookies expire. Since each XO only authenticates infrequently, SSL cost is not significant. My understanding from the wiki is that The school server is a bundle of software that may be run on a variety of platforms, allowing it to support schools of 20 to 2000 students. OLPC will design and build two varieties of school server, small and large, supporting 20 and 150 students respectively. So assuming that small school servers are approximately an XO in power, this means that the school server would have to be able to handle 20 authentications in a relatively short time window (open your laptops, class, and browse to this morning's lesson). Say 1 to 2 minutes. (I'm giving those obedient kids with XOs the benefit of the doubt here!) The big server scenario would require specification. I am going to go off and get timings for the small server and report back, but I'm betting it would work fine. As to the PKI infrastructure, I don't think it is any harder to work this out than any of the other key management issues already in play. So put the Certificate Authority software on the teacher's laptop and keep the CA key material on a thumb drive, as one example. We aren't talking about certs that get an attacker into a financial institution here. Carol Lerche On Mon, Jul 7, 2008 at 4:24 PM, Bobby Powers [EMAIL PROTECTED] wrote: On Mon, Jul 7, 2008 at 7:06 PM, Carol Lerche [EMAIL PROTECTED] wrote: The UI seems pretty important to me, but obviously that's a matter of taste. Not everyone likes tabbed browsing. Correct operation of websites that fail with the extant browser. Direct availability of plugins and addons. One example: scrapbook, a superb research tool. Another example Google Gears (according to a recent mail being ported, presumably because the browser is not standard). I am not familiar with the Firefox codebase, and perhaps all these things are directly available so long as the Firefox 3 engine is there, but if so, there desperately needs to be a detailed body of documentation telling how to access these capabilities. Carol - I created a page on the wiki to list these problem sites. Can you please record these sites there? http://wiki.laptop.org/go/Browse/ProblemSites And, to be fair, Gears is not (only) a website, its a browser plug-in that allows you to interact with certain websites offline. (and I do think someone is working on porting it as you said). Bobby On Mon, Jul 7, 2008 at 3:56 PM, Bobby Powers [EMAIL PROTECTED] wrote: 2008/7/7 Carol Lerche [EMAIL PROTECTED]: Client certs can be used for authentication with no changes to a Firefox browser or an Apache server. GTK based as well as web based software to create certs also already exists. What sort of patch are you looking for? I could certainly provide a page running in an apache server to validate a request for and implant a client cert in a Firefox browser. The issue of certificate creation needs a little more discussion, not because it is difficult or requires a lot of new software to execute, but because it is important to be clear about the requirements. When you describe the overhead, do you mean the overhead of creating the certs? Examining them when someone first logs on? I raised this alternative because you said that a bespoke browser was a requirement to have automatic authentication with the school server. To me, the benefits of running a standard browser are so substantial that this trade off should be considered. Can you explain these benefits? Both Gecko and WebKit are standard browser engines. I don't see much to be gained from a UI perspective (which presumably is what you're taking about?) by switching to FF3. Performance is the only compelling reason I see. Bobby On Mon, Jul 7, 2008 at 3:39 PM, Martin Langhoff [EMAIL PROTECTED] wrote: On Mon, Jul 7, 2008 at 7:20 PM, Carol Lerche [EMAIL PROTECTED] wrote: Why does
Re: [sugar] (another) WebKit port of Browse
2008/7/7 Carol Lerche [EMAIL PROTECTED]: The UI seems pretty important to me, but obviously that's a matter of taste. Not everyone likes tabbed browsing. Correct operation of websites that fail with the extant browser. Direct availability of plugins and addons. One example: scrapbook, a superb research tool. Another example Google Gears (according to a recent mail being ported, presumably because the browser is not standard). I am not familiar with the Firefox codebase, and perhaps all these things are directly available so long as the Firefox 3 engine is there, but if so, there desperately needs to be a detailed body of documentation telling how to access these capabilities. I certainly acknowledge that a) the sparse UI isn't for everyone and b) the UI is young and still needs some more work (and more features). It started out bare bones, and is slowly gaining important features as we go (recently URI autocompletion, find in page text, foundational support for global bookmarks, and other features appeared!). It should also be noted that tabs were part of the initial design, and were taken out both to prevent abuse of RAM and because we thought that it might be confused adjacent to the link sharing feature, which we felt was a really important addition for our target audience and collaborative learning. I'd consider adding them in light of recent engine improvements, assuming we can prove that kids navigate them naturally. Additionally, I'd love to see other individuals with interest porting other browsers to the XO. I think someone was working on this with Opera. Perhaps a more full featured Firefox could also be Sugarized. However, we designed the current Browse as is to be purposely sparse, to give kids the basics without overloading them with things that could get in the way. I think there's a place for Browse as a default browser, especially for kids under 8 or so, even if other more complex browsers appear as viable alternatives. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
Allowing the null encryption algorithm in the browser would enable it for other later negotiations, which seems an unnecessary exposure to suppress the encryption for a single small https exchange. But it would certainly be possible. On Mon, Jul 7, 2008 at 9:44 PM, [EMAIL PROTECTED] wrote: On Mon, 7 Jul 2008, Martin Langhoff wrote: On Mon, Jul 7, 2008 at 7:20 PM, Carol Lerche [EMAIL PROTECTED] wrote: Why does automatic authentication require a custom browser? Client certificates work well for this function in ordinary web applications (assuming a properly configured server). I haven't delved into this deeply yet, but I suspect that, while I am fond of client certs, they won't work - SSL network and CPU overhead and sidestepping PKI madness for server certs. More on this when I get to implement it. what about using client certs, but then null encryption after that? it's a non-standard config, but that's just a config option, not code changes. David Lang Now, anyone who wants to have a strong say on how I am developing this is free to start implementing it ahead of me, and showing me some fantastic patches :-) cheers, m -- Frisbeetarianism is the belief that when you die, your soul goes up on the roof and gets stuck -- George Carlin ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Tue, 8 Jul 2008, Mikus Grinbergs wrote: Not everyone likes tabbed browsing. That may be true - but what if the user needs to reference two (or more) separate pages of information. If while looking at one page he can't remember *exactly* what the other page said, he may want to switch between pages. What are the alternatives to tabbed browsing? multiple screens of browsing (currently only available by running multiple copies of browse, with the associated memory useage) David Lang [To me, it is more logical to select a tab created under my control, than to select from the previously-seen list as presented by the Browse 'Back' button. And to open several instances of the existing Activity seems wasteful.] mikus ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
A reference was made to Gears: My point was exactly that it is a plugin. There are other plugins that are educationally useful. Security. I believe that 'Browse' is restricted as to how much it is allowed to modify the operating system itself. Such restrictions would apply to plugins as well. That concept NEEDS to be enforced. [War story: When plugins first became available for Netscape, I installed one. But Netscape started behaving differently from how I had thought I had set it up. I investigated, and found out that under the covers the plugin had CHANGED (without telling me) some Netscape settings to the way *it* wanted them. Got rid of it fast.] My point is that a 'plugin' is typically a binary blob -- the person installing it on his computer has NO IDEA as to what that plugin might surreptitiously be doing under the covers. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
I've snipped away the parts I have no comment on, but: On Mon, 7 Jul 2008, Martin Langhoff wrote: Well, there is quite a bit of thinking that needs to happen here, and I am working on something else at the moment. So, these are quick notes And me, too - just quick notes: - XS installs/deployments will be done in so many different scenarios that we cannot address the promises needed the conventional PKI infrastructure. We need a good strategy to sidestep the PKI requirements of full blown SSL. A few weird schemes come to mind, all nasty :-) I'd be interested to hear them. - SSL overhead at the network layer is very significant. Network bandwidth and latency on the local link are valuable resources. Do it once at authentication time and use an HTTP cookie after that (that is available to HTTP sites in the same doamin). - SSL CPU overhead at the XS end is moderately significant. Same answer as above. -- Asheesh. -- Life is a grand adventure -- or it is nothing. -- Helen Keller ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Problem with Activity Development
On Mon, 7 Jul 2008, Ankuj Gupta wrote: Hi Due to the git repository structure I have to keep a different directory structure than the default directory as recommended by the wiki.The contents of the manifest file are mentioned here Okay. EducationalToolkitActivity.py imports parse and model .py But tle log shows module missing.I have also edited the activity-info file.But still it shows No module named as parse Can you: (a) provide the full source?, and (b) provide the exact error message? -- Asheesh. -- The easiest way to get the root password is to become system admin. -- Unknown source ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
