Guillermo
such people do not know what is ti teach in the university with a fucking
proxy like you and me.
It is super easy when you are not expose to the view of newbies.
PHARO IS NOT WELL PACKAGED guys. Try to get out our confort zone.
The world is different and working.
Stef
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 <[email protected]> wrote:
On Mon, Feb 20, 2017 at 4:05 AM, Torsten Bergmann <[email protected]>
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.
--
Using Opera's mail client: http://www.opera.com/mail/
