Another oddity

1. I open a new browser from WorldMenu
2. I write ctrl-f in upper-left pane
3. Browser asks: Class name or fragment?
   
4. I write Pbject
5. I place text cursor just after the P
6. I key in backspace, O
7. result PbjecO

Well, it may be worth noting that this is not a search dialog for what is in the list.  When I hit Cmd-F (or Ctrl-F) in the first list pane, I am not searching for class categories, but rather classes.  

As far as I can tell, the search dialog which appears in 4.5 works fine and does not exhibit the problem reported in this thread.

Also, please don't take this search dialog away ;)    To reiterate, this is not a filter feature, but rather a "class search" feature.

On Jun 11, 2020, at 1:11 AM, Marcel Taeumel wrote:

That said, we may want to add search dialogs for all 4 lists in the system browser, not just the first one. :-)

Best,

Marcel

Am 11.06.2020 10:10:26 schrieb Marcel Taeumel <[hidden email]>:

> Is the field morph really required?

It is just more user-friendly. A search dialog usually as a text field to type something into. That said, I am against adding such fields in a system browser because they would occupy too much screen space. :-D So, I am rather indecisive about this matter... :'(

Best,

Marcel

Am 11.06.2020 09:21:42 schrieb K K Subbu <[hidden email]>:

On 11/06/20 12:02 pm, Marcel Taeumel wrote:
> One could forward #textEdited: from the input field to set the list's
> item filter. Yet, there is no way to forward a "filter changed" event to
> the text field. Well, you could choose to only install the
> keyboard-event filter for the list morph and combine that with
> #textEdited:. Then you would spread the sync code across 2 methods, but
> you could improve the user experience. :-)
Marcel,

Is the field morph really required? class/method lists in browser don't
use one to filter the displayed list. Just pop up a list morph with all
classes and let the list morph do the filtering like in class/method
panes. The dialog window only needs to intercept enter/escape from the
list morph. choose/cancel buttons may also be dropped.

Regards .. Subbu

Yes, thank you.  I agree.  I treasure this feature.

Also, I am sorry (to the list) that a portion of my email was cryptic (at best).  I had misunderstood some of the earlier thread and was replying from a confused place.  :) 

Best,
Tim

On 2020-06-11 09:39, Trygve Reenskaug wrote:

Something has apparently been broken on the journey from 4.5 to 5.3.
My bug report was about editing the entry in the search pane.
It's a very neat feature, IMO

On 2020.06.11 17:51, Tim Johnson wrote:

Well, it may be worth noting that this is not a search dialog for what is in the list.  When I hit Cmd-F (or Ctrl-F) in the first list pane, I am not searching for class categories, but rather classes.  

 

As far as I can tell, the search dialog which appears in 4.5 works fine and does not exhibit the problem reported in this thread.

 

Also, please don't take this search dialog away ;)    To reiterate, this is not a filter feature, but rather a "class search" feature.

 

 

 

On Jun 11, 2020, at 1:11 AM, Marcel Taeumel wrote:

That said, we may want to add search dialogs for all 4 lists in the system browser, not just the first one. :-)

 

Best,

Marcel

Am 11.06.2020 10:10:26 schrieb Marcel Taeumel <[hidden email]>:

> Is the field morph really required?

 

It is just more user-friendly. A search dialog usually as a text field to type something into. That said, I am against adding such fields in a system browser because they would occupy too much screen space. :-D So, I am rather indecisive about this matter... :'(

 

Best,

Marcel

Am 11.06.2020 09:21:42 schrieb K K Subbu <[hidden email]>:

On 11/06/20 12:02 pm, Marcel Taeumel wrote:
> One could forward #textEdited: from the input field to set the list's
> item filter. Yet, there is no way to forward a "filter changed" event to
> the text field. Well, you could choose to only install the
> keyboard-event filter for the list morph and combine that with
> #textEdited:. Then you would spread the sync code across 2 methods, but
> you could improve the user experience. :-)
Marcel,

Is the field morph really required? class/method lists in browser don't
use one to filter the displayed list. Just pop up a list morph with all
classes and let the list morph do the filtering like in class/method
panes. The dialog window only needs to intercept enter/escape from the
list morph. choose/cancel buttons may also be dropped.

Regards .. Subbu

--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      [hidden email]
Morgedalsvn. 5A       http://folk.uio.no/trygver/
N-0378 Oslo             http://fullOO.info
Norway                     Tel: (+47) 468 58 625

On 11/06/20 12:02 pm, Marcel Taeumel wrote:

Yes, it was the simplest way to implement key-press response with sync between textfield and list-filter state. It occasionally bugs me too. See ListChooser >> #filterEvent:for: and the end of #buildWith:.

Marcel,

In filterEvent:for:, I see the up/down arrows being passed to listmorph. But shouldn't the left/right arrow keys be passed to the field editor?

Regards .. Subbu

Hi Trygve.

> Isn't the changed/update mechanism between a StringMorph and filter better known and simpler?

Yes, if the list would signal "self changed: #filterTerm", the model could pass then on to the search field via a custom #update:. But usually the pluggable widgets in Squeak call models directly while models use #changed: to talk to widgets.

Anyway, another goal is to "turn off" that filter reset in the list morph after X milliseconds. It is not just the synchronization between list and field.

Best,

Marcel

Am 12.06.2020 08:57:02 schrieb Trygve Reenskaug [hidden email]:

Isn't the changed/update mechanism between a StringMorph and filter better known and simpler?
Best ... Trygve

On 2020.06.12 08:39, K K Subbu wrote:

On 11/06/20 12:02 pm, Marcel Taeumel wrote:

Yes, it was the simplest way to implement key-press response with sync between textfield and list-filter state. It occasionally bugs me too. See ListChooser >> #filterEvent:for: and the end of #buildWith:.

Marcel,

In filterEvent:for:, I see the up/down arrows being passed to listmorph. But shouldn't the left/right arrow keys be passed to the field editor?

Regards .. Subbu

--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      [hidden email]
Morgedalsvn. 5A       http://folk.uio.no/trygver/
N-0378 Oslo             http://fullOO.info
Norway                     Tel: (+47) 468 58 625