- Pharo-users - lists.pharo.org

Re: [Pharo-users] Smalltalks video recordings?

by Dimitris Chloupis

me too :) On Fri, Nov 13, 2015 at 3:11 AM Stephan Eggermont <stephan(a)stack.nl> wrote: > On 12/11/15 19:57, Esteban A. Maringolo wrote: > > It is being recorded. And the slides being collected. So I guess they > > will be made public soon. > > Great. I'm looking forward to them > > Stephan > > > >

Nov. 13, 2015

Re: [Pharo-users] Smalltalks video recordings?

by Stephan Eggermont

On 12/11/15 19:57, Esteban A. Maringolo wrote: > It is being recorded. And the slides being collected. So I guess they > will be made public soon. Great. I'm looking forward to them Stephan

Nov. 13, 2015

Re: [Pharo-users] FileDialog from Spec

by Henrik Nergaard

Hi Jeff, Here is an example to bring up the file dialog answering a file reference. | reference | reference := UIManager default fileSave: 'Save as?' extensions: #('pdf' 'png' 'stuff') path: Smalltalk imageDirectory. For other examples see MorphicUIManager where methods start with file* Best regards, Henrik -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Jeff Gray Sent: Thursday, November 12, 2015 11:22 PM To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] FileDialog from Spec I just want to call a dialog on a button click. What approach do I take with the Polymorph one? Do I have to open a Polymorph window which then calls the dialog or can I bake the Polymorph dialog into my spec window? -- View this message in context: http://forum.world.st/FileDialog-from-Spec-tp4860608p4860782.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 12, 2015

Re: [Pharo-users] FileDialog from Spec

by Jeff Gray

I just want to call a dialog on a button click. What approach do I take with the Polymorph one? Do I have to open a Polymorph window which then calls the dialog or can I bake the Polymorph dialog into my spec window? -- View this message in context: http://forum.world.st/FileDialog-from-Spec-tp4860608p4860782.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 12, 2015

Re: [Pharo-users] Smalltalks video recordings?

by Esteban A. Maringolo

It is being recorded. And the slides being collected. So I guess they will be made public soon. El nov. 12, 2015 11:51 AM, "Stephan Eggermont" <stephan(a)stack.nl> escribiÃ³: > Looking at the tweet stream of #Smalltalks2015, I wonder if > #Smalltalks2015 is being recorded? Are there already slides available? > > Stephan > > >

Nov. 12, 2015

Smalltalks video recordings?

by Stephan Eggermont

Looking at the tweet stream of #Smalltalks2015, I wonder if #Smalltalks2015 is being recorded? Are there already slides available? Stephan

Nov. 12, 2015

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

by Tudor Girba

Hi, I changed the title of the message :). > On Nov 12, 2015, at 2:04 PM, Torsten Bergmann <astares(a)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. 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."

Nov. 12, 2015

Re: [Pharo-users] Changing playground and monticello shortcuts

by Thierry Goubier

Profiling a Spotter open ? Thierry 2015-11-12 14:25 GMT+01:00 Torsten Bergmann <astares(a)gmx.de>: > kilon 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 ? > > Tried on a slow mobile line now again as well without any problem. > I get the same impression that we talk about something else that slows > it down. > > As one can also see in the first minutes of my video: spotter opens right > away: > > https://www.youtube.com/watch?v=j-dTp6i_P3s > > This was also done on a machine with a slow connection. The catalog > stuff just appears "deferred" when the info was retrieved but > the spotter tool opens right away and classes and others could be used > as usual. > > Still it would not make sense to retrieve it anytime you open > spotter - thats why I think a cache would be suitable so we > do it just one time per image session. > > Thanks > T. > >

Nov. 12, 2015

Re: [Pharo-users] Changing playground and monticello shortcuts

by Stephan Eggermont

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

Nov. 12, 2015

Changing playground and monticello shortcuts

by Torsten Bergmann

kilon 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 ? Tried on a slow mobile line now again as well without any problem. I get the same impression that we talk about something else that slows it down. As one can also see in the first minutes of my video: spotter opens right away: https://www.youtube.com/watch?v=j-dTp6i_P3s This was also done on a machine with a slow connection. The catalog stuff just appears "deferred" when the info was retrieved but the spotter tool opens right away and classes and others could be used as usual. Still it would not make sense to retrieve it anytime you open spotter - thats why I think a cache would be suitable so we do it just one time per image session. Thanks T.

Nov. 12, 2015