I was going some of the changes with peter and we came to the conclusion: that we should not copy all the api of collection to listModel for example. ValueHolder should be treated as port hence public. We should also avoid in the model to have for example ListModel>>removeall listModeValue hodler.... widget changed. The flow should go always from the model to widgets via notification and not from the UI model (listModel here) to the widgets. When the widget is limited it is better to fix it than to patch it from the UIModel. Stef Le 9/3/16 22:13, stepharo a écrit :
We should check and collect the changes made by hernan too.
Stef
Le 8/3/16 16:45, Stephan Eggermont a écrit :
On 08-03-16 13:52, Johan Fabry wrote:
That looks very cool, how about adding it to the standard distribution? That is definitely the goal. Now is the time to point out stupid names, bad design decisions, missed use cases and ugly layout. I would welcome feedback.
While building it, I found out I don't like the way an EntryCompletion is connected to its PluggableTextFieldMorph. It makes it difficult to deal with objects that are not strings.
PluggableTextFieldMorph>>entryCompletion: anEntryCompletion entryCompletion := anEntryCompletion. entryCompletion ifNotNil: [ entryCompletion chooseBlock isNil ifTrue: [entryCompletion chooseBlock: [:v | self setText: v. self acceptTextInModel ]] ifFalse: [ | blk | blk := entryCompletion chooseBlock. entryCompletion chooseBlock: [:v | self setText: v. self acceptTextInModel. blk value: v]]].
In the demo code it also is clear that the ListModel is incomplete, I couldn't find ho wto open a selected item with the keyboard (unless I implement click on the item, but that then does not have enough context to actually know what to do).
Stephan