Hi, I changed the title of the message :).
On Nov 12, 2015, at 2:04 PM, Torsten Bergmann <astares@gmx.de> wrote:
People are saying that they do not want to have the Catalog Projects displayed by default
Why do you generalize that people wants to have them "not displayedâ? It's for people with a slow connection and they lament about the slowdown - not the functionality. For this group it feels slow when opening Spotter - especially when the JSON rertrieved anytime you open it.
As I said in the worst case one could put:
CatalogSettings displayCatalogProjectsInSpotter: false.
into the startup script or change in settings browser if one works on a really slow connection. This is already in latest Pharo image of today.
We are talking about two different things :). By âdisplay by defaultâ I mean that when you open Spotter the Catalog category is shown and this implies a search is performed even if you do not type anything. You can also choose to not have this be displayed by default, and only appear when you type something. This is what happens for searches like classes or implementors. For example: GTSpotter>>spotterImplementorsFor: aStep <spotterOrder: 30> self flag: #specialFilter. aStep listProcessor title: 'Implementors'; filter: GTFilterImplementor item: [ :filter :context | SystemNavigation default allBehaviorsDo: [ :class | class methodsDo: filter ] ]; wantsToDisplayOnEmptyQuery: false With your solution, you are completely taking it out of Spotter. So, not the same :). I would prefer to have it not query from the very beginning.
Another option is to provide an intermediary object. For example, how would it be if we would dive in the Catalog Browser object from the Menu >category and be able to search for projects?
A possible solution yes - but I dislike that it would again hide the available projects in yet another navigation downpath/sidepath of spotter that one must know and type in advance.
Wasn't the idea of Spotter to "just type" without having to know too much context?
Not really. The main idea of Spotter is to allow you to search from multiple contexts through one unified search interface. Now, that does not mean that a strong top search is not desirable. It certainly is, but it must be scalable.
I think a cache for the catalog projects for the spotter search (that is invalidated at image startup) could solve the problem:
When Spotter opens the FIRST time the projects are retrieved, nonetheless all the other items are already displayed. So the catalog projects appear lazy when retrieved (as it is now). For any following search the quick cache projects can be used without slowdowns. The server side of Catalog only updates each 24 hours anyway - so the contents is usually valid for the image session.
I like this. We could also add a timer that refreshes the image cache after 24h. Would you be interested in proposing a solution for this?
If there are still people left who (due to a real slow connection) find this initial one-time retrieval annoying then they can disable it as described above.
Now that we are on this, there is still an idea to provide the ability of enabling/disabling processors. We did not get around to do it, but we should probably rethink its priority.
Nonetheless we get really offtopic from the original subject of this threadâ¦
Indeed, but it is still valuable. That is why I changed the title :) Doru
Thanks T.
-- www.tudorgirba.com "Be rather willing to give than demanding to get."