Smalltalk › Squeak › Squeak - Dev

"find method" changes

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

22 messages Options

Chris Muller-3

"find method" changes

We have a UI problem in the context menu for classes. "find method"
essentially produces a redundancy of the methods list, except
demanding that the user to actually click a little area labelled
"accept" before Squeak will show the method. This is just wrong in
multiple ways, embarassingly bad. And so, I'd just like to warn
everyone that, barring any major objections, I intend to get out my
buzz saw and improve Squeak.

My plans are to remove the existing "find method..." behavior which
produces the redundant panel and replace it with the wild-card dialog
produced currently by "find method wildcard...". "find method
wildcard..." will be removed from the menu. Of course the hot-key
(Command+f) will still work to produce the wildcard dialog.

Sorry, this is a chance to repeat one of my favorite axioms: "if you
have two things that are almost the same, then you should either make
them the same or make them very different." :)

Ridding Squeak of this user-controlling, energy-sapping panel will
definitely be a increment in the right direction.

Ok?

laza

Re: "find method" changes

fine with me

On Sun, Mar 7, 2010 at 02:09, Chris Muller <[hidden email]> wrote:

> We have a UI problem in the context menu for classes. "find method"
> essentially produces a redundancy of the methods list, except
> demanding that the user to actually click a little area labelled
> "accept" before Squeak will show the method. This is just wrong in
> multiple ways, embarassingly bad. And so, I'd just like to warn
> everyone that, barring any major objections, I intend to get out my
> buzz saw and improve Squeak.
>
> My plans are to remove the existing "find method..." behavior which
> produces the redundant panel and replace it with the wild-card dialog
> produced currently by "find method wildcard...". "find method
> wildcard..." will be removed from the menu. Of course the hot-key
> (Command+f) will still work to produce the wildcard dialog.
>
> Sorry, this is a chance to repeat one of my favorite axioms: "if you
> have two things that are almost the same, then you should either make
> them the same or make them very different." :)
>
> Ridding Squeak of this user-controlling, energy-sapping panel will
> definitely be a increment in the right direction.
>
> Ok?
>
>

Michael Davies-2

Re: "find method" changes

In reply to this post by Chris Muller-3

On 7 March 2010 02:09, Chris Muller <[hidden email]> wrote:

...
My plans are to remove the existing "find method..." behavior which
produces the redundant panel and replace it with the wild-card dialog
produced currently by "find method wildcard...". "find method
wildcard..." will be removed from the menu. Of course the hot-key
(Command+f) will still work to produce the wildcard dialog.
...

My curiosity was piqued when I read this email, and on digging I found that there are a surprising number of different behaviours associated with the two "find method" menu items! It looks like many of these routes are there to work around problems with the core menu-based selection dialog. I spent a little time examining those behaviours and trying to understand what the thinking was behind each.

I suspect they all started with the simple aim of "Bring up a dialog with a given title, and a list of items, and let me know which was picked", but then incrementally added more features:
-Let the user see all options in the list easily.
-Allow them to use mouse to move to an entry and activate it (support direct click [or double-click], and pressing an Accept button)
-Allow use of the keyboard to incrementally filter out / disable entries as the user types a substring. Allow backspace to undo characters.
-Keep a matching item selected at all times while the filtering substring is changed, and allow the arrow keys to change this selection.
-Allow <enter> and <cmd-s> to choose the selected item, and <esc> and <cmd-l> to cancel the dialog without selection.
-Ensure that closing the window cancels the dialog without selection.
-Have a visible Accept and Cancel button to help new users navigate their way around.
-Let me know that the dialog was cancelled.

The reason that I thought it was worth going into this detail is that there's a good chance that some people will be deeply attached to each of these features. If it's possible to do all this in one re-usable dialog, then that would be useful in many other places in Squeak.

I've put a simple solution together, and I'd like to let people kick it about a bit to see if this seems a worthwhile exercise, and if it needs more work. It's designed to be a drop-in replacement for ChooserTool, and should be quite simple to integrate into other corners as well.

Cheers, Michael

MAD-ListChooser.st (11K) Download Attachment

Chris Muller-3

Re: "find method" changes

Michael, this is absolutely fantastic. You seem to have read my mind
with nearly every usability feature that you mentioned. Nice code,
too!

