[Bugs] #3944 sugar HIGH: Neighbourhood view icons can collide with central buddy icon

Sugar Labs Bugs bugtracker-noreply at sugarlabs.org
Tue Dec 11 09:32:43 EST 2012


#3944: Neighbourhood view icons can collide with central buddy icon
----------------------------+-----------------------------------------------
    Reporter:  garycmartin  |          Owner:  humitos           
        Type:  defect       |         Status:  accepted          
    Priority:  High         |      Milestone:  0.98              
   Component:  sugar        |        Version:  0.97.x            
    Severity:  Major        |       Keywords:  13.1.0, regression
Distribution:  Unspecified  |   Status_field:  Unconfirmed       
----------------------------+-----------------------------------------------

Comment(by dsd):

 humitos has figured out whats going wrong here, but I don't think the
 patch really approaches the issue in a way that can get a good review.
 I'll try to help with the explanation:

 Two icons are colliding: the owner icon, and an AP icon being added. The
 owner icon is stored on the grid as locked (it should not be move), the AP
 icon is not locked (it can be moved). The collision detection code here is
 failing to resolve the collision.

 _detect_collisions() is called for the AP icon. It iterates over each of
 the other children in the grid, checking for collisions.

 It reaches the owner icon, and this happens:

 {{{
             if c != child and intersection.width > 0:
 }}}

 This condition passes: the owner is not the AP icon, and an
 intersection(collision) was found.

 {{{
                 if (c not in self._locked_children and
                     c not in self._collisions):
                     collision_found = True
 }}}

 This condition fails: c(the owner) is locked, so we never record a
 collision as happening. And that is the only place where a collision would
 possibly be recorded. So we take no action on the collision, resulting in
 the behaviour (colliding icons) that we see here.

 Maybe a simple and logical fix can be found to this that would be more
 suitable for this late stage of 0.98. Failing that, I'm attaching my take
 on redoing this logic in a way that is easy to understand, inclusive of
 this case, and heavily commented. Its not tested.

-- 
Ticket URL: <http://bugs.sugarlabs.org/ticket/3944#comment:5>
Sugar Labs <http://sugarlabs.org/>
Sugar Labs bug tracking system


More information about the Bugs mailing list