As far as I remember, the main problem was not bandwidth but a blocking and non-responsive UI. Imagine I'm in the university, or in a company with a proxy. And I forget to set the proxy. Then, while spotter tries to fetch catalog entries, it would block the image and throw a timeout error some minutes after.
So, maybe for the future and besides Ben's C option (which I like) I have a D) Load catalog entries in background in a non-blocking way - and while catalog entries are not yet available, they should not be shown Even further, It would make sense a solution that mixes Ben's caching with background loading of the catalog entries... Guille On Mon, Feb 20, 2017 at 1:03 AM, Ben Coman <b...@openinworld.com> wrote: > On Mon, Feb 20, 2017 at 4:05 AM, Torsten Bergmann <asta...@gmx.de> wrote: > > In the past in Pharo it was possible to open Spotter, type in the name > of a framework/project to load > > from catalog, perform a search and just hit ENTER to easily install the > project. > > > > This was following the Spotter idea that it is easy to access most > informations of Pharo > > with the Spotter tool. > > > > There always was and still is a setting in "Settings" -> "Catalog" -> > "Display catalog projects in Spotter". > > This setting is ENABLED BY DEFAULT but could be switched off in the > settings tool or custom preference > > scripts if this is problematic for someone. > > > > > > Now in Pharo 6 there is an additional class "GTSpotterExtensionSettings" > to activate/deactivate > > Spotter extensions. While nearly all of the Spotter extensions are > enabled the one for the catalog > > integration is DISABLED BY DEFAULT. > > > > This leads to several effects: > > > > 1. While in the past it was possible in a fresh Pharo image to search > and install out of > > the box it is (as of today in the not yet released Pharo 6) not > possible anymore to quickly > > start by searching and installing from catalog using Spotter. > > > > 2. It is very confusing that in the settings "Display catalog projects > in Spotter" is enabled but a search > > in Spotter gives no results. Most people will not not know about > the second setting and easily > > get lost and think this behavior is just broken. > > Also this second setting for the Spotter extension is much more > hidden between all the other > > Spotter extension enablements very and hard to find. > > Generally its not good to have two settings for the one thing. > > > > > 3. Several of my youtube videos demonstrating Goodies like > DesktopManager, QuickAccess, > > MessageFlowBrowser, ... directly start by loading the tools from > Spotter. Anyone newbee who will > > follow these will not only be confused - but also stuck in trying > Pharo when he learns > > from these videos. > > UI things do evolve and videos date. But these seem worthwhile to keep > current. > > > > > I was asked several times on Slack and via Mail from people who > were not able to reproduce ... this > > is really annyoing. Especially this gives the wrong impression to > newbees. Things should be easy > > not complicated. > > > > To my knowledge disabling the Spotter search in Pharo 6 came up due to > some Pharo teaching in regions > > with slow internet connection. > > This made sense at the time. It is a worse first impression if UI > lags when this central part of the UI is interfaced. > How often would it access the network? Every time? Or did it cache > the result for a day, etc? > > > I understand that we would like to support these Pharo users too as best > > as possible in their out of the box experience ... but (without being > able to prove) I think that 90% or > > more Pharo users have a regular internet connection. Otherwise it would > be hard to work with updates, > > project loading, PharoLauncher, STHub or Iceberg/GitHub. > > > > Also my own personal experience is that even on low bandwidth network > this Catalog Spotter search for > > me was always fast enough (as I often use Pharo in trains with slow > connections or on a Pi with slow > > connections and less processing power). I do not know about all others > from the community. > > > > I invested hours in the past in developing and introducing the initial > configuration browser to Pharo, > > later improved and helped shaping its replacement CatalogBrowser, also > contributed this spotter search > > for the catalog items so things are more accessible, easy and enjoyable. > That's why I also invested > > hours in udpating configs or pushing you to put things into catalog. > > > > Because accessibility is key. Only when things are easy to access and > understandable people will > > enjoy Pharo. > > > > Currently in an out-of the box image this easy access to the projects > via Spotter is blocked. > > Additionally I have to explain to anyone who asks me that there is a > second non-obvious/more hidden setting > > leaving an unpleasant feeling how many others unknown to me will > struggle with this issue. > > > > I see two solutions: > > > > A) We enable both settings by DEFAULT to bring back the Spotter > search and installation > > of catalog items - with the clear benefit of having > > - the previous behavior in Pharo back > > - the out of the box ability to search for catalog projects in > any fresh image > > - no confusion among the user base anymore regarding the > settings > > - we have unbroken Youtube videos that newbees can continue to > follow > > - if a user asks (like often) how to get Seaside, Artefact, > Mongo, Teapot or other projects we can > > just tell him "search in Spotter and you should be fine" as > most of them have a config in > > the catalog. > > > > Remember that not all of us know about all the github pages > or nice Metacello expressions. > > So the easier things are found and accessible the better it > is. > > > > B) If A is still a "No go" for the community we should at a minimum > switch the defaults of > > the two settings: > > > > => we ENABLE the Spotter extension (GTSpotterExtensionSettings > perform: #GTSpotter_spotterCatalogProjectsFor: with: true) > > => we DISABLE the catalog setting (CatalogSettings > displayCatalogProjectsInSpotter: false) > > > > With this at least we have no confusion among the user base > anymore regarding the settings. > > C) Could a STON file of the catalog be cached in the zip of > Image/Changes files? > That zip might be updated daily to keep it current. > Then in a fresh image Spotter searches the cached file for a instant > response, > while the Catalog is updated from the network in the background. > > Even with fast Internet the Catalog should only need to auto-update once a > day, > with results cached in a common file to be accessed when fresh images > are started. > > The Spotter UI might display the last update date as part of the > Catalog sub-heading in its results. > > cheers -ben > > > > > I would clearly and strongly vote for option A as my preferred one. > > > > I agree there are regions/continents with very low bandwidth - but Pharo > will rival with state of the art > > technologies where loading/installation megabytes from the web is often > not seen as an issue. There are > > many package registries out there (from debian packages) up to Maven, > npm in JS, ... or look at Docker. > > Shuffling megabytes around is a reality in todays technologies. > > > > So to be honest I never understood this whole "bandwidth" discussion and > even if this comes up it could > > be solved with a note in the download/welcome screen or pointing to a > custom preference script for low bandwidth > > situations. > > > > Sorry for having to bring this up again ... but I would like this to be > solved BEFORE Pharo 6 will > > be pushed out of the door. Keeping it like it is without further actions > would be really stupid. > > > > Thanks for you comments, ideas or votes. > > > > Thanks > > T. > > > >
