Another oddity

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Another oddity

Trygve

Smalltalk version 'Squeak5.3'
  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
Text cursor placement seems to be ignored.
--Trygve
--

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



Reply | Threaded
Open this post in threaded view
|

Re: Another oddity

Karl Ramberg
I can confirm this bug in Squeak Trunk 6 19722

Best,
Karl

On Tue, Jun 9, 2020 at 2:06 PM Trygve Reenskaug <[hidden email]> wrote:

Smalltalk version 'Squeak5.3'
  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
Text cursor placement seems to be ignored.
--Trygve
--

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




Reply | Threaded
Open this post in threaded view
|

Re: Another oddity

marcel.taeumel
Hi, there.

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:.

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. :-)

Best,
Marcel

Am 10.06.2020 18:15:03 schrieb karl ramberg <[hidden email]>:

I can confirm this bug in Squeak Trunk 6 19722

Best,
Karl

On Tue, Jun 9, 2020 at 2:06 PM Trygve Reenskaug <[hidden email]> wrote:

Smalltalk version 'Squeak5.3'
  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
Text cursor placement seems to be ignored.
--Trygve
--

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




Reply | Threaded
Open this post in threaded view
|

Re: Another oddity

marcel.taeumel
I just tried something. Biggest challenge is to turn off that time-out list filters have because text fields do not reset their contents after a delay. That's an interesting puzzle. :-D

Best,
Marcel

Am 11.06.2020 08:32:21 schrieb Marcel Taeumel <[hidden email]>:

Hi, there.

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:.

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. :-)

Best,
Marcel

Am 10.06.2020 18:15:03 schrieb karl ramberg <[hidden email]>:

I can confirm this bug in Squeak Trunk 6 19722

Best,
Karl

On Tue, Jun 9, 2020 at 2:06 PM Trygve Reenskaug <[hidden email]> wrote:

Smalltalk version 'Squeak5.3'
  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
Text cursor placement seems to be ignored.
--Trygve
--

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




Reply | Threaded
Open this post in threaded view
|

Re: Another oddity

K K Subbu
In reply to this post by marcel.taeumel
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


Reply | Threaded
Open this post in threaded view
|

Re: Another oddity

marcel.taeumel
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




Reply | Threaded
Open this post in threaded view
|

Re: Another oddity

marcel.taeumel
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




Reply | Threaded
Open this post in threaded view
|

Re: Another oddity

Tim Johnson-2
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






Reply | Threaded
Open this post in threaded view
|

Re: Another oddity

Trygve
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



Reply | Threaded
Open this post in threaded view
|

Re: Another oddity

K K Subbu
In reply to this post by marcel.taeumel
On 11/06/20 1:40 pm, Marcel Taeumel wrote:
> 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... :'(

Of course, the field can rise up under the list only when text is typed
and disappear when the selection is done. All list morphs would behave
consistently.

Regards .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: Another oddity

Tim Johnson-2
In reply to this post by Trygve

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



Reply | Threaded
Open this post in threaded view
|

Re: Another oddity

timrowledge
In reply to this post by Tim Johnson-2
I think related to this in general - typing in the textfield of the 'add a category' dialogue is messed up a bit too. Try adding a category, typing abc and then left-cursor a couple d. You do not get adbc...


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Bother," said Pooh. "Eeyore - ready two photon torpedoes and lock phasers on the Heffalump. Piglet, meet me in Transporter Room Three."


Reply | Threaded
Open this post in threaded view
|

Re: Another oddity

K K Subbu
In reply to this post by marcel.taeumel
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

Reply | Threaded
Open this post in threaded view
|

Re: Another oddity

Trygve
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



Reply | Threaded
Open this post in threaded view
|

Re: Another oddity

marcel.taeumel
In reply to this post by K K Subbu
Hi Subbu.

But shouldn't the left/right arrow keys be passed to the field editor?

They are automatically, because they are not filtered. Or do you mean when the list has the keyboard focus? Hmm.... but even if you could move the text cursor then, insert/delete does not happen at the cursor position.

Ha! You could track the cursor position in the model and then change the search term at the right position. :-) This is crazy...

Best,
Marcel

Am 12.06.2020 08:40:12 schrieb K K Subbu <[hidden email]>:

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



Reply | Threaded
Open this post in threaded view
|

Re: Another oddity

marcel.taeumel
In reply to this post by Trygve
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



Reply | Threaded
Open this post in threaded view
|

Re: Another oddity

Trygve
Hi Marcel,
You are right, and I'm wrong, of course. No need for a heavy-duty mechanism here since all objects appear to be single-purpose and know their neighbor.
The input pane is a PluggableTextMorphPlus, so there may be something unconventional in its setup.

Best
--Trygve

On 2020.06.12 17:42, Marcel Taeumel wrote:
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



    

--

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