Re: [sugar] Landing patches about the network devices UI

2008-08-25 Thread Kimberley Quirk
I don't agree with adding #4 at this time (changing how/where we see  
the mesh icons). One of the many work-arounds that we have been  
telling people in field is that they may need to choose mesh ch 6 or  
11 if they want a small group to collaborate in a school setting  
without any other infrastructure. If the mesh icon doesn't show up in  
the neighborhood view, that will be a problem.


I'd like to see this UI change well before it is implemented. Is there  
a url, Eben?


I'm less concerned about 1 and 3 because they don't seem invasive from  
the one line summary... if they get in this week as polish that would  
be ok. I don't know the depth of 5 or 2... and I'm most worried about 4.


If all these fixes come in one patch, then I would ask that we do NOT  
take this patch. If we can pick and choose from this list to get some  
polish things into 8.2, then let's pick a few based on the invasiveness.


Thanks,
Kim



1 Adds IP address to the mesh  wireless palettes, with associated
changes to their model classes.
2 Removes the Disconnect or Turn On/off entries from the
wireless/mesh palettes.
3 Makes both frame icons pulse.
4 Don't show the mesh icons in the mesh view, instead show them in  
the frame.

5 Fix some iconsistency in the icon states by cleaning up the code.


On Aug 25, 2008, at 10:01 AM, Marco Pesenti Gritti wrote:


Eben Eliason wrote:

On Mon, Aug 25, 2008 at 8:19 AM, Marco Pesenti Gritti


4 would be nice to have but I don't consider it essential.



Actually, I think this is the most important aspect of the design,  
and

I strongly suggest we try to land it.  This has been confusing to
many, and when we change it I think we need to commit to going the
whole way, instead of leaving it in limbo which will only confuse
people more down the road.



Personally I think it's way too late for invasive UI changes. I'm  
fine to be overridden by Kim/Greg  decision in that direction, though.


Marco


___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


Re: [sugar] Landing patches about the network devices UI

2008-08-25 Thread Kimberley Quirk
Just spoke with Ricardo and he stated that the wireless firmware we  
added to this build was for test purposes only and not the firmware  
that we want to ship. It has other test code in it and the simple mesh  
feature was specifically turned off; so we can't use this firmware for  
system testing and we need to revert until we have a better firmware  
release with the bug fix on top of what was otherwise working well.

The issue I pointed out to him (and he will work with Marvell) is that  
we are only a few weeks away from our desired release date and the  
blocking bug in the firmware needs to be addressed in the next day or  
two. We really need a version of wireless firmware that we can be  
using in large scale testing by the end of the week.

Thanks for your help in driving this, Ricardo!

Kim



On Aug 25, 2008, at 9:13 AM, Walter Bender wrote:

 I agree with your assessment. Note that right now (8.2-756), the mesh
 icons don't show up on either the Neighborhood view or the Frame; that
 is clearly not a satisfactory situation.

 regards.

 -walter

 On Mon, Aug 25, 2008 at 8:19 AM, Marco Pesenti Gritti
 [EMAIL PROTECTED] wrote:
 Hello,

 we have a couple of patches that should be ready to be reviewed by
 tomorrow, which solves several issues with the UI of network devices.

 #6944 UI confuses which AP you are connected to
 #3993 The color of network icon in Home view becomes white after
 restarting Sugar.
 #2866 Network Manager GUI doesn't report success or failure
 #6995 Add a mesh device to the frame and remove mesh devices from
 Neighborhood view

 The tickets are a little confusing, so let me summarize what the  
 patches does:

 1 Adds IP address to the mesh  wireless palettes, with associated
 changes to their model classes.
 2 Removes the Disconnect or Turn On/off entries from the
 wireless/mesh palettes.
 3 Makes both frame icons pulse.
 4 Don't show the mesh icons in the mesh view, instead show them in  
 the frame.
 5 Fix some iconsistency in the icon states by cleaning up the code.

 mtd did quite a bit of testing on them already, but they are pretty
 invasive and there is some risk of regressions.

 My opinion is:

 2 is controversial and should be left as is for 8.2
 1, 5 are important and we should try to get them in.
 4 would be nice to have but I don't consider it essential.
 3 should be delayed unless it's small and it's easier to take it then
 to refactor patches.

 1,3,5 has been submitted for review as patch A. 2, 4 will be  
 submitted
 today as patch B. My suggestion would be:

 * Rip off 3 from patch A if it's worth it and land it for 8.2.0  
 (before Friday)
 * Do *not* land patch B for 8.2.0

 mtd has some free time today, so if we can let him know what we want
 and don't want to land soon it would be great.

 Thanks,
 Marco
 ___
 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] patch for a first boot launch of a Help activity

2008-07-31 Thread Kimberley Quirk
I don't think we want it to auto launch, but perhaps it should be the  
first icon on the left.


Thoughts on that?

Kim

On Jul 29, 2008, at 10:30 AM, Eben Eliason wrote:

My personal opinion on the matter is that we shouldn't be doing the  
launch automatically, but others are welcome to disagree. =)  I  
think the presence of a nice, clean, question mark icon on the Home  
screen after boot will be plenty for those that want to jump into  
help right away, and instilling the Home zoom level as just what it  
is -- Home -- is equally important.  Particularly because of the  
fullscreen nature of the activities (and the new launcher itself), I  
actually think it would be more disorienting to be driven directly  
into the help activity.


