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 <asta...@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. > > >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. > >
