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
