November 2015 - Pharo-users

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

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

by Dimitris Chloupis

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

Nov. 12, 2015

Changing playground and monticello shortcuts

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

Nov. 12, 2015

Re: [Pharo-users] FileDialog from Spec

by Nicolai Hess

2015-11-12 7:23 GMT+01:00 Jeff Gray <jeff(a)rogerthedog.com>: > In Pharo 4. > I'm writing a ui in spec and I want to be able to select and open a file on > a button click. > I can see one example in polymorph but I don't know if that can be used > from > spec. > Or am I missing something obvious? > We don't have a spec based FileDialog (or FileChooserModel) yet. Do you want to integrate the FileChooserUI in your spec based UI, or just open a FileChooserDialog? If you just want to open a dialog, I would say, take the polymorph one. If you want to have the FileChooser as a part of your UI, you 'll have to create a new spec model for it. nicolai > > > > > -- > View this message in context: > http://forum.world.st/FileDialog-from-Spec-tp4860608.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Nov. 12, 2015

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

by Tudor Girba

Hi Torsten, People are saying that they do not want to have the Catalog Projects displayed by default (before you type anything). This makes the opening of Spotter slower. 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? Cheers, Doru > On Nov 12, 2015, at 1:30 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > >>> Also the extension for CatalogBrowser does an HTTP request every time one opens spotter. I am for changing this, or >>> at least for not displaying the CatalogBrowser by default until one starts searching. >> >> Woaaaaâ¦. That is why opening Spotter on the other side of the World is so slowâ¦ >> Yes please, remove this. Really. It does not bring much. > > On the other side of the world (where network is faster) one can just open spotter, enter > a name or name fragment of a project/framework like "Roassal" hit enter and load it without > much hazzle. > > I now added an option/setting so you can disable the spotter integration if required. See attachement. > > Will be in with the next iteration of catalog browser. > > Thanks > T.<screen.png> -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them."

Nov. 12, 2015

FileDialog from Spec

by Jeff Gray

In Pharo 4. I'm writing a ui in spec and I want to be able to select and open a file on a button click. I can see one example in polymorph but I don't know if that can be used from spec. Or am I missing something obvious? -- View this message in context: http://forum.world.st/FileDialog-from-Spec-tp4860608.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 12, 2015

Changing playground and monticello shortcuts

by Torsten Bergmann

>> Also the extension for CatalogBrowser does an HTTP request every time one opens spotter. I am for changing this, or >> at least for not displaying the CatalogBrowser by default until one starts searching. > >Woaaaaâ¦. That is why opening Spotter on the other side of the World is so slowâ¦ >Yes please, remove this. Really. It does not bring much. On the other side of the world (where network is faster) one can just open spotter, enter a name or name fragment of a project/framework like "Roassal" hit enter and load it without much hazzle. I now added an option/setting so you can disable the spotter integration if required. See attachement. Will be in with the next iteration of catalog browser. Thanks T.

Nov. 12, 2015

Fwd: Putting a RTBitmap image in the center of a RTPieChart and composite forms.

by Offray Vladimir Luna CÃ¡rdenas

Sorry. Send from the wrong address. Here comes again. Cheers, Offray -------- Forwarded Message -------- Subject: Putting a RTBitmap image in the center of a RTPieChart and composite forms. Date: Wed, 11 Nov 2015 18:18:57 -0500 From: Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Hi, I'm just improving some demos for the Smalltalks2015 Argentina that I will be giving tomorrow so if anyone has some kind of quick answer I will be really useful. By the way the event has been really energizing, the are a lot of nice and good people here and the city is beautiful. Hopefully it will become some kind of yearly peregrination for me. So on the last minute improvements front, I have two questions: 1. I'm trying to put a RTBitmap image in the center of an RTPieChart... but I'm having problems to find size or center methods on it or its parent classes. 2. I would like to make a composite graph, but seems that I'm missing something with the associated subcomponents. Consider this: g works fine, but If I try to put it on a composite one I get this: So just axis without any data. So I'm using the wrong abstractions to embed a graph inside another or I need somehow to put the data explicitly on the composed graph. Any help will be welcomed, as always. Cheers, Offray

Nov. 11, 2015