Re: [Pharo-users] Spotter vs Spotlight was: [Re: Cleaning code completition's namespace]
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
Re: [Pharo-users] Spotter vs Spotlight was: [Re: Cleaning code completition's namespace]
Hi, On Wed, Feb 11, 2015 at 6:25 AM, Laura Risani laura.ris...@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 GTSpotterGlobalShortcutopenGlobalSpotter 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';
Re: [Pharo-users] Spotter vs Spotlight was: [Re: Cleaning code completition's namespace]
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 GTSpotterGlobalShortcutopenGlobalSpotter 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
Re: [Pharo-users] Spotter vs Spotlight was: [Re: Cleaning code completition's namespace]
On Wed, Feb 11, 2015 at 1:25 PM, Laura Risani laura.ris...@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
Re: [Pharo-users] Spotter vs Spotlight was: [Re: Cleaning code completition's namespace]
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.ris...@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 ToolShortcutsopenSpotlight 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
Re: [Pharo-users] Spotter vs Spotlight was: [Re: Cleaning code completition's namespace]
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 nicolaih...@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 tu...@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:
[Pharo-users] 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.ris...@gmail.com wrote: Hi Doru , On Fri, Feb 6, 2015 at 9:40 AM, Tudor Girba tu...@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 :): GTSpotterspotterSelectorsFor: 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
Re: [Pharo-users] Spotter vs Spotlight was: [Re: Cleaning code completition's namespace]
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 tu...@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
Re: [Pharo-users] Spotter vs Spotlight was: [Re: Cleaning code completition's namespace]
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-s-namespace-tp4804409p4804441.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
