[Bf-funboard] Tracking the selection order (feature request)

[Pedro Gimeno]

I'd like to propose the following feature addition.

tl;dr version:

Add a field to selectable items that tracks selection order, and expose
it through the Python API.

Long version:

The ability to track the order in which certain items are selected would
be helpful to certain scripts that could benefit of being able to
determine it, and even open new possibilities to scripts that can't
currently exist or can't work optimally.

The current select_history method doesn't cut it, as it's independent of
the actual selection status of the items, and it isn't updated with many
operations that actually select things, including 'b' and 'a' among
others. It also gets lost when changing the selection mode (face to
vertex, etc.)

So, my proposal is to add a new field to the selectable items, called
select_order, that gets a number from a global counter, which would be
atomically increased, every time the 'select' field is set to True (I'm
talking in Python terms as I'm not familiar with Blender internals, but
I'm sure anyone that knows about the latter can translate my words easily).

In fact, it would be possible to completely replace that flag with such
a counter, where zero would mean not selected, and anything other than
zero would mean selected (and indicate the ordering). I'm not saying
it's a good idea, though, just throwing it in for consideration.

Adding this field, and exposing it in the Python API, would allow
scripts to determine in which order elements were selected, and sort the
items accordingly by that key when operations need to be done in
selection order; while focusing only on the elements it's interested in
(e.g. faces even if the selection mode was vertex), something that
select_history makes virtually impossible.

One example of an add-on that could benefit from such a feature is the
Copy and Paste UV extension [1]. The select order option currently uses
select_history, but that's quite unreliable and can produce unexpected
results, for the reasons explained above.

The new field type should probably be a 64-bit unsigned integer. A
32-bit integer would probably overflow too soon when working with very
complex meshes for long periods of time.

Note: I'm aware that e.g. selecting with 'b' can select the items in a
random-ish order, but sometimes what matters is the ability to determine
whether a certain group was selected before a certain different group.

[1] https://github.com/nutti/Copy-And-Paste-UV_Blender-Ext