December 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GTInspector and huge arrays issue

by Aliaksei Syrel

Hi, Why the class you use is not available in Moose 5.0 ? There were some failing tests, so maybe new classes were not in the build (The latest is Glamour-Morphic-Brick.88) Brick more or less is nothing special. The main idea was to kill morphic layouting mechanism and reimplement it from scratch. Also drawing logic was changed, such that there is no way to draw outside of the parent Brick and to support z-index. But one of the most important feature for us was to have a normal support of paddings and margins (like in css). And all bounds are relative to the parent. Cheers, Alex On Wed, Dec 10, 2014 at 10:31 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > I am very interested into Brick, because I am very interesting into > anything GUI and graphic wise and I want to push pharo forward in that > field with my own efforts as best I can. > > The scrolling of your examples is actually very smooth. > > Why the class you use is not available in Moose 5.0 ? Because a moose 5.0 > image I have downloaded recently with pharolauncher that it contains > GTSpotter yet it does not have the class you use here. > > On Wed, Dec 10, 2014 at 9:31 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> > wrote: > >> Hi, >> >> in case someone is still interested, a Glamour-Morphic-Brick (extension >> of morph, that was used to build a Spotter) >> supports a very large lists. You can try in the latest version: >> >> GLMScrollListBrick exampleCollection - to open a list of all classes in >> the image (each element in the list is a morph). >> GLMScrollListBrick example - list of 2000 elements >> GLMScrollListBrick exampleInfinity - list of Float infinity number of >> elements. >> >> if your pharo image is old: >> >>> Gofer new >>> smalltalkhubUser: 'Moose' project: 'Glamour'; >>> package: 'Glamour-Morphic-Brick'; load. >> >> >> Maybe we will use it instead of default lists in Inspector. >> >> Cheers, >> Alex >> >> >> On Thu, Dec 4, 2014 at 4:04 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> Sven Van Caekenberghe wrote: >>> >>>> On 04 Dec 2014, at 11:45, phil(a)highoctane.be wrote: >>>>> >>>>> But further than that I want to edit values in inspectors. >>>>> >>>> >>>> Yes ! >>>> >>>> And auto refresh ! >>>> >>>> Both of these could be depending on presentation, so that heavy >>>> presentations can opt out. >>>> >>>> >>>> >>>> >>>> >>> It would be good if there was some visual indication of which >>> presentations auto-refreshed - like a drop pin looking like its "stuck-in" >>> when not-auto-refreshing. A user might even be able to change the state of >>> the pin, with the just the default dependent on type of presentation. >>> cheers -ben >>> >>> >> >

Dec. 10, 2014

Re: [Pharo-dev] About launching tools with Spotter

by Tudor Girba

Hi, First, I am happy already that different people see GTSpotter as suitable for different things: some want to search for tools more, some want to search for code, and I am hoping others want to search for something else. This is great because it shows that GTSpotter can be quite versatile. We should find a reasonable default. I think we probably should favor the tools on top just because there are very few of them. However, you should also consider looking inside the code a bit. This tool is meant to be moldable quickly to your preference. All search extensions are found in the GT-SpotterExtensions-Core. This package contains now some 40 methods totaling only 287 lines of code. For example, the definition of the top classes search is found in: GTSpotter>>spotterForClassesFor: aStep <spotterOrder: 10> aStep listProcessor allCandidates: [ Smalltalk allClasses ]; title: 'Classes'; matchSubstring; itemIcon: #systemIcon; wantsToDisplayOnEmptyQuery: false The pragma number defines the position in the list (the lower it is, the more on top it is). So, if you want to have a different order, a simple solution would be delete the GT-SpotterExtensions-Core package and replace it with your own package in your image. Cheers, Doru On Wed, Dec 10, 2014 at 10:43 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > Why it has to be always about black and white ? > > Just put GTSpotter to the Pharo settings and let the user choose what is > best for him. > > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 10, 2014

Re: [Pharo-dev] About launching tools with Spotter

by kilon alios

Why it has to be always about black and white ? Just put GTSpotter to the Pharo settings and let the user choose what is best for him.

Dec. 10, 2014

Re: [Pharo-dev] About launching tools with Spotter

by Guillermo Polito