I'm not sure the decision was finalized, as the ticket you worked  
from didn't make it clear one way or the other.  Thanks for your  
hard work, either way!


-  Eben


On Tue, Jul 29, 2008 at 10:12 AM, Bobby Powers  
[EMAIL PROTECTED] wrote:

On Tue, Jul 29, 2008 at 5:42 AM, Marco Pesenti Gritti
[EMAIL PROTECTED] wrote:
 I think the agreement when we met about this was to *not* autolaunch
 the activity. Eben?

that could certainly be.  it was a fun little project for an hour, and
I wasn't aware a decision was reached on whether or not to autolaunch
it.

bobby

 Marco

 On Tue, Jul 29, 2008 at 5:57 AM, Bobby Powers  
[EMAIL PROTECTED] wrote:

 Hello,

 after talking with Seth this evening, I whipped together a small  
patch
 (against the current git heads of sugar and sugar-toolkit) to  
launch
 an activity with the service name of org.laptop.Help on the first  
boot
 of the XO.  It checks the user profile for a field called  
'ShowHelp'
 in a category 'FirstBoot', which doesn't exist on the first  
launch.  I
 know this has been talked about for G1G1, does anyone have any  
better

 ideas of how to do this?


 yours,
 Bobby

 ___
 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] Congratulations! but Sugar sucks

2008-07-24 Thread Kimberley Quirk
Ben,
I think many people will agree with much of what you have identified  
in your rant; and we have been working on making the most progress we  
can given the constraints of the 'real' world:

1 - 350,000 laptops in the hands of kids today. This alone takes most  
of the resources away from your identified big issues and forces us to  
focus on the serious bugs that are currently shipping. This is not an  
excuse... just reality. We identified all the items you have written  
down as being 'not good enough' pretty much from the day we shipped.  
But the problems of real world take precedent over the next features.  
At the same time, we have been hiring so we can try to tackle both:  
support what we've shipped AND make progress on the next features.  
Hiring and coming up to speed take many months.

2 - OLPC never had enough resources to deliver all 6 of these new  
technologies with 'developed world' quality from day 1. This has been  
identified well before we even shipped the first laptop... and we  
decided it was still better to have something in the hands of kids  
rather than nothing.

We've heard it from others who have visited schools in Mongolia,  
Rwanda, Haiti, Uruguay, etc. and I will add my voice to that group as  
I just got back from visiting a school in Peru. The students and  
teachers are all learning so quickly with the laptops, and they are  
all excited and appreciative to have this opportunity in their school.  
It really is better to continuing shipping these laptops where they  
can help children, then to stop and 'get it right' for the developed  
world market.

Yes, sometimes progress is slow; and I (for one) appreciate the time  
and thought you put into this list as it DOES represent the areas  
where we want to make progress and can most use help.

Now, maybe we can turn this list into a real request for how people  
can help!

Kim





On Jul 24, 2008, at 2:25 PM, Benjamin M. Schwartz wrote:

 (Foreword: I originally intended to send this e-mail after the  
 release of
 8.2.0,
 but I have been convinced to send it earlier in order to prompt  
 discussion)

 Dear OLPC developers,

 Congratulations on your work so far towards 8.2.0, with its new UI,  
 new
 underpinnings, and thousands of individual improvements.  It took  
 years of
 effort to get this far, and a tremendous amount has been done to  
 reinvent
 the entire notion of a software stack to better serve the educational
 needs of children.  This release will be a triumph.

 Unfortunately, it is also an abysmal failure.  There is hardly a worse
 operating
 environment available than Sugar as it currently stands.  In  
 addition to an
 amazing variety of terrible bugs, this failure is due to a handful of
 major missing
 features.  I list here six major missing features, and what can be  
 done about
 them to ensure a 9.1.0 that moves Sugar from mediocre to outstanding.

 1. The datastore
 Sugar's design calls for a centralized rich data storage system, the
 datastore.  The datastore provides secure, limited file access to
 Activities, manages file metadata, maintains a differentially  
 compressed
 history of all work, ensures reliable backups to a trusted server, and
 mediates the connection to removable media.  Every one of these  
 features
 is crucial to Sugar's functioning, and almost none are really  
 working at
 this time.  We cannot afford another release based on the present
 datastore, as it fails to implement the features we require, and is
 unreliable even in the features it supposedly implements.

 Solution:
 There have, at this point, been at least five distinct proposals for a
 next-generation datastore design, all differing in underlying
 implementation and user-facing functionality.  We need to have a  
 Once And
 For All datastore summit, draw up a compromise datastore design, and
 implement it.  We can do this by 9.1.0, if we are willing to make it a
 priority.

 2. OS Updates
 We now have hundreds of thousands of laptops deployed in the field,
 running a variety of OS versions.  OLPC cannot afford to support a
 multitude of decrepit versions, and children cannot afford to suffer
 defects that have long since been fixed.  We need a reliable, fast,
 update system that does not rely on the network, so that children
 everywhere can move to the
 latest version of Sugar without losing their data.  The update  
 system must
 support tremendously invasive upgrades, like repartitioning the NAND  
 and
 replacing JFFS2, because we expect to do this in short order.

 Solution:
 A secure usb autoreinstallation stick is required.  It is not  
 technically
 challenging to implement, but it must be made a priority, and then  
 be made
 widely available and idiot-proof.

 3. File Sharing
 Students and teachers have no good way to distribute files directly  
 from
 one person's Journal to another.  If all Activities that open a file  
 do
 not implement Collaboration, then there is simply no way to transfer