experiencing unexpected OLPC behavior from a misplaced click

Greg Smith gregsmitholpc at gmail.com
Sun Jul 20 09:04:57 EDT 2008

Hi Mikus,

I didn't mean to put you in a difficult position.

I assume that if the XO doesn't do what the user expects its a bug 
(maybe a low priority one). No problem if you don't want to file this one.

Can you write a brief blurb in the 8.2.0 release notes to preserve the 
knowledge. Maybe just text, no bug ID in 

I'm not trying to push you into anything you are not comfortable with.

You're making a great contribution and its making a big difference to 
the quality of the product! Please keep the comments and work coming, 
regardless of any communication faux pas on my part.


Greg S

Date: Sat, 19 Jul 2008 14:25:39 -0400
From: Mikus Grinbergs <mikus at bga.com>
Subject: experiencing unexpected OLPC behavior from a misplaced click
To: devel at lists.laptop.org
Message-ID: <488231A3.8070209 at bga.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I posted about an experience I had, where I was surprised to find
that my OLPC had become unresponsive.  My reason for posting was to
"alert" others that "surprises may be lurking" for OLPC users.


Greg, you quoted my post, and wrote:
 > > Can you file a bug on this (dev.laptop.org) and include steps to
 > > reproduce and test?

I am put into a difficult position when I see comments like this.
If I am prevented from doing something by the current behavior of
the OLPC, and would like that behavior changed to allow me to go
ahead and do the thing I wanted, *then* I will write a ticket.

But here is a case where I did not wait long enough for the OLPC to
draw a pop-up palette, and did not make sure that the cursor was
correctly positioned on the appropriate entry in that palette,
before I 'clicked'.  In other words, it was __I__ who misbehaved.

It is my intention to *not* write a ticket on this.  Aside from the
__user's__ behavior needing to be corrected, I'm not sure what else
would be "ticketable" ??

It might help impatient users if palettes (e.g., in the Journal
screen) were 'instantaneous' instead of 'slow' --  but I imagine the
graphics speed is established by the OLPC processing capability (low
power draw is imperative) and the overall Sugar GUI 'Look_And_Feel'
design -- and can't be changed.  I see nothing in this particular
situation for which writing a ticket would improve matters.


More information about the Devel mailing list