> I suspect they all started with the simple aim of "Bring up a dialog with a
> given title, and a list of items, and let me know which was picked", but
> then incrementally added more features:
> -Let the user see all options in the list easily.
> -Allow them to use mouse to move to an entry and activate it (support direct
> click [or double-click], and pressing an Accept button)

Yes of course, and this is where many designers stop caring. Argh!

> -Allow use of the keyboard to incrementally filter out / disable entries as
> the user types a substring. Allow backspace to undo characters.

yes.

> -Keep a matching item selected at all times while the filtering substring is
> changed, and allow the arrow keys to change this selection.

Yes.

> -Allow <enter> and <cmd-s> to choose the selected item, and <esc> and
> <cmd-l> to cancel the dialog without selection.

Yes!

> -Ensure that closing the window cancels the dialog without selection.
> -Have a visible Accept and Cancel button to help new users navigate their
> way around.
> -Let me know that the dialog was cancelled.

I love it. May I assume an MIT license on this code? If so, I would
like to integrate this into the trunk, to replace ChooserTool.

I do have a couple of questions.

- Is there a reason you chose to answer the index or 0 rather than
the object selected or nil? The only way this could possibly convey
more information is if you have duplicate entries in the list, which
seems very unlikely.. The cost is that the developer has to index
back into some list, which may have originated from a non-Sequenceable
collection, forcing him to keep create and remember transient one to
index back into just to use it.

- I'll take the filtering the way it is, but since you are obviously
one who cares about refined usability, I will tell you what my one
additional usability idea.. Order the results so that left-matches
are before mid-string matches.

Thanks again for this work!

- Chris

Chris Muller-3

Re: "find method" changes

> - Is there a reason you chose to answer the index or 0 rather than
> the object selected or nil? The only way this could possibly convey
> more information is if you have duplicate entries in the list, which
> seems very unlikely.. The cost is that the developer has to index
> back into some list, which may have originated from a non-Sequenceable
> collection, forcing him to keep create and remember transient one to
> index back into just to use it.

Ah, I just looked at ChooserTool and answered my own question. I
agree that drop-in replacement for ChooserTool is the way to go, even
if I feel my question has merit.

Levente Uzonyi-2

Re: "find method" changes

In reply to this post by Chris Muller-3

On Wed, 10 Mar 2010, Chris Muller wrote:

> Michael, this is absolutely fantastic. You seem to have read my mind
> with nearly every usability feature that you mentioned. Nice code,
> too!
>
>> I suspect they all started with the simple aim of "Bring up a dialog with a
>> given title, and a list of items, and let me know which was picked", but
>> then incrementally added more features:
>> -Let the user see all options in the list easily.
>> -Allow them to use mouse to move to an entry and activate it (support direct
>> click [or double-click], and pressing an Accept button)
>
> Yes of course, and this is where many designers stop caring. Argh!
>
>> -Allow use of the keyboard to incrementally filter out / disable entries as
>> the user types a substring. Allow backspace to undo characters.
>
> yes.
>
>> -Keep a matching item selected at all times while the filtering substring is
>> changed, and allow the arrow keys to change this selection.
>
> Yes.
>
>> -Allow <enter> and <cmd-s> to choose the selected item, and <esc> and
>> <cmd-l> to cancel the dialog without selection.
>
> Yes!
>
>> -Ensure that closing the window cancels the dialog without selection.
>> -Have a visible Accept and Cancel button to help new users navigate their
>> way around.
>> -Let me know that the dialog was cancelled.
>
> I love it. May I assume an MIT license on this code? If so, I would
> like to integrate this into the trunk, to replace ChooserTool.
>
> I do have a couple of questions.
>
> - Is there a reason you chose to answer the index or 0 rather than
> the object selected or nil? The only way this could possibly convey
> more information is if you have duplicate entries in the list, which
> seems very unlikely.. The cost is that the developer has to index
> back into some list, which may have originated from a non-Sequenceable
> collection, forcing him to keep create and remember transient one to
> index back into just to use it.

The implementation assumes that the list is a SequenceableCollection.

>
> - I'll take the filtering the way it is, but since you are obviously
> one who cares about refined usability, I will tell you what my one
> additional usability idea.. Order the results so that left-matches
> are before mid-string matches.
>
> Thanks again for this work!
>
> - Chris
>
>

