I changed it mostly because it was messing up the color when you did mouse-over
(required to check the owner color to set it correctly when there was a
selection, the code was ugly and with corner cases).
Encapsulating a morph with another morph just for a background color is kind of
waste IMO. Causing unnecessary overhead for rendering/layout/eventHandling
etc...
Mesurable? Don’t think I checked, but in the long run there is less
allocations, less layout etc..
I would also argue that
------------------
(highligtedRowIndexes includes: rowIndex) ifTrue: [
row selectionColor: (self owner colorForSelection:
primarySelectionIndex = rowIndex) ].
-----------------
Is better than
-----------------
rowSubviews add: ((highligtedRowIndexes includes: rowIndex)
ifTrue: [
"IMPORTANT: I need to set owner to nil because
otherwise it will trigger an
invalidation of the owner when adding morph to
selectionMorph, causing an
infinite loop"
self
toSelectionRow: (row privateOwner: nil)
primary: primarySelectionIndex =
rowIndex ]
ifFalse: [ row ]) ].
-----------------------
Selection could be and drawn by the container, but then again you would need
much more code and special logic (updating the damageRecorder with correct
rectangles when selection changes for example) than to just extend and
specialize one morph to be a row.
I would much rather prefer one specialized morph doing its thing, than
encapsulate it.
Best regards,
Henrik
-----Original Message-----
From: Pharo-dev [mailto:[email protected]] On Behalf Of Thierry
Goubier
Sent: Sunday, April 3, 2016 8:58 PM
To: Pharo Development List <[email protected]>
Subject: Re: [Pharo-dev] [bloc] shape size?
Le 03/04/2016 20:00, Henrik Nergaard a écrit :
>
>> Let me return you the question then: do you do a composition of
>> submorphs if you're trying to get a different drawOn:?
>
>> Oh, ok, that's true FastTable does it for the selection... changing
>> background color by encapsulating a row in another Morph with the
>> right background color.
>
> Did, not anymore.
>
> FTTableRowMorph>>#selectionColor:
Had to check the following code to be sure:
(highligtedRowIndexes includes: rowIndex) ifTrue: [
row selectionColor: (self owner colorForSelection:
primarySelectionIndex = rowIndex) ].
Was there a measurable inpact when changing that?
Because I have now three ways of doing this, and all of them have trade-offs.
For example the one above suppose that row items are a specific kind of Morph,
i.e. FTTableRowMorph; one could do without a dedicated Morph subclass for rows
and display the selection as a transparent colored rectangle over the row; this
is what I do.
Thierry
