Opened 10 years ago

Closed 10 years ago

Last modified 9 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 10 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 10 years ago by manuq

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

comment:2 Changed 10 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 10 years ago by erikos

  • Keywords r? added

comment:4 follow-up: Changed 10 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 10 years ago by manuq

  • Cc erikos added

comment:6 in reply to: ↑ 4 Changed 10 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 9 years ago by dnarvaez

  • Milestone 0.98 deleted

Milestone 0.98 deleted

Note: See TracTickets for help on using tickets.