Re: [Sugar-devel] Keep confusion -- round N+1
On 06/24/2010 01:07 AM, Daniel Drake wrote: On 23 June 2010 15:49, Martin Langhoffmartin.langh...@gmail.com wrote: Continuing on the tradition of Keep confusion, yet again thread http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023440.html I was yesterday in a conf call with the Perú team, who had been working with teachers and were reporting a keep bug on F11/S0.84 images. What was very clear was that both technical team and teachers were confused about the keep button; and they were seeing a bug that increased their confusion. Yep, I'm here in peru and they are facing the same confusion as i've seen all over the world. This button needs to go away. Yes, same observation here in the Planetarium deployment. The kids think that the keep button means 'saving' and they get confused when I say that Sugar saves automatically. +1 too for removing it. Here in Peru they are modifying all of the 30 activities on the laptop to remove the Keep button. (with a little care for the ones where it has alternative functions such as Write -- thats why you can't just take it out of the activity class altogether) Maybe those activities that do need those exports options can move them into another category/subtab. TurtleArt is a good example for solving that. Regards, Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Keep confusion -- round N+1
On 06/23/2010 10:49 PM, Martin Langhoff wrote: [...] It probably needs to be complemented by an option in the Journal to add a duplicate this document, and Home View changes to make it clearer/easier to open a new activity without reopening the last document. We actually did a lot of work on this in the last release cycle with the design team on making a better separation between resume and start new in the Journal. After making tests [1] in deployments for start new vs. resume we concluded that the way activity starting works on the iPhone would probably work well in Sugar, too [2]. In any case, we have been working on this topic so hard during the last release cycle, would be great it we conclude something from that discussion at make it an action item. Regards, Simon [1] http://wiki.sugarlabs.org/go/Design_Team/0.88_Meeting#Resume.2FStart_new_on_the_Home_View [2] http://wiki.sugarlabs.org/go/File:Sugar_resume_vs_start_new.jpg ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Keep confusion -- round N+1
After making tests [1] in deployments for start new vs. resume we concluded that the way activity starting works on the iPhone would probably work well in Sugar, too [2]. Hehe, this is exactly the thing you would get with per-activity datastores. Guess what, Android does this too. :) Not to mention that an object chooser for pictures could be totally different from an object chooser for ftp sessions for example. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Removing 'share' option from activites that don't know how to share
Talking with the Perú team a few days ago about F11/S0.84 (both on xo-1.5 and xo-1) Teachers and testers were very confused with the 'share' option in activities where sharing does nothing, or is seriously buggy. To avoid confusing users, they are looking into removing the 'share' option from most activities. This is practical and executive for them short-term; of course the right fix is for activities do call up the 'share' option only where actual sharing code exists and is known to work... What is the right fix? Do we want a list of activities where it should be removed, and prod the maintainers, and only file bugs for those that don't respond soonish? (The above would be an informal copy of the mass bug filing protocol @ Debian.) m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sound troubles
Hi Thomas, On Thu, Jun 3, 2010 at 3:18 PM, Thomas PLESSIS 55...@supinfo.com wrote: I'm developing flash applications on OLPC using adobe air. We have some troubles with our flash application when we are playing sounds : randomly, the sound channel is down, and we need to restart application to have sounds again. We have noticed that it's happen after the standby of the laptop... Any idea on how to solve this problem? Care to try the most recent release candidate? It seems to contain fixes for sound +suspend troubles that might be related. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Keep confusion -- round N+1
On 24 Jun 2010, at 09:45, NoiseEHC noise...@freemail.hu wrote: After making tests [1] in deployments for start new vs. resume we concluded that the way activity starting works on the iPhone would probably work well in Sugar, too [2]. Hehe, this is exactly the thing you would get with per-activity datastores. Guess what, Android does this too. :) Not to mention that an object chooser for pictures could be totally different from an object chooser for ftp sessions for example. Well, 'per-activity data stores' sounds like a large rewrite for the data-store, Journal, and every activity... i.e. not very likely. The 'start new vs. resume' design tries to provides a similar work flow but with minimal possible changes - it's pretty close to just moving the current hover palette functionality into a larger object chooser type dialogue. Hmmm, I wonder if we could/should augment the object chooser to also cover this case? Also worth taking note that the Apple iOS approach of letting the app deal 100% with the presentation of files/objects gives a real mixed bag of different attempts from each app developer, some do great work, others are rather confusing/weak, some don't bother at all. There is certainly little consistency when using one app vs. another, you have to re-learn what features are available and where the developer decided to place them. Regards, --Gary ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Removing 'share' option from activites that don't know how to share
On 24 Jun 2010, at 16:20, Martin Langhoff martin.langh...@gmail.com wrote: Talking with the Perú team a few days ago about F11/S0.84 (both on xo-1.5 and xo-1) Teachers and testers were very confused with the 'share' option in activities where sharing does nothing, or is seriously buggy. To avoid confusing users, they are looking into removing the 'share' option from most activities. This is practical and executive for them short-term; of course the right fix is for activities do call up the 'share' option only where actual sharing code exists and is known to work... What is the right fix? Do we want a list of activities where it should be removed, and prod the maintainers, and only file bugs for those that don't respond soonish? Making a list of the offenders and posting would be a start, but remember to state the release you are targeting/testing. Here's a likely large chunk of the problem... For Sugar 0.86 and above the new toolbars will disable the sharing UI with: self.max_participants = 1 For Sugar 0.82 the trick was: activity_toolbar = toolbox.get_activity_toolbar() activity_toolbar.share.props.visible = False For Sugar 0.84 the trick seems to be: activity_toolbar = toolbox.get_activity_toolbar() activity_toolbar.share.hide() I've not noticed an elegant way to detect Sugar versions other than try: except: clauses around some newer modules, with fallback to 0.82 code. Anyone point to a specific activity doing this type of thing nicely? Regards, --Gary (The above would be an informal copy of the mass bug filing protocol @ Debian.) m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Keep confusion -- round N+1
El Wed, 23-06-2010 a las 16:49 -0400, Martin Langhoff escribió: So here we have two separate bugs: B1 - That we have a Keep button, labelled Keep, that actually creates a new document but retains the same document name. We solved this by relabeling the button to Keep a copy. B2 - What you can see between steps #2.1 and #2.2 -- if you wait a few seconds between those steps, step #4 will show 2 documents with the new name instead of 2 documents with the old name. This is http://bugs.sugarlabs.org/ticket/1948 There are two patches for this bug, both with outstanding problems. Mine uses focus-out-event to detect the change, but gtk does not seem to generate the event if you click stop directly after editing the widget. The other approach landed in git for 0.88.1. It uses a 1-second inactivity timer for saving, but the user could be too fast at closing the activity (ctrl-q). Moreover, if the user is too slow at typing, it causes spurious saves which slow down the UI and make the widget mess up the input (which is what the bug was about). It probably needs to be complemented by an option in the Journal to add a duplicate this document, and Home View changes to make it clearer/easier to open a new activity without reopening the last document. A duplicate document function in the journal would be very useful, I think. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Keep confusion -- round N+1
A duplicate document function in the journal would be very useful, I think. I think it's easier and more correct implement this in the activities. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Server-devel] Problemas con SURFboard SB5101 resueltos parcialmente.
Hola lista! Estábamos teniendo problemas con la interacción entre SchoolServer y el SURFboard SB5101 (http://tinyurl.com/yam9j9v) que provee el ISP del estado en nuestra implementación de OLPC en La Rioja Argentina. Despues de pasar toda una mañana haciendo pruebas en el NOC del ISP llegamos a la siguiente conclusión: - El XS envia una DHCPREQUEST con la MAC de eth0 pero por alguna razón la envia cambiada. Si la MAC termina en AB:CD:DA, al servidor de DHCP llega como AB:CD:DB; como el XS no posee esa MAC no toma la IP que el cablemodem le envia. - Tambien observamos que el archivo ifcfg-eth0 no posee definida la variable HWADDR. NOTA: Ese comportamiento, de alteración del ultimo byte de la direccion MAC, lo vi en los AP al pasarse a modo bridge. Resolvimos parcialmente ese problema creando un script que lea la MAC de eth0 y se la agregue al archivo ifcfg-eth0, ese script se ejecuta cuando configuramos el dominio y al reiniciar el XS, toma ip correctamente. Es un gusto aportar nuestra minima experiencia a esta lista. Saludos! Guillermo Narváez Implementación de OLPC en La Rioja Argentina Programa Joaquin Victor Gonzalez ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
