And it would still be cool if the search would not block the UI process :). Is that on your roadmap?
Doru On Wed, Jan 1, 2014 at 9:39 PM, Tudor Girba <tu...@tudorgirba.com> wrote: > Hi, > > I went only over the functionality for now (I tried in a Pharo #30664 with > Moose inside). > > It starts to be really interesting: > - I love it how I can navigate with up/down and still continue typing. > This is seriously cool. > > but :): > - Esc has no effect ( > - The list entries behave strangely because you use a text morph that can > be edited. For example, type something, go with the mouse over an item in > the list, you will see the cursor changes to a text one, click, and you can > start typing there. Why not use a LabelMorph? > - Pressing Enter does not seem to trigger the action associated with a > list. Only pressing double click seems to work. > - The PluggableTextMorph at the top allows Enter. Pressing Enter leads to > a line break. This is not wanted (you asked what I meant by it a field). > - The PluggableTextMorph at the top should not indicate dirty state > - Pressing up/down also moves the cursor in the top PluggableTextMorph. > This should not happen. > - It would be interesting to have the count of hits even though we are > only displaying a limited amount. The count could be displayed below the > label (with a gray color) like: > Messages > 23 items > > And a question related to "Show all on down arrow when closed": > - I think I did not see this behavior. What does "closed" mean? And what > do you mean by "all"? > > Cheers, > Doru > > > > > On Wed, Jan 1, 2014 at 7:23 AM, Tudor Girba <tu...@tudorgirba.com> wrote: > >> Sounds like a great New Year gift :). I will review the code today. >> >> Cheers, >> Doru >> >> >> On Wed, Jan 1, 2014 at 3:20 AM, DeNigris Sean <s...@clipperadams.com>wrote: >> >>> Thanks for the feedback everyone! >>> >>> A few enhancements: >>> - Close on escape >>> - Select next on down arrow when open >>> - Show all on down arrow when closed >>> - Select previous on up arrow >>> - Accept on enter - requires an override in PluggableTextFieldMorph, but >>> I think the change can be integrated in Core >>> - For entry completion (unlike our current behavior): >>> - Keyboard focus remains with the text field, so: >>> - you can continue to type >>> - the selected item stays selected as long as it remains >>> visible, even if it moves around in the list (maybe doesn't matter for >>> completion...) >>> >>> I'm off to celebrate... See you in the new year! >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"