but* they are hidden. Actually, the case for tools not in the main menu but in a sub menu (komitter, versionner, file browser, etc), they are not listed by default :) On Wed, Dec 10, 2014 at 10:32 PM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > I'm with Esteban. > > Type "Work" or "Test" looking for the Workspace or the Test Runner. They > are far too down... > > Try typing "process" looking Process browser, or "Configuration" for the > configuration browser. > > Those are things that should be accessible, by they are hidden because > their names collide with a lot of classes and packages... > > On Wed, Dec 10, 2014 at 8:28 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > wrote: > >> I think this should be configurable :) >> >> >> > On 10 Dec 2014, at 19:13, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> > >> > well, I vote the contrary: I want âappsâ to show first :P >> > remember that is not just browsers what we openâ¦. >> > >> > Esteban >> > >> >> On 10 Dec 2014, at 19:01, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >> >> >>> On 10 Dec 2014, at 17:52, Damien Cassou <damien.cassou(a)gmail.com> >> wrote: >> >>> >> >>> On Wed, Dec 10, 2014 at 5:09 PM, Tudor Girba <tudor(a)tudorgirba.com> >> wrote: >> >>>> But, indeed, it seems that people prefer to have the applications on >> top and >> >>>> the rest of the things below. So, a quick fix for this problem is to >> make >> >>>> the Menu category come before the classes. >> >>> >> >>> >> >>> but if you open a System Browser, the next step is to search for >> >>> something in the System Browser. Why would you do that if you can use >> >>> Spotter to directly search for the thing you want? >> >>> >> >>> Same thing for Monticello: spotter makes it apparently easy to commit >> >>> directly from spotter. So, the main activity is to search for a >> >>> package in spotter, not for Monticello. >> >>> >> >>> So, it looks like packages, classes and methods should come before >> >>> applications :-) >> >> >> >> Yes! +1 >> >> >> >>> -- >> >>> Damien Cassou >> >>> http://damiencassou.seasidehosting.st >> >>> >> >>> "Success is the ability to go from one failure to another without >> >>> losing enthusiasm." >> >>> Winston Churchill >> >>> >> >> >> >> >> > >> > >> >> >> >

Dec. 10, 2014

Re: [Pharo-dev] About launching tools with Spotter

by Guillermo Polito

I'm with Esteban. Type "Work" or "Test" looking for the Workspace or the Test Runner. They are far too down... Try typing "process" looking Process browser, or "Configuration" for the configuration browser. Those are things that should be accessible, by they are hidden because their names collide with a lot of classes and packages... On Wed, Dec 10, 2014 at 8:28 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > I think this should be configurable :) > > > > On 10 Dec 2014, at 19:13, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > well, I vote the contrary: I want âappsâ to show first :P > > remember that is not just browsers what we openâ¦. > > > > Esteban > > > >> On 10 Dec 2014, at 19:01, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> > >>> On 10 Dec 2014, at 17:52, Damien Cassou <damien.cassou(a)gmail.com> > wrote: > >>> > >>> On Wed, Dec 10, 2014 at 5:09 PM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >>>> But, indeed, it seems that people prefer to have the applications on > top and > >>>> the rest of the things below. So, a quick fix for this problem is to > make > >>>> the Menu category come before the classes. > >>> > >>> > >>> but if you open a System Browser, the next step is to search for > >>> something in the System Browser. Why would you do that if you can use > >>> Spotter to directly search for the thing you want? > >>> > >>> Same thing for Monticello: spotter makes it apparently easy to commit > >>> directly from spotter. So, the main activity is to search for a > >>> package in spotter, not for Monticello. > >>> > >>> So, it looks like packages, classes and methods should come before > >>> applications :-) > >> > >> Yes! +1 > >> > >>> -- > >>> Damien Cassou > >>> http://damiencassou.seasidehosting.st > >>> > >>> "Success is the ability to go from one failure to another without > >>> losing enthusiasm." > >>> Winston Churchill > >>> > >> > >> > > > > > > >

Dec. 10, 2014

Re: [Pharo-dev] GTInspector and huge arrays issue

by kilon alios

