Spotter vs Spotlight was: [Re: Cleaning code completition's namespace]
Hi, Thanks for the detail feedback. I provided some inlined answers and took the liberty of changing the thread subject. On Sat, Feb 7, 2015 at 4:58 PM, Laura Risani <laura.risani@gmail.com> wrote:
Hi Doru ,
On Fri, Feb 6, 2015 at 9:40 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
In the latest Pharo 4 Spotter works properly with the Dark Theme.
Starting from a fresh image (downloaded this week), and doing nothing more than setting the theme to Pharo 3 Dark, GTSpotter shows white, what is curious because GTInspector and GTPlayground show dark.
As mentioned, please try with the latest Pharo. I just tried 40481. The problem is fixed.
Could you elaborate? Where do you see the difference? What do you mean by
"more direct"?
I'll tell you what i think based exclusively on my personal preferences (like the black theme) and not having tried the tool for very long, probably there are additional customizations and features i ignore, so my opinion won't be fully qualified.
I asked for your opinion and that is what I expect. No worries :)
For accessing+navigating the world menu, i like better a global shortcut+the world menu itself, because, unlike Spotter, there is a visual depiction of submenus that let you recognize them beforehand, and when you type to navigate items stay at place so i don't have to visually rescan (to me these qualities are directness ones). In addition, unlike Spotter , word menu opens where the ponter is, so i could choose where to open it if i wanted to.
Spotter is not a tool for accessing menus :). It simply also offers a way to access menus.
To quickly find and/or browse classes and msg implementations/senders is a need i frequently face (many times i know the names and want a quick access without "polluting" where i am), which can occur in two forms, with or without context.
In the contextual case (like browsing from within a class/method) the tool i'm using provides me the browse facilities to address the need.
In the uncontextual case, i have Spotlight and Spotter .
Spotlight addresses the need directly in two steps 1° find the cls/msg "name" 2°open a specialized (info+actions) browser on it in a regular window (modal/movable/resizeable). The model is a simple direct one-to-one mapping of what i want to do, doesn't make me think how to do what i want to do.
This implies that all you want to do is look for a class or for a message. What about a pragma? Or a package? Or a previous script that you used in the Playground? Or global variables? Or a method inside a class? These deserve a way to be found as well, and Spotter is an interface for searching objects.
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: http://www.humane-assessment.com/blog/introducing-gtspotter/ But, you raise an interesting debate on the difference between selectors and implementations. One problem with the MessageBrowser is that it does not allow me to search through the results. In Spotter, you type "do:" and then with Cmd+Shift+Right, you will get the possibility of searching through the results. But, let's take searching for selectors as an example of how to tweak Spotter to search for what you want. Install this method in your image and try searching with Spotter again. It's ugly, but it is working :): GTSpotter>>spotterSelectorsFor: aStep <spotterOrder: 0> | processor | processor := aStep listProcessor. processor title: 'Selectors'; filter: [ :originalQuery :stream | |query selectors | query := originalQuery trimBoth asLowercase. query isEmpty ifFalse: [ selectors := Set new. SystemNavigation default allBehaviorsDo: [:class | class selectorsDo:[ :selector | ((selectors includes: selector) not and: [ selector beginsWith: query ]) ifTrue: [ selectors add: selector. selectors size > 5 ifFalse: [ stream addObject: selector inProcessor: processor ]]]]. selectors ] ]; actLogic: [ :each | self systemNavigation browseAllImplementorsOf: each ] -Only shows me 5 (implementation) results at the time.
You can actually dive into those results and refine the search. If you press Cmd+Shift+RightArrow you will get all the results in the category. We know that this feature is not well offered and we will work on making it more obvious. In the meantime, please give it a try and let me know if it improves the situation.
- Its window misses the useful qualities of a regular one, which are in many cases useful (sometimes i want to keep the list of implementations/senders open). I don't understand the motivation of this absence, why is better to not have/implement them than to do so?
Spotter is meant to first solve the problem of helping you find something and then get out of the way without having you manage the window. For this reason, its window is volatile.
Also i don't understand the motivation of its fixed size/position, i find them annoying, a centered rectangle which impedes me to see anything else and of a size which also makes me hard to read it contents and forces me to scroll, and i "can't" do anything about it because it is fixed, seems a warning sign.
What is a warning sign?
Spotlight opens on a corner giving me the choice of seeing something else if i wanted to.
Given that Spotlight also does not offer a window, I understand that you do not object to the volatile window, but to the size, right? -Because it searches implementations instead of selectors it avoids
MessageBrowser which (to me) offers a much richer experience for browsing impementations/senders (dual views, more info of implementations like its package, more actions).
What do you mean by dual view? Do you mean the preview of sources? If yes, you should take the latest version of Pharo and take a look again. Here is a post that explains that part: http://www.humane-assessment.com/blog/boosting-gtspotter-with-preview/ I want to stress one more time that this is my personal opinion for myself,
and while i probably won't use the tool
I think you will :).
i think that Spotlight and Spotter should coexist as other tools do (like Workspace and Playground) because one tool can't fit all mindsets/preferences.
Sure. But, what makes you say they do not coexist (I did not see this argument above)?
Does anyone know why was Spotlight removed from distribution v4?
Because Spotter is meant to replace it and go beyond it. Cheers, Doru
Cheers, Doru
Thank you for being interested in my opinion. Best, Laura
-- www.tudorgirba.com "Every thing has its own flow"
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: http://www.humane-assessment.com/blog/introducing-gtspotter/
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" :) 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. - 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) searching for implementors, I often use the search result afterwards. - spotlight opens a MessageList - with spotter I can only open a Browser for one implementor. 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. nicolai
Nicolai Hess wrote
Spotlight... 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)
Secret workaround: After typing an exact class/message name e.g. Morph, press the left arrow to close the completion menu before hitting enter and you will get a browser on your intended target instead of MorphBlahBlahBlahThatNoOneProbablyEverSearchedForOnPurpose ;) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spotter-vs-Spotlight-was-Re-Cleaning-code-completition... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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: http://www.humane-assessment.com/blog/introducing-gtspotter/
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"
Hi again Doru , Thanks for the detail feedback. I provided some inlined answers and took
the liberty of changing the thread subject.
It was just a first impression, perhaps once i get to properly know the tool and give it the proper trial period it deserves (as a work someone put dedication on and also as something many knowledgeable people have chosen), i could articulate a more funded opinion. About the thread subject, my intent was to compare both tools just from the perspective of the the need i stated "quickly find and/or browse classes and msg implementations/senders", and argument why for that need i would choose Spotlight, to me they are not comparable from any other perspective. As you state below the purpose of Spotter is "provide a uniform interface to search all sorts of objects that you see interesting", so to me it doesn't seems to rival Spotlight but Finder.
As mentioned, please try with the latest Pharo. I just tried 40481. The problem is fixed.
Dark theme works fine, looks nicer now! Spotter is not a tool for accessing menus :). It simply also offers a way
to access menus.
I wanted to mean that i wouldn't use it instead of world menu, to the end of navigating world menu. Yet it would be an (afaik) innovation if it could search inside all existing menus in the image, and i would use it for that end. This implies that all you want to do is look for a class or for a message.
What about a pragma? Or a package? Or a previous script that you used in the Playground? Or global variables? Or a method inside a class? These deserve a way to be found as well, and Spotter is an interface for searching objects.
Perhaps i wasn't clear enough in my expression. As i said before i wanted to compare just from the perspective of the before mentioned need. I do need to look for all that sort of things, but i have other tools for those, package, method inside a class -> Class Browser pragma, globals -> Finder previous script -> don't know any nice tool. Yet i would use other tools if they offered usability improvements.
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: http://www.humane-assessment.com/blog/introducing-gtspotter/
It states "Until now, the way to search for implementors in Pharo is to open a Playground, enter a the symbol, press *Cmd+m* and then close the Playground window." I don't know if this post is previous to the v3 release i have that comes with Spotlight and a shortcut for it on ToolShortcuts>>openSpotlight Since i'm dark-theme keyword-only minded i stand applaud this feature "The interface is fully controllable through the keyboard. " Also found these ones to be useful innovations "Spotting past Playground pages" "Spotting the last spotted objects" Then the possibility of navigating through related objects of the system in just one window, it is a quite valuable one. To me it resolves with the addition of an optional modifying key to the existing pervading browse shortcuts (senders, implementations, class ...) to address the two equally useful actions of opening a new window and keep open or close current one . About "provide a uniform interface to search all sorts of objects that you see interesting". Do you mean graphic interface, right? I ingenuously pose the question Why is better a uniform GUI for searching? I'm not sure whether the question subject's nature is objective and then we could find an answer or whether it is subjective an all we can get is a set of opinions. I'm not sure what "uniform" mean... is "uniform" as opposed to "specialized"? Doesn't a specialized search result interface, where the searched thing's qualities are known beforehand, let you leverage that context to provide a richer and more efficient interface? To summarize my issues with the GUI are 1) As a keybordian one of my main concerns is keystroke cost of an action, MessageBrowser shows me by default the two pane views (results and method code) cause it is implicit it's dealing with msgs, but in Spotter i have to press a keycombination to bring up the code pane. 2) Not having the regular features of a window that are useful depending on the case, for shortcuting i would like volatile but for browsing results i could depending on the case prefer persistency . Also when i open a window its because my highest priority interest is its content (if not i tile), so i like my windows to open as bigger as they can (yet to get this behavior requires me to do very little code modifications). 3) Main concern is that i can't tell at a glance the purpose and comprehensive features of the tool, an explanation is required. In contrast Finder gives me a list on top row of things that it can find, so it is clear at a glance that it searches narrowed one of those things. For a tool that "searches all sorts of objects" an ideal GUI to me would be 1)"What to search for" . A two key shortcut that opens a kind of somehow logical structured list/table of the names of the types of objects one could search, this window would be "as bigger as possible" and volatile. ( for example "definitions" : class, methods, variables, pragmas interfaces: world menu, all menus code: playgrounds, source metadata: .... complex/custom queries: ... image: ...?... .... ) 2) "Search for it". Each of those names would have a letter underlined and when you press just that letter key a specialized search interface narrowed to that type would show ( for example classes would show their packages methods all MessageBrowser info ) these windows would be regular and one could choose by pressing a modifying key when opening them to make them volatile or not. I want to stress one more time that this is my personal opinion for myself,
and while i probably won't use the tool
I think you will :).
I will give it a try with the added method for sure! With current Spotter's interface i probably keep Spotlight for shortcut access and Spotter+Finder for finding. If the interface was changed to my ideal one, i would use it without hesitation. If not but if i found Spotter functionalities to be innovations of great value then i'd try myself to modify the interface to make it as close as my ideal and use Spotter.
i think that Spotlight and Spotter should coexist as other tools do (like
Workspace and Playground) because one tool can't fit all mindsets/preferences.
Sure. But, what makes you say they do not coexist (I did not see this argument above)?
I misexpressed. I wanted to point out that Spotlight comes no longer in the distribution, the could both come in it, as tools like Workspace and GTPlayground, and many themes. Yet each one can load the packages he likes the most. An applause for Spotter's intent to push the current boundaries of usability! Love, Laura
Hi Laura, Thanks for the detailed answer. Please let's continue this discussion. It will help us figure out how to describe Spotter and maybe it will provide . On Sun, Feb 8, 2015 at 6:27 PM, Laura Risani <laura.risani@gmail.com> wrote:
Hi again Doru ,
Thanks for the detail feedback. I provided some inlined answers and took
the liberty of changing the thread subject.
It was just a first impression, perhaps once i get to properly know the tool and give it the proper trial period it deserves (as a work someone put dedication on and also as something many knowledgeable people have chosen), i could articulate a more funded opinion.
Sure. About the thread subject, my intent was to compare both tools just from the
perspective of the the need i stated "quickly find and/or browse classes and msg implementations/senders", and argument why for that need i would choose Spotlight, to me they are not comparable from any other perspective.
Ok.
As you state below the purpose of Spotter is "provide a uniform interface to search all sorts of objects that you see interesting", so to me it doesn't seems to rival Spotlight but Finder.
Both. And it starts to also overlap the MessageBrowser and the FileBrowser.
As mentioned, please try with the latest Pharo. I just tried 40481. The
problem is fixed.
Dark theme works fine, looks nicer now!
Spotter is not a tool for accessing menus :). It simply also offers a way
to access menus.
I wanted to mean that i wouldn't use it instead of world menu, to the end of navigating world menu. Yet it would be an (afaik) innovation if it could search inside all existing menus in the image, and i would use it for that end.
What do you mean about all existing menus in the image? Right now, the default Spotter searches for the top level entries in the World menu and then lets you dive if you want. It can also be made easily to search for all menu entries from the World menu. Is that what you have in mind?
This implies that all you want to do is look for a class or for a message.
What about a pragma? Or a package? Or a previous script that you used in the Playground? Or global variables? Or a method inside a class? These deserve a way to be found as well, and Spotter is an interface for searching objects.
Perhaps i wasn't clear enough in my expression. As i said before i wanted to compare just from the perspective of the before mentioned need. I do need to look for all that sort of things, but i have other tools for those, package, method inside a class -> Class Browser pragma, globals -> Finder previous script -> don't know any nice tool. Yet i would use other tools if they offered usability improvements.
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: http://www.humane-assessment.com/blog/introducing-gtspotter/
It states "Until now, the way to search for implementors in Pharo is to open a Playground, enter a the symbol, press *Cmd+m* and then close the Playground window." I don't know if this post is previous to the v3 release i have that comes with Spotlight and a shortcut for it on ToolShortcuts>>openSpotlight
Yes, Spotlight is a way to do that too. And it is indeed better than the Playground solution. Still I saw all the time people using Playground for that purpose. Since i'm dark-theme keyword-only minded i stand applaud this feature
"The interface is fully controllable through the keyboard. "
Also found these ones to be useful innovations "Spotting past Playground pages" "Spotting the last spotted objects"
Then the possibility of navigating through related objects of the system in just one window, it is a quite valuable one. To me it resolves with the addition of an optional modifying key to the existing pervading browse shortcuts (senders, implementations, class ...) to address the two equally useful actions of opening a new window and keep open or close current one .
About "provide a uniform interface to search all sorts of objects that you see interesting". Do you mean graphic interface, right?
Both graphical and conceptual. I ingenuously pose the question Why is better a uniform GUI for searching?
I'm not sure whether the question subject's nature is objective and then we could find an answer or whether it is subjective an all we can get is a set of opinions. I'm not sure what "uniform" mean... is "uniform" as opposed to "specialized"? Doesn't a specialized search result interface, where the searched thing's qualities are known beforehand, let you leverage that context to provide a richer and more efficient interface?
In this mail alone you list 4 different search tools: Finder, MessageBrowser, Spotlight, Search in Nautilus. Each of these behaves radically different without much of an added value. The whole philosophy of Smalltalk revolves around a minimal and uniform model that can be used to express elegantly any action. For example, Smalltalk has a simple syntax, and yet you can explain with that simple syntax all things for which other languages require lots of hardcoded constructs. The same rigor should be applied to the user interface. With Spotter we strive to reach such a simple model that can be infinitely moldable to fit custom needs. Now, besides elegance, if any, what else is there? Given that search is such a pervasive action, before I start anything I first want to find an entry point. That can be a method, a class, a file, or whatever other object. To this end, first people think of what tool to use and then of how to find the interesting object inside that tool. With Spotter we want to eliminate the first step: we just open Spotter and start searching for what we want. It's not quite there, but I think it is amazingly close to this goal. To summarize my issues with the GUI are
1) As a keybordian one of my main concerns is keystroke cost of an action, MessageBrowser shows me by default the two pane views (results and method code) cause it is implicit it's dealing with msgs, but in Spotter i have to press a keycombination to bring up the code pane.
Opening a preview is a sticky behavior: once opened/closed, it stays like that for subsequent usages.
2) Not having the regular features of a window that are useful depending on the case, for shortcuting i would like volatile but for browsing results i could depending on the case prefer persistency .
Certainly. The current solution focuses on search. Creating a persistent list of objects is still a work in progress but it is out of scope at the moment.
Also when i open a window its because my highest priority interest is its content (if not i tile), so i like my windows to open as bigger as they can (yet to get this behavior requires me to do very little code modifications).
I do not understand this one. Could you elaborate? 3) Main concern is that i can't tell at a glance the purpose and
comprehensive features of the tool, an explanation is required. In contrast Finder gives me a list on top row of things that it can find, so it is clear at a glance that it searches narrowed one of those things.
For a tool that "searches all sorts of objects" an ideal GUI to me would be 1)"What to search for" . A two key shortcut that opens a kind of somehow logical structured list/table of the names of the types of objects one could search, this window would be "as bigger as possible" and volatile. ( for example "definitions" : class, methods, variables, pragmas interfaces: world menu, all menus code: playgrounds, source metadata: .... complex/custom queries: ... image: ...?... .... )
There will be a hint of the search input box that will list all searchable categories for the current object. Keep in mind that because we have diving possibility, every object can define what can be interesting to search. So, there isn't a single list of categories but there are many lists. For example, right now, there are some 59 such extensions in the image. To find them, you can search for the spotterOrder: pragma, dive in, and then you will see all methods that references this pragma.
2) "Search for it". Each of those names would have a letter underlined and when you press just that letter key a specialized search interface narrowed to that type would show ( for example classes would show their packages methods all MessageBrowser info ) these windows would be regular and one could choose by pressing a modifying key when opening them to make them volatile or not.
This already works. As explained before, something like: d #i will give you only the implementors of "d". So, # will search for the name of the category. This feature is not yet complete in that it does not highlight properly the results, but could you try to see if this fits what you have in mind? I want to stress one more time that this is my personal opinion for myself,
and while i probably won't use the tool
I think you will :).
I will give it a try with the added method for sure! With current Spotter's interface i probably keep Spotlight for shortcut access and Spotter+Finder for finding.
If the interface was changed to my ideal one, i would use it without
hesitation. If not but if i found Spotter functionalities to be innovations of great value then i'd try myself to modify the interface to make it as close as my ideal and use Spotter.
Did you try compiling the method that I sent in the previous mail (basically just copy paste that method in the GTSpotter class)? It should provide the behavior of Spotlight. Please try and let me know if it works for you. Cheers, Doru
i think that Spotlight and Spotter should coexist as other tools do
(like Workspace and Playground) because one tool can't fit all mindsets/preferences.
Sure. But, what makes you say they do not coexist (I did not see this argument above)?
I misexpressed. I wanted to point out that Spotlight comes no longer in the distribution, the could both come in it, as tools like Workspace and GTPlayground, and many themes. Yet each one can load the packages he likes the most.
An applause for Spotter's intent to push the current boundaries of
usability!
Love, Laura
-- www.tudorgirba.com "Every thing has its own flow"
What do you mean about all existing menus in the image? Right now, the default Spotter searches for the top level entries in the World menu and then lets you dive if you want. It can also be made easily to search for all menu entries from the World menu. Is that what you have in mind?
At that moment i thought of searching on all existing menu entries, for example if Spotter-search for "Browse" menu-category results will include "Browse scoped" (an entry of a menu you get for classes on the ClassBrowser). Yet at this moment i'm not sure of how useful it could be.
In this mail alone you list 4 different search tools: Finder, MessageBrowser, Spotlight, Search in Nautilus. Each of these behaves radically different without much of an added value.
The whole philosophy of Smalltalk revolves around a minimal and uniform model that can be used to express elegantly any action. For example, Smalltalk has a simple syntax, and yet you can explain with that simple syntax all things for which other languages require lots of hardcoded constructs. The same rigor should be applied to the user interface. With Spotter we strive to reach such a simple model that can be infinitely moldable to fit custom needs.
Now, besides elegance, if any, what else is there? Given that search is such a pervasive action, before I start anything I first want to find an entry point. That can be a method, a class, a file, or whatever other object. To this end, first people think of what tool to use and then of how to find the interesting object inside that tool. With Spotter we want to eliminate the first step: we just open Spotter and start searching for what we want. It's not quite there, but I think it is amazingly close to this goal.
I liked a lot these paragraphs in theirself and also as a motivation for Spotter. 2) Not having the regular features of a window that are useful depending on
the case, for shortcuting i would like volatile but for browsing results i could depending on the case prefer persistency .
Certainly. The current solution focuses on search. Creating a persistent list of objects is still a work in progress but it is out of scope at the moment.
If at the method GTSpotterGlobalShortcut>>openGlobalSpotter one changes #openInWorld by #openInWindow , one gets the persistent behavior (it also includes the preview if opened). So now i can open a volatile or persistent Spotter, i'm going to have a keycombination for each one. In addition i get all the regular window behavior i in some cases want. This makes me really happy :) Only one little keybordian issue, Cmd+w doesn't close the window as usual, the same happens with GTPlayground. It would be nice if these come implemented so one doesn't have to add them.
This already works. As explained before, something like: d #i
will give you only the implementors of "d". So, # will search for the name of the category. This feature is not yet complete in that it does not highlight properly the results, but could you try to see if this fits what you have in mind?
I've just read about that, and also the last bit on custom categories on the blog. So now i will define a category for classes+selectors and map a keycombination to open a volatile Spotter on ti, and remove the 5 results limit (how do i do this?). This gives me my wanted "selector/class shortcut" Spotlight provided me, improving the annoying deficiency Spotlight has of showing no-longer defined names (i asked about it in a recent mail to the list). Having a shortcut (Cmd+Shift+ArrowUp/ArrowDown) to jump through categories, then why to limit the number of results in each category to 5? Why not to show them all to avoid the need of going into the category?
Did you try compiling the method that I sent in the previous mail (basically just copy paste that method in the GTSpotter class)? It should provide the behavior of Spotlight. Please try and let me know if it works for you.
Yes, it works at some degree. I face this issue, if i type 'openIn' i get only 1/1 selector #openeningDelimiters, and only if i continue to type 'openInW' i get 5/28 selectors. Also at some point i started to get an #inform: msg saying "WorldState interCyclePause failed". So additions i would like to see built by default Cmd+w to close on GTSpotter and GTPlayground. Remove/know-how-to remove the 5 limit on results. Selectors category. Font size configured at SystemBrowser to have effect on GTSpotter both on search results and preview. To summarize i love Spotter and it will be the tool i use the most (in number of openings). Love, Laura
On Wed, Feb 11, 2015 at 1:25 PM, Laura Risani <laura.risani@gmail.com> wrote:
Also at some point i started to get an #inform: msg saying "WorldState interCyclePause failed".
Thats not GTSpotter. That was my fault since build 40477 integrated Issue 14669. This should be fixed since Issue 40874 was integrated into build 40486 . cheers -ben
Hi, On Wed, Feb 11, 2015 at 6:25 AM, Laura Risani <laura.risani@gmail.com> wrote:
What do you mean about all existing menus in the image? Right now, the
default Spotter searches for the top level entries in the World menu and then lets you dive if you want. It can also be made easily to search for all menu entries from the World menu. Is that what you have in mind?
At that moment i thought of searching on all existing menu entries, for example if Spotter-search for "Browse" menu-category results will include "Browse scoped" (an entry of a menu you get for classes on the ClassBrowser). Yet at this moment i'm not sure of how useful it could be.
In this mail alone you list 4 different search tools: Finder, MessageBrowser, Spotlight, Search in Nautilus. Each of these behaves radically different without much of an added value.
The whole philosophy of Smalltalk revolves around a minimal and uniform model that can be used to express elegantly any action. For example, Smalltalk has a simple syntax, and yet you can explain with that simple syntax all things for which other languages require lots of hardcoded constructs. The same rigor should be applied to the user interface. With Spotter we strive to reach such a simple model that can be infinitely moldable to fit custom needs.
Now, besides elegance, if any, what else is there? Given that search is such a pervasive action, before I start anything I first want to find an entry point. That can be a method, a class, a file, or whatever other object. To this end, first people think of what tool to use and then of how to find the interesting object inside that tool. With Spotter we want to eliminate the first step: we just open Spotter and start searching for what we want. It's not quite there, but I think it is amazingly close to this goal.
I liked a lot these paragraphs in theirself and also as a motivation for Spotter.
2) Not having the regular features of a window that are useful depending
on the case, for shortcuting i would like volatile but for browsing results i could depending on the case prefer persistency .
Certainly. The current solution focuses on search. Creating a persistent list of objects is still a work in progress but it is out of scope at the moment.
If at the method GTSpotterGlobalShortcut>>openGlobalSpotter one changes #openInWorld by #openInWindow , one gets the persistent behavior (it also includes the preview if opened). So now i can open a volatile or persistent Spotter, i'm going to have a keycombination for each one. In addition i get all the regular window behavior i in some cases want. This makes me really happy :)
Only one little keybordian issue, Cmd+w doesn't close the window as usual, the same happens with GTPlayground. It would be nice if these come implemented so one doesn't have to add them.
Spotter is not yet meant to be used in a window. The rendering is really not appropriate for that :). Cmd+w should work for Playground. Does it not? Indeed openInWindow does not install the Cmd+W action, but that is morphic specific.
This already works. As explained before, something like:
d #i
will give you only the implementors of "d". So, # will search for the name of the category. This feature is not yet complete in that it does not highlight properly the results, but could you try to see if this fits what you have in mind?
I've just read about that, and also the last bit on custom categories on the blog. So now i will define a category for classes+selectors and map a keycombination to open a volatile Spotter on ti, and remove the 5 results limit (how do i do this?). This gives me my wanted "selector/class shortcut" Spotlight provided me, improving the annoying deficiency Spotlight has of showing no-longer defined names (i asked about it in a recent mail to the list).
Having a shortcut (Cmd+Shift+ArrowUp/ArrowDown) to jump through categories, then why to limit the number of results in each category to 5? Why not to show them all to avoid the need of going into the category?
Because you still want to have an overview of what is being detected. Spotter should not be optimized for the default pane that is being opened. It has to handle any object. Nevertheless, we do need a more obvious way to show the all items.
Did you try compiling the method that I sent in the previous mail
(basically just copy paste that method in the GTSpotter class)? It should provide the behavior of Spotlight. Please try and let me know if it works for you.
Yes, it works at some degree. I face this issue, if i type 'openIn' i get only 1/1 selector #openeningDelimiters, and only if i continue to type 'openInW' i get 5/28 selectors.
There was a mistake in the algorithm as the matching was case sensitive which is not useful in our case. So, try this: spotterSelectorsFor: aStep <spotterOrder: 0> | processor | processor := aStep listProcessor. processor title: 'Selectors'; filter: [ :originalQuery :stream | |query selectors | query := originalQuery trimBoth asLowercase. query isEmpty ifFalse: [ selectors := Set new. SystemNavigation default allBehaviorsDo: [:class | class selectorsDo:[ :selector | ((selectors includes: selector) not and: [ selector *asLowercase* beginsWith: query ]) ifTrue: [ selectors add: selector. selectors size > 5 ifFalse: [ stream addObject: selector inProcessor: processor ]]]]. selectors ] ]; actLogic: [ :each | self systemNavigation browseAllImplementorsOf: each ]
Also at some point i started to get an #inform: msg saying "WorldState interCyclePause failed".
As Ben suggested, this is a separate issue.
So additions i would like to see built by default Cmd+w to close on GTSpotter and GTPlayground.
This works. Could you explain what you do (including the versions and OS you use)?
Remove/know-how-to remove the 5 limit on results.
Every processor is defined in a class extensions annotated with <spotterPreview:>. The processor can specify the limit. Right now, the implementations specify 5 items. You can play with variations.
Selectors category.
You can just install this in your image. That is the whole point of a moldable tool: that you have the power of easily specifying what works for you. Font size configured at SystemBrowser to have effect on GTSpotter both on
search results and preview.
Good point. Could you open a Pharo issue for this one?
To summarize i love Spotter and it will be the tool i use the most (in number of openings).
You see :) Thanks, Doru
Love, Laura
-- www.tudorgirba.com "Every thing has its own flow"
Hi, There was a mistake in the algorithm as the matching was case sensitive
which is not useful in our case. So, try this:
spotterSelectorsFor: aStep (...)
Works perfect. So additions i would like to see built by default
Cmd+w to close on GTSpotter and GTPlayground.
This works. Could you explain what you do (including the versions and OS you use)?
You're right, Cmd+w works fine, i forgot i had changed Cmd key.
Remove/know-how-to remove the 5 limit on results.
Every processor is defined in a class extensions annotated with <spotterPreview:>. The processor can specify the limit. Right now, the implementations specify 5 items. You can play with variations.
Thank you for the tip. Font size configured at SystemBrowser to have effect on GTSpotter both on
search results and preview.
Good point. Could you open a Pharo issue for this one?
Done, number 14933 . Love, Laura
participants (5)
-
Ben Coman -
Laura Risani -
Nicolai Hess -
Sean P. DeNigris -
Tudor Girba