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:pharo-dev-bounces@lists.pharo.org] On Behalf Of Thierry Goubier Sent: Sunday, April 3, 2016 8:58 PM To: Pharo Development List <pharo-dev@lists.pharo.org> 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