This new chooser is great. The only thing I don't like about it is that if
I press enter when the list is empty, it cancels the selection. For
example if I print this: ListChooser chooseFrom: #(foo bar baz)
and accidentally press v<enter> instead of b<enter>, the return value will
be 0.

Levente

Chris Muller-4

Re: "find method" changes

> This new chooser is great. The only thing I don't like about it is that if I
> press enter when the list is empty, it cancels the selection. For example if
> I print this: ListChooser chooseFrom: #(foo bar baz)
> and accidentally press v<enter> instead of b<enter>, the return value will
> be 0.

What do you want it to return in that case?

Michael Davies-2

Re: "find method" changes

In reply to this post by Chris Muller-3

On 11 March 2010 04:26, Chris Muller <[hidden email]> wrote:

Michael, this is absolutely fantastic. You seem to have read my mind
with nearly every usability feature that you mentioned. Nice code,
too!

That's very kind of you. Of course my thanks go to you for the inspiration to look at this area, and to the existing ChooserTool and UserDialog which have some interesting code in them.

I love it. May I assume an MIT license on this code? If so, I would
like to integrate this into the trunk, to replace ChooserTool.

Yes, MIT licence is perfect. Please feel free to integrate the code.

I do have a couple of questions.

- Is there a reason you chose to answer the index or 0 rather than
the object selected or nil? The only way this could possibly convey
more information is if you have duplicate entries in the list, which
seems very unlikely.. The cost is that the developer has to index
back into some list, which may have originated from a non-Sequenceable
collection, forcing him to keep create and remember transient one to
index back into just to use it.

As you saw, for compatibility with the ListChooser. On reflection, it's not unreasonable to support #chooseIndexFrom:/#chooseItemFrom: methods.

- I'll take the filtering the way it is, but since you are obviously
one who cares about refined usability, I will tell you what my one
additional usability idea.. Order the results so that left-matches
are before mid-string matches.

I thought about this, but I'd only feel happy about presenting a mixed list to the user if we could find a clear way to present that, and I wasn't up to that on the first pass.

Andreas.Raab

Re: "find method" changes

On 3/11/2010 12:59 AM, Michael Davies wrote:

> On 11 March 2010 04:26, Chris Muller <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> Michael, this is absolutely fantastic. You seem to have read my mind
> with nearly every usability feature that you mentioned. Nice code,
> too!
>
> That's very kind of you. Of course my thanks go to you for the
> inspiration to look at this area, and to the existing ChooserTool and
> UserDialog which have some interesting code in them.

For the records (and as sort of a lame me too :-) I'm two thumbs up on
the ListChooser as well. It's much better than what was there.

Cheers,
- Andreas

>
> I love it. May I assume an MIT license on this code? If so, I would
> like to integrate this into the trunk, to replace ChooserTool.
>
> Yes, MIT licence is perfect. Please feel free to integrate the code.
>
> I do have a couple of questions.
>
> - Is there a reason you chose to answer the index or 0 rather than
> the object selected or nil? The only way this could possibly convey
> more information is if you have duplicate entries in the list, which
> seems very unlikely.. The cost is that the developer has to index
> back into some list, which may have originated from a non-Sequenceable
> collection, forcing him to keep create and remember transient one to
> index back into just to use it.
>
> As you saw, for compatibility with the ListChooser. On reflection, it's
> not unreasonable to support #chooseIndexFrom:/#chooseItemFrom: methods.
>
> - I'll take the filtering the way it is, but since you are obviously
> one who cares about refined usability, I will tell you what my one
> additional usability idea.. Order the results so that left-matches
> are before mid-string matches.
>
> I thought about this, but I'd only feel happy about presenting a mixed
> list to the user if we could find a clear way to present that, and I
> wasn't up to that on the first pass.
>
>
>
>

Michael Davies-2

Re: "find method" changes

In reply to this post by Levente Uzonyi-2

On 11 March 2010 04:54, Levente Uzonyi <[hidden email]> wrote:

The implementation assumes that the list is a SequenceableCollection.

Good point.

- I'll take the filtering the way it is, but since you are obviously
one who cares about refined usability, I will tell you what my one
additional usability idea.. Order the results so that left-matches
are before mid-string matches.

