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
