- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] editing the default window size of glamour inspector

by Ben Coman

Tudor Girba wrote: > Hi, > > Sorry for not replying earlier. Thanks Nicolai for picking this one up. > I missed the initial mail. > > The initialExtent does not make sense for presentation, and anyway, you > would not want to change an inspector when you are inside a flow. If I > understand correctly, Clement would want that when he spawns an > inspector window on a new object, to set the window size to something else. > > The idea of having a gtInitialWindowExtent is intriguing, but it won't > really work. The problem is that an object can have associated > presentations in several external packages, so defining the initial > extent in one of them might not work for the other ones. > > But, I was more thinking of a different mechanism that remembers the > size of the inspector every time you change it, and have the next window > take that size into account. > I am even considering having this size cached by the class of the > object (not sure yet if that makes sense). As I was reading, I was thinking to myself that remembering last size per class would make a lot of sense. Could there be a button in Preferences to save initialExtents to file, so these carry over to new images? cheers -ben

Nov. 24, 2014

changing MC repository url display

by Esteban Lorenzano

Hi, So I have this problemâ¦ each time I open a MC browser I see something like this: And as you can seeâ¦ most important part of the repositories (the NAME) is hidded because window is small. Of course, I can enlarge the screen to see the names, but that made me think the way the information is presented is not good (because the place, sthub, ss, ss3 or whatever) is less important than the repository name. So I would like to change that to something like: Pharo/Pharo40 (smalltalkhub.com <http://smalltalkhub.com/>) Pharo/Pharo40Inbox (smalltalkhub.com <http://smalltalkhub.com/>) Moose/Glamour (smalltalkhub.com <http://smalltalkhub.com/>) ./mc (filetree) VMMaker (source.squeak.org <http://source.squeak.org/>) â¦ etcâ¦ since this is a small change that has a huge visual impact, I would like to discuss it before. So, what do you think? Esteban

Nov. 24, 2014

Re: [Pharo-dev] editing the default window size of glamour inspector

by Tudor Girba

Hi, Sorry for not replying earlier. Thanks Nicolai for picking this one up. I missed the initial mail. The initialExtent does not make sense for presentation, and anyway, you would not want to change an inspector when you are inside a flow. If I understand correctly, Clement would want that when he spawns an inspector window on a new object, to set the window size to something else. The idea of having a gtInitialWindowExtent is intriguing, but it won't really work. The problem is that an object can have associated presentations in several external packages, so defining the initial extent in one of them might not work for the other ones. But, I was more thinking of a different mechanism that remembers the size of the inspector every time you change it, and have the next window take that size into account. I am even considering having this size cached by the class of the object (not sure yet if that makes sense). What do you think? Cheers, Doru On Mon, Nov 24, 2014 at 12:57 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-11-12 15:14 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > >> Hello, >> >> I would like for specific objects to change the default window size of >> the glamour inspector (Basically a bigger window will be opened by default >> for these objects). This is because I extended my inspectors to provide >> roassal visualization that are quite large. >> >> How can I do it ? >> >> For example I would like something like that: >> >> MyObject>>#gtInitialWindowExtent >> < gtInitialWindowExtent > >> ^ 800@1000 >> >> Clement >> >> > > I think this is not doable. > You can change the method with the inspector pragma to be called with the > context (inspector instance) > > gtInspectorItemsIn: composite inContext: aGTInspector > <gtInspectorPresentationOrder: 30> > > instead of > > gtInspectorItemsIn: composite > <gtInspectorPresentationOrder: 30> > > this way you have access to the glamour inspector. Unfortunately it does > not have any > window extent property. > > Maybe we can move the initialExtent property from GLMBrowser up to > GLMPresentation? > That way it would be accessible and usable for this aGTInspector argument. > > > > Nicolai > > > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 24, 2014

Re: [Pharo-dev] editing the default window size of glamour inspector

by Nicolai Hess

2014-11-12 15:14 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Hello, > > I would like for specific objects to change the default window size of the > glamour inspector (Basically a bigger window will be opened by default for > these objects). This is because I extended my inspectors to provide roassal > visualization that are quite large. > > How can I do it ? > > For example I would like something like that: > > MyObject>>#gtInitialWindowExtent > < gtInitialWindowExtent > > ^ 800@1000 > > Clement > > I think this is not doable. You can change the method with the inspector pragma to be called with the context (inspector instance) gtInspectorItemsIn: composite inContext: aGTInspector <gtInspectorPresentationOrder: 30> instead of gtInspectorItemsIn: composite <gtInspectorPresentationOrder: 30> this way you have access to the glamour inspector. Unfortunately it does not have any window extent property. Maybe we can move the initialExtent property from GLMBrowser up to GLMPresentation? That way it would be accessible and usable for this aGTInspector argument. Nicolai

Nov. 24, 2014

[pharo-project/pharo-core]

by GitHub

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

Nov. 24, 2014

[pharo-project/pharo-core] 04945b: 40383

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 04945b033abdc10ba786b45ac9b9b2bc820cb989 https://github.com/pharo-project/pharo-core/commit/04945b033abdc10ba786b45a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-11-24 (Mon, 24 Nov 2014) Changed paths: A Collections-Sequenceable.package/OrderedCollection.class/instance/converting/asOrderedCollection.st A CollectionsTests.package/ArrayTest.class/instance/tests - converting/testAsArrayKeepsIdentity.st A CollectionsTests.package/OrderedCollectionTest.class/instance/tests - converting/testAsOrderedCollectionKeepsIdentity.st A CollectionsTests.package/OrderedCollectionTest.class/instance/tests - converting/testAsOrderedCollectionReturnsOrderedCollection.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script383.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40383.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40383 14498 Unnecessary instance creation in OrderedCollection>>#asOrderedCollection? https://pharo.fogbugz.com/f/cases/14498 http://files.pharo.org/image/40/40383.zip

Nov. 24, 2014

Re: [Pharo-dev] Listening for shift key pressed

by Aliaksei Syrel

Hi Ben, Thanks :) Here I opened issue <https://pharo.fogbugz.com/f/cases/14521/Pressing-shift-ctrl-command-options…> I didn't do it before, because Stef wrote, that it's somehow known bug and they will try to move to OSWindow in the future. Cheers, Alex On Sun, Nov 23, 2014 at 4:32 PM, Ben Coman <btc(a)openinworld.com> wrote: > Aliaksei Syrel wrote: > >> Hi, Nicolai >> >> Thanks for suggestion. I'm using Mac 10.10 and it doesn't show any >> notifications for shift.. >> I'll open an issue for this. >> >> Cheers, >> Alex >> > > > Hi Alex, > > Did you open an issue? I can't find it. I've made some progress getting > it working and would like to document this for review. > > cheers -ben > > > >> On Fri, Nov 21, 2014 at 10:20 PM, Nicolai Hess <nicolaihess(a)web.de >> <mailto:nicolaihess@web.de>> wrote: >> >> If you look at KeyPrinterMorph you'll see that it indeed handles a >> single shift key down. >> >> 2014-11-21 17:36 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com >> <mailto:alex.syrel@gmail.com>>: >> >> Hi Ben, >> >> If at the end of InputEventFetcher>>__waitForInput >> you put "Transcript crShow: Time now" >> and I think you'll be looking at as raw an event aas you can >> get. >> >> >> Now this exhibits some strange behaviour? Pushing <shift> >> on its own does not produce an event, however pushing >> <shift> fast multiple times does generate events. ??? >> >> It's maybe because you move mouse, or randomly touch touchpad. >> >> After some investigations and digging lower and lower till >> primitive methods, I realized that VM itself doesn't queue an >> event after user presses Shift. It's just a modifier bit, that >> is applied on a real events, such as mouse moves or normal >> keyboard events. >> >> Cheers, >> Alex >> >> >> >> > >