Thanks again for this work!

- Chris

This new chooser is great. The only thing I don't like about it is that if I press enter when the list is empty, it cancels the selection.

You caught me out there :-). I originally ignored attempts to submit the dialog when there wasn't a valid entry, but this left me with <cr> characters in the text field, so I temporarily changed it to emulate cancel while thinking about how to deal with that.

Michael Davies-2

Re: "find method" changes

In reply to this post by Michael Davies-2

On 11 March 2010 09:59, Michael Davies <[hidden email]> wrote:

On 11 March 2010 04:26, Chris Muller <[hidden email]> wrote:

I love it. May I assume an MIT license on this code? If so, I would
like to integrate this into the trunk, to replace ChooserTool.

Yes, MIT licence is perfect. Please feel free to integrate the code.

Actually one point that I'm unhappy about is the introduction of the UnpluggedListMorph - if this is going into the trunk, I think it would be better to update PluggableListMorph with a setting to allow the model full access to the morph's keyboard events.

Igor Stasenko

Re: "find method" changes

On 11 March 2010 11:20, Michael Davies <[hidden email]> wrote:

> On 11 March 2010 09:59, Michael Davies <[hidden email]> wrote:
>>
>>
>> On 11 March 2010 04:26, Chris Muller <[hidden email]> wrote:
>>
>>> I love it. May I assume an MIT license on this code? If so, I would
>>> like to integrate this into the trunk, to replace ChooserTool.
>>>
>> Yes, MIT licence is perfect. Please feel free to integrate the code.
>
> Actually one point that I'm unhappy about is the introduction of the
> UnpluggedListMorph - if this is going into the trunk, I think it would be
> better to update PluggableListMorph with a setting to allow the model full
> access to the morph's keyboard events.
>
>

[slight OT]
Michael , you having a very good sense of humor, i'd say.
Initials - MAD. UnpluggedListMorph

Rofl. And wellcome :)))

>
>

--
Best regards,
Igor Stasenko AKA sig.

Levente Uzonyi-2

Re: "find method" changes

In reply to this post by Chris Muller-4

On Wed, 10 Mar 2010, Chris Muller wrote:

>> This new chooser is great. The only thing I don't like about it is that if I
>> press enter when the list is empty, it cancels the selection. For example if
>> I print this: ListChooser chooseFrom: #(foo bar baz)
>> and accidentally press v<enter> instead of b<enter>, the return value will
>> be 0.
>
> What do you want it to return in that case?
>

Nothing, don't select anything in this case, optionally Beeper
beepPrimitive.

Levente

Tapple Gao

Re: "find method" changes

In reply to this post by Chris Muller-3

On Sat, Mar 06, 2010 at 07:09:06PM -0600, Chris Muller wrote:
> We have a UI problem in the context menu for classes. "find method"
> essentially produces a redundancy of the methods list, except
> demanding that the user to actually click a little area labelled
> "accept" before Squeak will show the method. This is just wrong in
> multiple ways, embarassingly bad. And so, I'd just like to warn
> everyone that, barring any major objections, I intend to get out my
> buzz saw and improve Squeak.

What is "find method"?

--
Matthew Fulmer (a.k.a. Tapple)

Nicolas Cellier

Re: "find method" changes

In reply to this post by Michael Davies-2

2010/3/11 Michael Davies <[hidden email]>:

>
>
> On 11 March 2010 04:26, Chris Muller <[hidden email]> wrote:
>>
>> Michael, this is absolutely fantastic. You seem to have read my mind
>> with nearly every usability feature that you mentioned. Nice code,
>> too!
>>
> That's very kind of you. Of course my thanks go to you for the inspiration
> to look at this area, and to the existing ChooserTool and UserDialog which
> have some interesting code in them.
>
>>
>> I love it. May I assume an MIT license on this code? If so, I would
>> like to integrate this into the trunk, to replace ChooserTool.
>>
> Yes, MIT licence is perfect. Please feel free to integrate the code.
>

Sorry for the stupid question, doesn't it have to be a bit more formal ?

Nicolas

