>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. >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? 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. 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. Nonetheless we get really offtopic from the original subject of this thread... Thanks T. |
I am on a 100kb/s connection and never had an issue with Spotter, are we sure here that is just slow connections or maybe something else ? On Thu, Nov 12, 2015 at 3:06 PM Torsten Bergmann <[hidden email]> wrote: >People are saying that they do not want to have the Catalog Projects displayed by default |
On 12-11-15 14:08, Dimitris Chloupis wrote:
> I am on a 100kb/s connection and never had an issue with Spotter, are we > sure here that is just slow connections or maybe something else ? There are two aspects to slow connections: bandwidth and delay. Low bandwidth is probably less of an issue as the amount of data transfered is small (110 KB of json). You need at least a round-trip for the TCP connect and another one for the get request. Stephan |
In reply to this post by Torsten Bergmann
Hi,
I changed the title of the message :). On Nov 12, 2015, at 2:04 PM, Torsten Bergmann <[hidden email]> wrote:People are saying that they do not want to have the Catalog Projects displayed by default It's for people with a slow connection and they lament about the slowdown - not the 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? 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) For any following search the quick cache projects can be used without slowdowns. The server side 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 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 |
Free forum by Nabble | Edit this page |