Changing playground and monticello shortcuts

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Changing playground and monticello shortcuts

Torsten Bergmann
>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.

Reply | Threaded
Open this post in threaded view
|

Re: Changing playground and monticello shortcuts

kilon.alios
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

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.

Reply | Threaded
Open this post in threaded view
|

Re: Changing playground and monticello shortcuts

Stephan Eggermont-3
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



Reply | Threaded
Open this post in threaded view
|

catalog projects in spotter (Was: Re: Changing playground and monticello shortcuts)

Tudor Girba-2
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 

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