#9560 NORM -: os33 - Neighborhood View unreliable
Zarro Boogs per Child
bugtracker at laptop.org
Tue Dec 8 07:07:07 EST 2009
#9560: os33 - Neighborhood View unreliable
-------------------------------------+--------------------------------------
Reporter: mikus | Owner: dsd
Type: defect | Status: closed
Priority: normal | Milestone:
Component: sugar | Version: Development build as of this date
Resolution: fixed | Keywords:
Next_action: test in build | Verified: 0
Deployment_affected: | Blockedby:
Blocking: |
-------------------------------------+--------------------------------------
Comment(by mikus):
Replying to [comment:6 Quozl]:
> Please test with os50, and re-open if this persists.
[[BR]]I am currently running with os54. Neighborhood View still appears
to not be behaving as well as I would like it to.
Using a wired ethernet, Neighborhood View *does* "track" in real-time
which other XOs are "connected". For instance, as individual XOs
suspend/resume, their icons vanish/reappear in the Neighborhood View of
the (on-line) XO whose screen I am watching.
What I have no control over is the "buddy"? information being shown by
Neighborhood View. If there has been a collaboration (say in Chat), and
all of the XOs participating in that collaboration have now exited (i.e.,
stopped that Activity), I would like the 'invite' icon to disappear from
all Neighborhoods. [I've seen that Chat icon still stick around, even in
the Neighborhood View of the XO which issued the original 'invite'
(although all participants have stopped Chat).]
[[BR]]I personally believe in "user control". What I would like is for
Neighborhood View to provide a 'refresh' capability -- say a keyboard
sequence which would *erase* all displayed "buddy"? information, such that
this XO would have to "re-discover" the "I'm imvited" icons that it
presents in Neighborhood View (meaning only "currently active" invites
would show after 'refresh').
----
I have only one XO-1.5, but multiple XO-1s. When an F11-on-XO1 build with
equivalent capabilities (to the XO-1.5 build) becomes available, I'll see
if I can come up with a test scenario that shows up what I believe to be
unreliable about the Neighborhood View implementation.
--
Ticket URL: <http://dev.laptop.org/ticket/9560#comment:8>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system
More information about the Bugs
mailing list