Smalltalk version 'Squeak5.3'
--Trygve --
The
essence of object orientation is that objects collaborate
to achieve a goal. |
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:
|
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
|
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
|
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 |
> 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
|
That said, we may want to add search dialogs for all 4 lists in the system browser, not just the first one. :-) Best, Marcel
|
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:
|
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. --
The essence of object orientation is
that objects collaborate to achieve a
goal. |
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 |
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, On 2020-06-11 09:39, Trygve Reenskaug wrote: Something has apparently been broken on the journey from 4.5 to 5.3. |
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." |
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 |
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: --
The essence of object orientation is
that objects collaborate to achieve a
goal. |
In reply to this post by K K Subbu
Hi Subbu. 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
|
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
|
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:
--
The essence of object orientation is
that objects collaborate to achieve a
goal. |
Free forum by Nabble | Edit this page |