>>
>> I do have a couple of questions.
>>
>> - Is there a reason you chose to answer the index or 0 rather than
>> the object selected or nil? The only way this could possibly convey
>> more information is if you have duplicate entries in the list, which
>> seems very unlikely.. The cost is that the developer has to index
>> back into some list, which may have originated from a non-Sequenceable
>> collection, forcing him to keep create and remember transient one to
>> index back into just to use it.
>>
> As you saw, for compatibility with the ListChooser. On reflection, it's not
> unreasonable to support #chooseIndexFrom:/#chooseItemFrom: methods.
>
>>
>> - I'll take the filtering the way it is, but since you are obviously
>> one who cares about refined usability, I will tell you what my one
>> additional usability idea.. Order the results so that left-matches
>> are before mid-string matches.
>>
> I thought about this, but I'd only feel happy about presenting a mixed list
> to the user if we could find a clear way to present that, and I wasn't up to
> that on the first pass.
>
>
>
>
>

Michael Davies-2

Re: "find method" changes

On 11 March 2010 21:45, Nicolas Cellier <[hidden email]> wrote:

2010/3/11 Michael Davies <[hidden email]>:

>>
> Yes, MIT licence is perfect. Please feel free to integrate the code.
>

Sorry for the stupid question, doesn't it have to be a bit more formal ?

Dunno, I would have thought that giving permission in the same thread as publishing the code is good enough, but in case we do fall out later, here's the same code with "Released under the MIT Licence" added.

Is there a public space to quickly publish a copy of non-Monticello code to make a clear indication of intent to release it under the MIT licence? How about a public email address ([hidden email]?) that I can forward an email and attachment to? That's got to be the simplest possible thing that would work.

MAD-ListChooser.st (12K) Download Attachment

Nicolas Cellier

Re: "find method" changes

2010/3/11 Michael Davies <[hidden email]>:

Me neither.
Pharo contributors are asked to sign an agreement.
Squeak/trunk is more simple If I understood: what you post in trunk
and/or inbox is automatically MIT.
But I don't see how this would apply to posting on behalf of a third party...
Better ask a stupid question than running into future legal mess...

Anyway, thank you

Nicolas

> Is there a public space to quickly publish a copy of non-Monticello code to
> make a clear indication of intent to release it under the MIT licence? How
> about a public email address ([hidden email]?) that I can forward an
> email and attachment to? That's got to be the simplest possible thing that
> would work.
>
>
>
>

johnmci

Re: "find method" changes

On 2010-03-11, at 1:51 PM, Nicolas Cellier wrote:

> Me neither.
> Pharo contributors are asked to sign an agreement.
> Squeak/trunk is more simple If I understood: what you post in trunk
> and/or inbox is automatically MIT.
> But I don't see how this would apply to posting on behalf of a third party...
> Better ask a stupid question than running into future legal mess...
>
> Anyway, thank you
>
> Nicolas

I look forward to the web page that explains the choices that http://conservancy.softwarefreedom.org/
have dictated are the solution for the Squeak community in order to end confusion. Nothing worse
than a confused corporate lawyer when explaining where the code came from.

--
===========================================================================
John M. McIntosh <[hidden email]> Twitter: squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================

keith1y

Re: "find method" changes

In reply to this post by Nicolas Cellier

In the "grow" process just described every source file exported has a
licence statement appended.

Keith

Karl Ramberg

Re: "find method" changes

In reply to this post by Michael Davies-2

You could post it as and enhancement on mantis

Karl

On Thu, Mar 11, 2010 at 10:43 PM, Michael Davies
<[hidden email]> wrote:

> On 11 March 2010 21:45, Nicolas Cellier <[hidden email]>
> wrote:
>>
>> 2010/3/11 Michael Davies <[hidden email]>:
>> >>
>> > Yes, MIT licence is perfect. Please feel free to integrate the code.
>> >
>>
>> Sorry for the stupid question, doesn't it have to be a bit more formal ?
>
> Dunno, I would have thought that giving permission in the same thread as
> publishing the code is good enough, but in case we do fall out later, here's
> the same code with "Released under the MIT Licence" added.
>
> Is there a public space to quickly publish a copy of non-Monticello code to
> make a clear indication of intent to release it under the MIT licence? How
> about a public email address ([hidden email]?) that I can forward an
> email and attachment to? That's got to be the simplest possible thing that
> would work.
>
>
>
>