June 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] ExternalIconFamily framework released

by Fernando Olivero

Hi, according to a suggestion by Stef, i cleaned up the framework i developed for importing/managing external icon families in Pharo. To load evaluate: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfExternalIconFamily'; load. (Smalltalk globals classNamed: 'ConfigurationOfExternalIconFamily') perform: #load. More info on the squeaksource page : http://www.squeaksource.com/ExternalIconFamily I'm using is successfully in Gaucho, importing the oxygen icon set. Pharo would be greatly enhanced, if it would have a consistent iconic look and feel, i could open a issue for starting on this task, for Pharo 1.4 ? Fernando

June 6, 2011

Re: [Pharo-project] Toward MVP: SimpleGridExample vs. ClassListExample, etc.

by Alain Plantec

Hi Bill, thanks for your feedbacks! Le 06/06/2011 01:11, Schwab,Wilhelm K a Ã©crit : > Maybe PluggableMultiColumnListMorph is where I should start for the short term?? yes. Cheers Alain > Bill >

June 6, 2011

Re: [Pharo-project] help to remove toolbuilder

by StÃ©phane Ducasse

Yes I did that for the moment :) Stef On Jun 5, 2011, at 11:32 PM, Schwab,Wilhelm K wrote: > Stef, > > It looks like it goes into the following loop: > > [aWidget world notNil] whileTrue: [ > aWidget outermostWorldMorph doOneCycle. > ]. > > where aWidget is the system window of interest. You might simply add this code (make a backup first<g>), see if that goes well. > > Does that help? > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Sunday, June 05, 2011 3:17 PM > To: Pharo-project open-source Smalltalk > Subject: [Pharo-project] help to remove toolbuilder > > Hi gary > > > I could nearly remove toolBuilder if I could know what to do with > [ToolBuilder default runModal: aSystemWindow openAsIs] in > > > openModal: aSystemWindow > "Open the given window locking the receiver until it is dismissed. > Answer the system window. > Restore the original keyboard focus when closed." > > |area mySysWin keyboardFocus| > keyboardFocus := self activeHand keyboardFocus. > mySysWin := self isSystemWindow ifTrue: [self] ifFalse: [self ownerThatIsA: SystemWindow]. > mySysWin ifNil: [mySysWin := self]. > mySysWin modalLockTo: aSystemWindow. > area := RealEstateAgent maximumUsableArea. > aSystemWindow extent: aSystemWindow initialExtent. > aSystemWindow position = (0@0) > ifTrue: [aSystemWindow > position: self activeHand position - (aSystemWindow extent // 2)]. > aSystemWindow > bounds: (aSystemWindow bounds translatedToBeWithin: area). > [ToolBuilder default runModal: aSystemWindow openAsIs] > ensure: [mySysWin modalUnlockFrom: aSystemWindow. > self activeHand newKeyboardFocus: keyboardFocus]. > ^aSystemWindow > > Stef >

June 6, 2011

Re: [Pharo-project] Toward MVP: SimpleGridExample vs. ClassListExample, etc.

by Schwab,Wilhelm K

Alain, Stef might be correct about it being better in 1.3. In fairness, the Hudson 1.3 image is not as big as my 1.1.1 working image, so the comparison might have some flaws. The class examples are paginated, deferring some work. There is a separate LazyClassListExample; it seems to work properly, and the only change that I see relative to ClassListExample is its use of LazyMorphTreeMorph. Making that same substitution for SimpleGridMorph produces weird side effects ("extra morphs" created on some rows) in 1.3. In 1.1.1, the window opens quickly, but is ultimately sluggish until all morphs are created. The latter is not terribly surprising, but one could hope for 1.3's speed with 1.1.1's stability :) Getting back to my MVP focus, I note that MorphTreeMorph is both slower than Dolphin's enhanced (multi-column) lists, and also more powerful. It has a lot in common with the lists in the PaneHolders package that I created for Dolphin (with some additions and omissions). As non-oo as it might be, there is arguably room for a text-only grid that is very fast. Whether Object Arts put it in Dolphin "because it was there" in Windows, because they knew it would a good compromise, or somewhere in between is open for discussion. Regardless, it is a useful widget. Maybe PluggableMultiColumnListMorph is where I should start for the short term?? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Alain Plantec [alain.plantec(a)yahoo.com] Sent: Saturday, June 04, 2011 12:46 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Toward MVP: SimpleGridExample vs. ClassListExample, etc. yes, it is slow. the idea would be to build the list in background. you can try the lazy version also. LazyMorphTreeMorph. a row is built only when it is visible. Cheers Alain Le 04/06/2011 18:08, Schwab,Wilhelm K a Ã©crit : > I have a couple of GUIs to create, and took another look at my (very) slowly evolving MVP package. A small update appears below, but the question of the day is one of performance of MorphTreeMorph in its various incarnations. > > ClassListExample is very impressive and reasonably quick. SimpleGridExample is very nice, but quite slow. Profiling its opening reveals that it spends a lot of time making morphs, but that's not super surprising. It's the total time that is of concern. Any takers on why? > > I ask, because I am trying to create basic presenter classes for lists, trees, (more or less working), text (will be easy - I *think*), and another big item is multi-column lists. My objective is to be able to easily construct things that (unless told to do otherwise) automatically deal with the selected index, updates, etc. None of this stuff is terribly difficult to do when following the Polymorph examples, PharoCasts, etc., but hopefully we can have MVP and stop repeating ourselves at the same time. > > The next thing I am missing is a grid. Any strong thoughts on examples to follow/reuse, or things that should NOT be used for any reason? > > Bill > > > > >

June 5, 2011

Re: [Pharo-project] help to remove toolbuilder

by Schwab,Wilhelm K

Stef, It looks like it goes into the following loop: [aWidget world notNil] whileTrue: [ aWidget outermostWorldMorph doOneCycle. ]. where aWidget is the system window of interest. You might simply add this code (make a backup first<g>), see if that goes well. Does that help? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Sunday, June 05, 2011 3:17 PM To: Pharo-project open-source Smalltalk Subject: [Pharo-project] help to remove toolbuilder Hi gary I could nearly remove toolBuilder if I could know what to do with [ToolBuilder default runModal: aSystemWindow openAsIs] in openModal: aSystemWindow "Open the given window locking the receiver until it is dismissed. Answer the system window. Restore the original keyboard focus when closed." |area mySysWin keyboardFocus| keyboardFocus := self activeHand keyboardFocus. mySysWin := self isSystemWindow ifTrue: [self] ifFalse: [self ownerThatIsA: SystemWindow]. mySysWin ifNil: [mySysWin := self]. mySysWin modalLockTo: aSystemWindow. area := RealEstateAgent maximumUsableArea. aSystemWindow extent: aSystemWindow initialExtent. aSystemWindow position = (0@0) ifTrue: [aSystemWindow position: self activeHand position - (aSystemWindow extent // 2)]. aSystemWindow bounds: (aSystemWindow bounds translatedToBeWithin: area). [ToolBuilder default runModal: aSystemWindow openAsIs] ensure: [mySysWin modalUnlockFrom: aSystemWindow. self activeHand newKeyboardFocus: keyboardFocus]. ^aSystemWindow Stef

June 5, 2011

Re: [Pharo-project] [update 1.3] #13248 (pay attention will break the server because of pop ups).

by StÃ©phane Ducasse

apparently it will work (my previous image was dirty). Stef On Jun 5, 2011, at 10:31 PM, StÃ©phane Ducasse wrote: > > 13248 > ----- > > - another step towards removing toolbuilder. MorphicUIManager is now not in ToolBuilder anymore but Polymorph close to UITheme (to be validated later) and PluggableMenuSpec close to MenuMorph. > > Marcus it will break the build server but I redid all the integration two times and I do not understand why some packages where dirty in 13247 so > sorry but I lost already more than one hour on this one. > > Stef :(

June 5, 2011

[Pharo-project] [update 1.3] #13248 (pay attention will break the server because of pop ups).

by StÃ©phane Ducasse

13248 ----- - another step towards removing toolbuilder. MorphicUIManager is now not in ToolBuilder anymore but Polymorph close to UITheme (to be validated later) and PluggableMenuSpec close to MenuMorph. Marcus it will break the build server but I redid all the integration two times and I do not understand why some packages where dirty in 13247 so sorry but I lost already more than one hour on this one. Stef :(

June 5, 2011

Re: [Pharo-project] testing ui errors in headless mode

by StÃ©phane Ducasse

this is probably related also with the problem that hilaire got with DrGeo. I did some experiences and we will check that with igor. Probably the command line is executed at startup but before the UI thread is launched. So we should fix that for 1.3 Stef On Jun 5, 2011, at 10:09 PM, Lukas Renggli wrote: > Not sure --- I didn't read the whole thread and I am not sure if I > understand the problem --- but did you try: > > WorldState addDeferredUIMessage: [ 1 inspect ] > > AFAIK, code filed-in at startup does not run in the GUI process > causing problems when the code expects to run in the GUI process > and/or a GUI process to be present (it might not be resumed on startup > yet). > > Lukas > > > On 5 June 2011 21:07, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> I would need a bit of help with this one :). >> >> I tried: >> >> testStartup >> self shouldnt: [[1 inspect] on: ErrorNonInteractive do: [:x | ]] raise: Error >> >> This still fails. Is there a way around it? >> >> You can try using the attached st file. >> >> Cheers, >> Doru >> >> >> >> Begin forwarded message: >> >>> From: Tudor Girba <tudor(a)tudorgirba.com> >>> Date: 31 May 2011 23:08:03 CEST >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] testing ui errors in headless mode >>> >>> Hi, >>> >>> On 31 May 2011, at 22:32, Igor Stasenko wrote: >>> >>>> On 31 May 2011 23:15, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>> Hi Igor, >>>>> >>>>> Sorry for the late reply. >>>>> >>>>> >>>>> >>>>> On 26 May 2011, at 17:48, Igor Stasenko wrote: >>>>> >>>>>> On 26 May 2011 17:03, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I tried several ways to get my head around this problem, but I do not know how to proceed. Can anyone help? >>>>>>> >>>>>>> Cheers, >>>>>>> Doru >>>>>>> >>>>>>> >>>>>>> On 25 May 2011, at 21:21, Tudor Girba wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> We have some smoke tests in Moose that basically spawn a UI and check for Error. >>>>>>>> >>>>>>>> This used to work when running headless in Pharo 1.2 but now they fail in Pharo 1.3. I believe this has to do with the new changes in the UI Manager, but I do not know what to do. >>>>>>>> >>>>>>>> To reproduce the problem, you can simply call a Pharo-1.3.image in headless mode and file in the attached st file that: >>>>>>>> >>>>>>>> - installs a simple test: >>>>>>>> HeadlessTest>>testStartup >>>>>>>> self shouldnt: [1 inspect] raise: Error >>>>>> >>>>>> Tudor, your test is wrong. >>>>>> During image startup and in headless mode calling inspector will and >>>>>> should raise an error. >>>>>> Because inspecting object requires a presence of UI. >>>>>> But there's no UI in headless mode and prohibited from use during >>>>>> image startup phase, because >>>>>> you cannot start asking questions from user before properly >>>>>> initializing everything related to startup. >>>>>> Startup is called startup on purpose: is should not be interrupted nor >>>>>> require user's interaction. >>>>>> >>>>>> Assume that you don't have Morphic loaded in your image, then what you >>>>>> expect to happen if you do >>>>>> 1 inspect >>>>>> ? >>>>> >>>>> I understand now that the test is wrong. I just wanted to offer an example of spawning a ui, but I think I found the problem like this :). >>>>> >>>>> Now, the thing is that my test tests that triggering the entries from a menu does not result in an error. And inspect or browse happen to be among the menu entries. Is there a way to still have this test working on the server? >>>>> >>>>> Should I put a guard condition in the method triggering the inspector? That sounds bad. Any other ideas? >>>>> >>>> >>>> Yes, you could swallow all ErrorNonInteractive. >>>> So if you will know that something will lead to UI interaction, you >>>> can catch ErrorNonInteractive. >>>> Since there is no UI you won't proceed further, but still will know >>>> that during running the test some UI is involved. >>>> >>>> So, actually a following should pass: >>>> >>>> UIManager default isInteractive ifFalse: [ >>>> self should: [1 inspect] raise: ErrorNonInteractive >>>> ] >>>> >>>> The problem is that there is some missing protocol in >>>> NonInteractiveUIManager (because at the time i was adding it , i >>>> covered all methods, >>>> but then some more stuff were added to morphic ui manager without >>>> parallel extension to other ui managers, >>>> so the test above can fail because you will get DNU error instead of >>>> ErrorNonInteractive ) >>> >>> I tried it: >>> >>> testStartup >>> self shouldnt: [[1 inspect] on: ErrorNonInteractive do: [:x | ]] raise: Error >>> >>> But this still fails. You can try using the attached st file. >>> >>> Cheers, >>> Doru >>> >> >>> >>>>> Cheers, >>>>> Doru >>>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "The coherence of a trip is given by the clearness of the goal." >>> >>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "What is more important: To be happy, or to make happy?" >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch >

June 5, 2011

Re: [Pharo-project] testing ui errors in headless mode

by Lukas Renggli

Not sure --- I didn't read the whole thread and I am not sure if I understand the problem --- but did you try: WorldState addDeferredUIMessage: [ 1 inspect ] AFAIK, code filed-in at startup does not run in the GUI process causing problems when the code expects to run in the GUI process and/or a GUI process to be present (it might not be resumed on startup yet). Lukas On 5 June 2011 21:07, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I would need a bit of help with this one :). > > I tried: > > testStartup > Â Â Â Â self shouldnt: Â [[1 inspect] on: ErrorNonInteractive do: [:x | ]] raise: Â Error > > This still fails. Is there a way around it? > > You can try using the attached st file. > > Cheers, > Doru > > > > Begin forwarded message: > >> From: Tudor Girba <tudor(a)tudorgirba.com> >> Date: 31 May 2011 23:08:03 CEST >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] testing ui errors in headless mode >> >> Hi, >> >> On 31 May 2011, at 22:32, Igor Stasenko wrote: >> >>> On 31 May 2011 23:15, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> Hi Igor, >>>> >>>> Sorry for the late reply. >>>> >>>> >>>> >>>> On 26 May 2011, at 17:48, Igor Stasenko wrote: >>>> >>>>> On 26 May 2011 17:03, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>>> Hi, >>>>>> >>>>>> I tried several ways to get my head around this problem, but I do not know how to proceed. Can anyone help? >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> On 25 May 2011, at 21:21, Tudor Girba wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> We have some smoke tests in Moose that basically spawn a UI and check for Error. >>>>>>> >>>>>>> This used to work when running headless in Pharo 1.2 but now they fail in Pharo 1.3. I believe this has to do with the new changes in the UI Manager, but I do not know what to do. >>>>>>> >>>>>>> To reproduce the problem, you can simply call a Pharo-1.3.image in headless mode and file in the attached st file that: >>>>>>> >>>>>>> - installs a simple test: >>>>>>> HeadlessTest>>testStartup >>>>>>> Â Â Â self shouldnt: Â [1 inspect] raise: Â Error >>>>> >>>>> Tudor, your test is wrong. >>>>> During image startup and in headless mode calling inspector will and >>>>> should raise an error. >>>>> Because inspecting object requires a presence of UI. >>>>> But there's no UI in headless mode and prohibited from use during >>>>> image startup phase, because >>>>> you cannot start asking questions from user before properly >>>>> initializing everything related to startup. >>>>> Startup is called startup on purpose: is should not be interrupted nor >>>>> require user's interaction. >>>>> >>>>> Assume that you don't have Morphic loaded in your image, then what you >>>>> expect to happen if you do >>>>> 1 inspect >>>>> ? >>>> >>>> I understand now that the test is wrong. I just wanted to offer an example of spawning a ui, but I think I found the problem like this :). >>>> >>>> Now, the thing is that my test tests that triggering the entries from a menu does not result in an error. And inspect or browse happen to be among the menu entries. Is there a way to still have this test working on the server? >>>> >>>> Should I put a guard condition in the method triggering the inspector? That sounds bad. Any other ideas? >>>> >>> >>> Yes, you could swallow all ErrorNonInteractive. >>> So if you will know that something will lead to UI interaction, you >>> can catch ErrorNonInteractive. >>> Since there is no UI you won't proceed further, but still will know >>> that during running the test some UI is involved. >>> >>> So, actually a following should pass: >>> >>> UIManager default isInteractive ifFalse: [ >>> self should: Â [1 inspect] raise: Â ErrorNonInteractive >>> ] >>> >>> The problem is that there is some missing protocol in >>> NonInteractiveUIManager (because at the time i was adding it , i >>> covered all methods, >>> but then some more stuff were added to morphic ui manager without >>> parallel extension to other ui managers, >>> so the test above can fail because you will get DNU error instead of >>> ErrorNonInteractive ) >> >> I tried it: >> >> testStartup >> Â Â Â self shouldnt: Â [[1 inspect] on: ErrorNonInteractive do: [:x | ]] raise: Â Error >> >> But this still fails. You can try using the attached st file. >> >> Cheers, >> Doru >> > >> >>>> Cheers, >>>> Doru >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> -- >> www.tudorgirba.com >> >> "The coherence of a trip is given by the clearness of the goal." >> >> >> >> > > -- > www.tudorgirba.com > > "What is more important: To be happy, or to make happy?" > > > -- Lukas Renggli www.lukas-renggli.ch

June 5, 2011

Re: [Pharo-project] Cuis 3.3

by StÃ©phane Ducasse

thanks! Stef On Jun 5, 2011, at 9:30 PM, Guillermo Polito wrote: > > > On Sun, Jun 5, 2011 at 4:53 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > > Maybe we can list the interesting things to add and open tickets? That we we'll not forget ;) > > Yes here is the list > > > > > On Sat, Jun 4, 2011 at 6:09 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > Hi guys > > > > Some items would be good to have in pharo like the event cleaning... to bad that we cannot collaborate more > > but this is like that. > > > > May be have a look > > > * New hierarchy of Morphic Windows for tools, builds and handles UI > > and menus; handles keystrokes > > - View / Model separation is now complete > > - Models are now GUI agnostic: they have 25% less methods and no references to Morphs > > > http://code.google.com/p/pharo/issues/detail?id=4359 > > we are rewriting all StringHolder with the same purpose so comparing is interesting at the design level. > > certainly: > > > * Object level events cleanup > > - Gone is Model and the DependentsFields classVar in Object > > - Only object event system mechanism is #when:send:to: > > It's already here: > > http://code.google.com/p/pharo/issues/detail?id=4352&colspec=ID%20Type%20St… > > > > > * Deep Models cleanup > > http://code.google.com/p/pharo/issues/detail?id=4360 > > > > > * Big cleanup of copy and friends. > > - #deepCopy eliminated > > - #veryDeepCopy, DeepCopier, #veryDeepInner:, > > #veryDeepFixupWith: eliminated. > > http://code.google.com/p/pharo/issues/detail?id=4361&q=owner%3Ame&colspec=I… > > > > * Editor tweaks and enhancements. Code simplification, removed > > several ivars > > > > > http://code.google.com/p/pharo/issues/detail?id=4362 > > > > * FileList refactor > > > http://code.google.com/p/pharo/issues/detail?id=4363 >

June 5, 2011