touch-packages team mailing list archive

[Robert Schroll <rschroll@xxxxxxxxx>]

Public bug reported:

When a ListItem is dragged, it emits "Started" and "Moving" events.  But
if each "Moving" event is accepted, as happens in a live drag case, no
"Dropped" event will be emitted when the item is finally dropped.  One
should be added.  The "to" and "from" parameters could both be set to
the final position, or they could be set to an invalid value.

Example use cases:
1) Updating an underlying data store.  The QML list model may present data stored on disk.  (In a database, for instance.)  Updating the model may be quick while updating the disk store is slow.  It would be nice to be able to give the feedback of the live updates but put off updating the data store until the drag is over.  The "Dropped" signal is necessary for this.
2) Changing styling during drag.  A developer may want to change some styling of elements other than the dragged element during the drag.  For instance, non-dragged items could be shaded so as to be less prominent, or additional information could be presented.  The "Dropped" signal is necessary to know when to reset the styles.
3) Consistency in a mixed drag action.  By choosing which "Moving" events to accept, a developer can create a situation in which parts of a drag are live and others are not.  Currently, the "Dropped" signal will be emitted for some of these drags and not for others.  In addition to being surprising, this may complicated clean-up code.  If the "Dropped" signal is always emitted, this situation would be simplified.

** Affects: ubuntu-ui-toolkit (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in
Ubuntu.
https://bugs.launchpad.net/bugs/1500118

Title:
  ListItem feature request: Signal at end of live drag

Status in ubuntu-ui-toolkit package in Ubuntu:
  New

Bug description:
  When a ListItem is dragged, it emits "Started" and "Moving" events.
  But if each "Moving" event is accepted, as happens in a live drag
  case, no "Dropped" event will be emitted when the item is finally
  dropped.  One should be added.  The "to" and "from" parameters could
  both be set to the final position, or they could be set to an invalid
  value.

  Example use cases:
  1) Updating an underlying data store.  The QML list model may present data stored on disk.  (In a database, for instance.)  Updating the model may be quick while updating the disk store is slow.  It would be nice to be able to give the feedback of the live updates but put off updating the data store until the drag is over.  The "Dropped" signal is necessary for this.
  2) Changing styling during drag.  A developer may want to change some styling of elements other than the dragged element during the drag.  For instance, non-dragged items could be shaded so as to be less prominent, or additional information could be presented.  The "Dropped" signal is necessary to know when to reset the styles.
  3) Consistency in a mixed drag action.  By choosing which "Moving" events to accept, a developer can create a situation in which parts of a drag are live and others are not.  Currently, the "Dropped" signal will be emitted for some of these drags and not for others.  In addition to being surprising, this may complicated clean-up code.  If the "Dropped" signal is always emitted, this situation would be simplified.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1500118/+subscriptions