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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
