Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#4014 closed defect (fixed)

Drag still partly active on Home favourites view triggering odd palette behaviours

Reported by: garycmartin Owned by: manuq
Priority: Unspecified by Maintainer Milestone:
Component: Sugar Version: 0.97.x
Severity: Unspecified Keywords: 13.1.0, r+
Cc: erikos Distribution/OS: Unspecified
Bug Status: Unconfirmed

Description

Testing on 13.1.0 build 5

Drag and drop events still partly active on Home favourites view triggering odd palette behaviours and leftover pressed grey feedback state.

Steps to reproduce:

1) On the Home Activities Spiral/Circle Favourite View
2) Drag an Activity icon with either the cursor or via touch

Results:

  • Icons can be left in grey pressed style state
  • The icons palette can appear some way away from the icon
  • Can often lead to future single touch/click of an Activity icon to always raising it's palette instead of resuming by default.

sudo killall X to recover

Drag and drop Activity icon behaviours should be completely disabled for Home Favourites Spiral/Circle View

Attachments (1)

0001-Favorites-view-do-drag-and-drop-of-icons-only-in-the.patch (4.2 KB) - added by manuq 8 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 9 years ago by manuq

  • Owner changed from erikos to manuq
  • Status changed from new to assigned

comment:2 Changed 8 years ago by manuq

This happens in Home view, spiral layout. Drag is breaking the long-press behaviour.

The long-press, implemented in #3992, works wrong if the user press an icon and then release outside the icon. The palette appears in the release location, and is not dismissed if the user tap or open the frame. This is because there is drag and drop code in all favourites view, but we just want it in random view.

comment:3 Changed 8 years ago by erikos

  • Keywords r? added

comment:4 follow-up: Changed 8 years ago by manuq

About my patch attached, I was in doubt with this: there are two callbacks connected to all children:

  • motion-notify-event
  • drag-begin

what should we do? I'm just returning at the beggining of the callback method if dragging is not wanted.

Another possibility could be, if possible, traverse the list of children when the layout changes and connect/disconnect them.

comment:5 Changed 8 years ago by manuq

  • Cc erikos added

comment:6 in reply to: ↑ 4 Changed 8 years ago by erikos

  • Keywords r+ added; r? removed
  • Resolution set to fixed
  • Status changed from assigned to closed

Replying to manuq:

About my patch attached, I was in doubt with this: there are two callbacks connected to all children:

  • motion-notify-event
  • drag-begin

what should we do? I'm just returning at the beggining of the callback method if dragging is not wanted.

That sounds good to me. The other options sounds to complex.

The patch works as expected. And the random view still works.

comment:7 Changed 8 years ago by dnarvaez

  • Milestone 0.98 deleted

Milestone 0.98 deleted

Note: See TracTickets for help on using tickets.