Hi,

Thanks for this mails. I am not just saying it. Even if they take energy, these discussions provide very useful feedback.

On Sun, Feb 8, 2015 at 1:45 AM, Nicolai Hess <nicolaihess@web.de> wrote:
I can understand Lauras point. I used spotlight quite a lot for searching messages and classes, even
if I know the exact name of the message or class, so I don't use it only for "searching" but as an interface
to quickly open a new Browser or MessageList.

There are some minor differences that actually make a big difference, if you are used to it, more below.
BUT and this is a big "but" and an advantage for spotter

1. Spotlight does not find all items and even if you type in a the exact class name that exists, the first entries
spotlight shows, may only include that name. (Searching and opening a browser for String or Morph for example)
2. even if I miss spotlight, the power of spotter (searching everything, extensibility and search in the resultlist) outweigh this for me.


2015-02-07 23:38 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,

��
In contrast, from the perspective of that need, Spotter��
-Doesn't search "names" (class names/selectors) but implementations, overlaping the two actions of the need (when i olny hava a clue and i'm not sure of the name i'm interesed into, i don't care for the list of implementations, is obstrusive "garbage"). Forcing me to unnecessarily think how to do what i want to do. In addition i find it hard to think about the tool because i can't figure out a statement of purpose for it, perhaps "global search for a name", but i'm not sure of "global" because it doesn't do source code.
-Shows me "garbage" i have to mentally filter (world menu, packages, pragmas, ... ).

I think you are misinterpreting the goal of Spotter. It is meant to provide a uniform interface to search all sorts of objects that you see interesting, and it even offers a cheap way to tweak its behavior to your needs. Here is a post that describes it in more details:

This is not quite fair :)
She said, for her spotlight is more useful, you asked for details, she said explained it and your conclusion is " you misinterpeting the goal of spotter" :)

I do not know how else to put it. It was not meant as condescending, but to point out that looking at Spotter from a fixed point of view is not particularly useful and prevents you from seeing its potential.

Even in your post, you treat Spotter for what it already offers in terms of kinds of search, but you do not take into account the possibility of spending half an hour to build the kinds of searches that fit you better. I understand this is a radically new proposition, but because every developer has a different need catering to custom needs is an important ability that should be considered.

We still have to explain the moldability part better.

��
The "minor" differences:
- most of the time I am searching for classes and message, I do not use scripts and rarely search for files.
often, I know what kind of thing I am searching, messages for example, I type in "transform" because I search for a message that starts with that word.
- spotlight shows messages with the word "transform"
- spotter shows classes with the world "Transform", packages with the word "Transform" and than a list of 5 method names.

Ok. Here is another feature that was not made public because it is not completely finished: if you add #i to your search, it will show only the implementors category. So, if you know you are looking for implementors of transform, you can search for:
transform #i

It is still longer than what you search in spotlight, but as you said, it is a generic mechanism.


- spotlight displays just the message name
- spotter shows ClassName>>#messagename ( <- this is more difficult to read because the result entries starting with an unrelated word, the class name)

That is probably a good point. Should it better be "message in Class"?
��
searching for implementors, I often use the search result afterwards.
- spotlight opens a MessageList

Did you check the code I provided in the previous mail? It's one method that I think will add to your Spotter what you describe above.

��
- with spotter I can only open a Browser for one implementor.

Or, you can go inside the implementors and you probably have what you are looking for in the MessageBrowser. Again, this is an opportunity that comes with the new paradigm.

��
Again, the above points are not arguments for spotlight over spotter, they just explain why I am more used to the way spotlight works for the class and method search - I do.

Ok, here is another thing. Shift+Enter opens a default Spotter. But, if really needed, you can easily build your own Spotter and map it on a different key. Just provide a different input object that contains only the extensions to show.��

GTSpotterMorph new
extent: 600@400;
spotterModel: MySpotterModelThatOnlyContainsExtensionsForTheEntryPointsIWant new;
openCenteredInWorld.

In the future we might work on even easier ways to filter and reorder categories. If you do choose this path, please let us know the kinds of things that worked for you. As I mentioned, these input is really important for us.

Cheers,
Doru


--
www.tudorgirba.com

"Every thing has its own flow"