I am very interested into Brick, because I am very interesting into anything GUI and graphic wise and I want to push pharo forward in that field with my own efforts as best I can. The scrolling of your examples is actually very smooth. Why the class you use is not available in Moose 5.0 ? Because a moose 5.0 image I have downloaded recently with pharolauncher that it contains GTSpotter yet it does not have the class you use here. On Wed, Dec 10, 2014 at 9:31 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi, > > in case someone is still interested, a Glamour-Morphic-Brick (extension of > morph, that was used to build a Spotter) > supports a very large lists. You can try in the latest version: > > GLMScrollListBrick exampleCollection - to open a list of all classes in > the image (each element in the list is a morph). > GLMScrollListBrick example - list of 2000 elements > GLMScrollListBrick exampleInfinity - list of Float infinity number of > elements. > > if your pharo image is old: > >> Gofer new >> smalltalkhubUser: 'Moose' project: 'Glamour'; >> package: 'Glamour-Morphic-Brick'; load. > > > Maybe we will use it instead of default lists in Inspector. > > Cheers, > Alex > > > On Thu, Dec 4, 2014 at 4:04 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> Sven Van Caekenberghe wrote: >> >>> On 04 Dec 2014, at 11:45, phil(a)highoctane.be wrote: >>>> >>>> But further than that I want to edit values in inspectors. >>>> >>> >>> Yes ! >>> >>> And auto refresh ! >>> >>> Both of these could be depending on presentation, so that heavy >>> presentations can opt out. >>> >>> >>> >>> >>> >> It would be good if there was some visual indication of which >> presentations auto-refreshed - like a drop pin looking like its "stuck-in" >> when not-auto-refreshing. A user might even be able to change the state of >> the pin, with the just the default dependent on type of presentation. >> cheers -ben >> >> >

Dec. 10, 2014

Ugly textrendering (vertical label)

by Nicolai Hess

Someone knows, why the text on the completion morph is so ugly? For example, this text Morph ne will open a completion window for "Morph class". This name is a vertical label on the left. The text looks ugly when we are using a FT font. Can we do anything to make this look better ? I know that (smooth) text rendering is difficult for arbitrary rotated forms, but this rotation around n*90 degree works with StrikeFont. nicolai

Dec. 10, 2014

Re: [Pharo-dev] GTInspector and huge arrays issue

by Aliaksei Syrel

Hi, in case someone is still interested, a Glamour-Morphic-Brick (extension of morph, that was used to build a Spotter) supports a very large lists. You can try in the latest version: GLMScrollListBrick exampleCollection - to open a list of all classes in the image (each element in the list is a morph). GLMScrollListBrick example - list of 2000 elements GLMScrollListBrick exampleInfinity - list of Float infinity number of elements. if your pharo image is old: > Gofer new > smalltalkhubUser: 'Moose' project: 'Glamour'; > package: 'Glamour-Morphic-Brick'; load. Maybe we will use it instead of default lists in Inspector. Cheers, Alex On Thu, Dec 4, 2014 at 4:04 PM, Ben Coman <btc(a)openinworld.com> wrote: > Sven Van Caekenberghe wrote: > >> On 04 Dec 2014, at 11:45, phil(a)highoctane.be wrote: >>> >>> But further than that I want to edit values in inspectors. >>> >> >> Yes ! >> >> And auto refresh ! >> >> Both of these could be depending on presentation, so that heavy >> presentations can opt out. >> >> >> >> >> > It would be good if there was some visual indication of which > presentations auto-refreshed - like a drop pin looking like its "stuck-in" > when not-auto-refreshing. A user might even be able to change the state of > the pin, with the just the default dependent on type of presentation. > cheers -ben > >

Dec. 10, 2014

Re: [Pharo-dev] About launching tools with Spotter

by Yuriy Tymchuk

I think this should be configurable :) > On 10 Dec 2014, at 19:13, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > well, I vote the contrary: I want âappsâ to show first :P > remember that is not just browsers what we openâ¦. > > Esteban > >> On 10 Dec 2014, at 19:01, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 10 Dec 2014, at 17:52, Damien Cassou <damien.cassou(a)gmail.com> wrote: >>> >>> On Wed, Dec 10, 2014 at 5:09 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> But, indeed, it seems that people prefer to have the applications on top and >>>> the rest of the things below. So, a quick fix for this problem is to make >>>> the Menu category come before the classes. >>> >>> >>> but if you open a System Browser, the next step is to search for >>> something in the System Browser. Why would you do that if you can use >>> Spotter to directly search for the thing you want? >>> >>> Same thing for Monticello: spotter makes it apparently easy to commit >>> directly from spotter. So, the main activity is to search for a >>> package in spotter, not for Monticello. >>> >>> So, it looks like packages, classes and methods should come before >>> applications :-) >> >> Yes! +1 >> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Success is the ability to go from one failure to another without >>> losing enthusiasm." >>> Winston Churchill >>> >> >> > >

Dec. 10, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40410 Home: https://github.com/pharo-project/pharo-core

Dec. 10, 2014