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. > > 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 > > > > |
In reply to this post by Stephan Eggermont-3
Stephan Eggermont <[hidden email]> writes:
> https://vimeo.com/158063568 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 |
In reply to this post by Stephan Eggermont-3
That looks very cool, how about adding it to the standard distribution? > On Mar 7, 2016, at 16:21, Stephan Eggermont <[hidden email]> 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. > > 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 > > > > ---> 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 <[hidden email]> 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 <[hidden email]> 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. >> >> 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 >> >> >> >> > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > > |
In reply to this post by Stephan Eggermont-3
2016-03-07 20:21 GMT+01:00 Stephan Eggermont <[hidden email]>: When using data entry applications, Elegant and cool. More nice looking, professional widgets: yes! Thierry
|
In reply to this post by jfabry
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 > > > > |
In reply to this post by EstebanLM
On 08-03-16 13:55, Esteban Lorenzano wrote:
>> On 08 Mar 2016, at 13:52, Johan Fabry <[hidden email]> 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 |
In reply to this post by stepharo
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 >> >> >> >> > > > |
Free forum by Nabble | Edit this page |