[ANN] SelectEntity, a new widget for Spec
When using data entry applications, we often have to select one entity out of a large list. Spec provides the entryCompletion option for text fields for that. That works well for small lists When the number of different entities grows large however, or when we want to be able to add a new entity, the traditional solution is to combine an entry completion field with a button that opens a dialog. This is what SelectEntity provides. In addition, it supports limiting the choices shown based on the context in which the field is shown. https://vimeo.com/158063568 I've created a small demo application that can be found on smalltalkhub: Gofer it smalltalkhubUser: 'StephanEggermont' project:'Ancestry'; package: 'Ancestry'; load. It can be started with: ANPersonList new openWithSpec. Stephan Thanks to Peter Uhnak for the design comments & debugging
Cool! I will try friday. Stef Le 7/3/16 20:21, Stephan Eggermont a écrit :
When using data entry applications, we often have to select one entity out of a large list. Spec provides the entryCompletion option for text fields for that. That works well for small lists When the number of different entities grows large however, or when we want to be able to add a new entity, the traditional solution is to combine an entry completion field with a button that opens a dialog. This is what SelectEntity provides. In addition, it supports limiting the choices shown based on the context in which the field is shown.
I've created a small demo application that can be found on smalltalkhub:
Gofer it smalltalkhubUser: 'StephanEggermont' project:'Ancestry'; package: 'Ancestry'; load.
It can be started with:
ANPersonList new openWithSpec.
Stephan
Thanks to Peter Uhnak for the design comments & debugging
Stephan Eggermont <stephan@stack.nl> writes:
this looks really nice, thanks Stephan. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
That looks very cool, how about adding it to the standard distribution?
On Mar 7, 2016, at 16:21, Stephan Eggermont <stephan@stack.nl> wrote:
When using data entry applications, we often have to select one entity out of a large list. Spec provides the entryCompletion option for text fields for that. That works well for small lists When the number of different entities grows large however, or when we want to be able to add a new entity, the traditional solution is to combine an entry completion field with a button that opens a dialog. This is what SelectEntity provides. In addition, it supports limiting the choices shown based on the context in which the field is shown.
I've created a small demo application that can be found on smalltalkhub:
Gofer it smalltalkhubUser: 'StephanEggermont' project:'Ancestry'; package: 'Ancestry'; load.
It can be started with:
ANPersonList new openWithSpec.
Stephan
Thanks to Peter Uhnak for the design comments & debugging
---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On 08 Mar 2016, at 13:52, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
That looks very cool, how about adding it to the standard distribution?
not now. Pharo 6: +1
On Mar 7, 2016, at 16:21, Stephan Eggermont <stephan@stack.nl> wrote:
When using data entry applications, we often have to select one entity out of a large list. Spec provides the entryCompletion option for text fields for that. That works well for small lists When the number of different entities grows large however, or when we want to be able to add a new entity, the traditional solution is to combine an entry completion field with a button that opens a dialog. This is what SelectEntity provides. In addition, it supports limiting the choices shown based on the context in which the field is shown.
I've created a small demo application that can be found on smalltalkhub:
Gofer it smalltalkhubUser: 'StephanEggermont' project:'Ancestry'; package: 'Ancestry'; load.
It can be started with:
ANPersonList new openWithSpec.
Stephan
Thanks to Peter Uhnak for the design comments & debugging
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On 08-03-16 13:55, Esteban Lorenzano wrote:
On 08 Mar 2016, at 13:52, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
That looks very cool, how about adding it to the standard distribution? not now. Pharo 6: +1
I've added ConfigurationOfAncestry to the catalog. That provides the widget and the small demo using it. It needs FastTableModel, so only recent Pharo5 Stephan
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
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
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
2016-03-07 20:21 GMT+01:00 Stephan Eggermont <stephan@stack.nl>:
When using data entry applications, we often have to select one entity out of a large list. Spec provides the entryCompletion option for text fields for that. That works well for small lists When the number of different entities grows large however, or when we want to be able to add a new entity, the traditional solution is to combine an entry completion field with a button that opens a dialog. This is what SelectEntity provides. In addition, it supports limiting the choices shown based on the context in which the field is shown.
Elegant and cool. More nice looking, professional widgets: yes! Thierry
I've created a small demo application that can be found on smalltalkhub:
Gofer it smalltalkhubUser: 'StephanEggermont' project:'Ancestry'; package: 'Ancestry'; load.
It can be started with:
ANPersonList new openWithSpec.
Stephan
Thanks to Peter Uhnak for the design comments & debugging
participants (6)
-
Damien Cassou -
Esteban Lorenzano -
Johan Fabry -
Stephan Eggermont -
stepharo -
Thierry Goubier