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 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"
