Following on from something I noticed commenting on "[Pharo-users] "whenSelectedItemChanged:" in Spec"...
On Wed, 17 Jul 2019 at 08:38, Ben Coman <
[hidden email]> wrote:
> Looking at ListPresenter>>whenSelectedItemChanged: aBlock
> it is registering aBlock on selectionHolder using #whenChangedDo:
> Reviewing selectionHolder "Code search...>References to it" I see that
> selectionHolder is initialized as an instance of SelectionHolderClass.
>
> So it seems you are expecting whenSelectedItemChanged: to be called
> every time the-selection-is-changed
> when actually it is only called once (by your application) to register
> the block-to-be-called when the-selection-is-changed.
> You don't seem to have done any such registration.
It seems awkward that the SelectionValueHolder used by ListPresenter
allows #index: and #selection: to be set independently making it too easy to get insistent state.
Multi-selection also has a completely different basis using IdentityDictionary
with the boolean "multiSelection" indicating some widget specific handling to distinguish between the two selection-types that may be duplicated a lot elsewhere.
It might be nice to have a generic SelectionWrapper class
that behaved a bit like a PositionableStream to encapsulate any "collection" as its first instance variable, with "positions" as its only other instance variable.
Selected-values would be a derivation of those two instance variables.
"positions" is used rather than "index" since the latter feels 1-dimensional and it should work just as well with a 2-dimensional grid/table.
For an event-driven facility it might subclass Model, or it may be simpler to have its own Announcer.
WDYT?
Would such a class be worthwhile?
Where in the system might this reduce code duplication? (which would define its requirements)
Are there any existing candidates? (Reviewing Spotter('selection') doesn't indicate anything. The closest is SelectionMorph which has baggage and works with items rather than positions)
cheers -ben
Locked
