#2321 NORM Trial-3: With large number of activites, home ring overdraws first activity

[Zarro Boogs per Child]

#2321: With large number of activites, home ring overdraws first activity
-----------------------+----------------------------------------------------
  Reporter:  mcfletch  |       Owner:  marco                            
      Type:  defect    |      Status:  new                              
  Priority:  normal    |   Milestone:  Trial-3                          
 Component:  sugar     |     Version:  Development build as of this date
Resolution:            |    Keywords:                                   
  Verified:  0         |  
-----------------------+----------------------------------------------------
Changes (by Eben):

 * cc: christianmarc (added)
  * owner:  dcbw => marco

Comment:

 We could either refuse to launch new instances when the ring is full, or
 we could bump something out of the ring, as danw mentioned.  Personally,
 despite the fact that activities should be auto-saved, I think that it's a
 bad idea to bump them out of an activity.  They might be participating in
 a chat, or a game, or any other type of activity where their current
 "active-online" state is important.  Additionally, the "least recently
 used" activity could be any of those in the ring, so there would be no way
 for the child to know what would happen when starting a new one.

 Therefore, I think the correct solution is to cap the number and refuse to
 launch more.  We played around with visual designs for this in the past
 with wedges that were shown in red, outside of the ring, to indicate that
 they didn't fit.  I'd like to propose another (simpler) option, though,
 which Pentagram and I should discuss.  That is, we could render the
 activity icons in the frame in the XO colors upon rollover to indicate
 that clicking it will create a new live instance.  If we do this, we can
 clearly indicate the case when a new instance ''won't'' be created by
 treating the rollover as we do now, keeping the stroke.

 In any case, the actual implementation of the hard cap can happen even
 without the visual feedback on rollover/click, so let's get that in the
 builds.  We definitely don't want to have overlapping ring segments.
 Marco, I'm assigning to you to deal with the limit, and I'll update this
 ticket with confirmed visual spec.  Feel free to assign back to me if the
 limit is implemented before I submit visual details.

-- 
Ticket URL: <http://dev.laptop.org/ticket/2321#comment:4>
One Laptop Per Child <http://laptop.org/>