Nov. 24, 2014

Re: [Pharo-dev] contributing to Pharo testing effort

by Hilaire

Hi Sheridan, The MultiByteFileStream is broken when dealing with non-ascii character (see my recent post "Something strange with fileOut) and there are only 3 tests for this class. Test stressing this class will be pretty useful to properly refactor it without breaking other parts. Hilaire Le 23/11/2014 19:45, sheridan(a)sheridan-mahoney.com a Ã©crit : > Hi there, > I am interested in helping out with writing tests in Pharo, and was > wondering where would be a good place to start. I am familiar with > Smalltalk from working at GemStone Systems in their QA department some > years ago, but am somewhat new to Pharo. Any advice would be very > appreciated. > > Best regards, > Sheridan Mahoney > > -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Nov. 24, 2014

Something strange with fileOut

by Hilaire

Hi, We write code and comment in English, so only ascii characters are used. For string we also use English, and when translation is needed we use catalog of messages as gettext, where the non ascii strings are externally represented. So most of the time we only use ascii characters in our code. However, if a developer writes non ascii character in a method, fileout may just break. The problem is described and related to MultiByteFileStream: https://pharo.fogbugz.com/f/cases/14462 I check with Squeak4.5, although I cannot enter non-ascii character (but that's another problem, probably related to the VM I am using not suited to Squeak) I have no error when fileout the same class with non-ascii character in method body. The MultiByteFileStream seems quite different, I don't know the history of changes in these two method versions but changed in Squeak version seems a bit newer. The changes may not be trivial because it involves the whole class hierarchy. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Nov. 24, 2014

Re: [Pharo-dev] [smalltalk-research] Re: Julia vs Pharo

by Nicolai Hess

2014-11-18 16:45 GMT+01:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > Were is the code located ? > One can be found here: http://mc.lukas-renggli.ch/built/oneclick/ It would be great to have this on a more recent pharo (3 or 4). > > Apparently the Helvetia one click image is no more available on this page: > http://scg.unibe.ch/research/helvetia > > On Tue, Nov 18, 2014 at 4:38 PM, Serge Stinckwich > <serge.stinckwich(a)gmail.com> wrote: > > On Mon, Nov 17, 2014 at 8:13 PM, Lukas Renggli <renggli(a)gmail.com> > wrote: > >> > >> On Mon, Nov 17, 2014 at 5:05 PM, Serge Stinckwich > >> <serge.stinckwich(a)gmail.com> wrote: > >>> > >>> On Mon, Nov 17, 2014 at 5:01 PM, werner kassens <wernerk740(a)gmail.com> > >>> wrote: > >>> >>I never heard about this one. > >>> > > >>> > no wonder<g>, i got the name wrong, it was helvetia > >>> > >>> Ok, this is about domain-specific languages not multiple dispatch. > >> > >> > >> It actually included an example of multiple dispatch :-) > > > > Hi Lukas, > > > > I was not aware of that ;-) > > I will have a look. > > > > Thanks, > > -- > > Serge Stinckwich > > UCBN & UMI UMMISCO 209 (IRD/UPMC) > > Help fight Ebola by joining the Computing for Ebola Challenge > > http://bit.ly/1oEdBag > > > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Help fight Ebola by joining the Computing for Ebola Challenge > http://bit.ly/1oEdBag > >

Nov. 24, 2014