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"

Reply via email to