- Pharo-dev - lists.pharo.org

[Pharo-project] Developing morphic apps with pharo - sorting wheat from chaff

by Michael Forster

Hi, I'm writing a desktop business application for a customer. Having written a number of web applications using Pharo and Seaside, I would like to use Pharo and Morphic in this case. I have read the section on Morphic in `Pharo by Example', however, writing a business application (i.e. CRUD), I need to focus on (tedious) data browsing and entry, keyboard navigation, and so on as opposed to (cool) interactive morphs. My problem is trying to discern the the current and most stable approach to using Morphic for such an application. Clearly, I have a wealth of code at my fingertips and the Squeak wiki has numerous posts, but many of the latter seem outdated and speak only vaguely of the MVC vs. Morphic situation. Do I use ToolBuilder? Are pluggable morphs a vestige of MVC? Do I use PolyMorph widgets? Do I use dependencies, events, or announcements? I am very interested in seeing Pharo succeed as a business application development tool (among other uses), and I would be quite happy to contribute to code and documentation to help that along. However, first, I need to learn how to sort the wheat of Morphic from the chaff of MVC and whatever else is lying around in a Pharo image. Any pointers to (more) definitive documentation and classes would be much appreciated. Regards, Mike -- Michael J. Forster <mike(a)sharedlogic.ca>

Feb. 25, 2010

Re: [Pharo-project] We should run + fix the tests in 1.1

by Marcus Denker

On Feb 25, 2010, at 4:27 PM, Yanni Chiu wrote: > StÃ©phane Ducasse wrote: >> ... testserver, where are you? > > I have: > > http://hudson.jooshr.org/job/Pharo1.1/ > > which builds once a day. cool! I added it to my RSS reader. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 25, 2010

Re: [Pharo-project] in 11233 merging is broken?

by GARY CHAMBERS

Something must be wrong with the script load somehow... Note that there are changes between working copy after load and Polymorph-Tools-Diff-StephaneDucasse.23.mcz. To fix for yourself at the moment, reload Polymorph-Tools-Diff-StephaneDucasse.23.mcz. Not an answer to why though... Regards, Gary. ________________________________ From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> To: Pharo-project Development <Pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, 25 February, 2010 15:50:40 Subject: [Pharo-project] in 11233 merging is broken? Hi all I'm trying to integrate changes and apparently I cannot merge anymore nothing show up :). two questions: - do you get the behavior with 11233 or it is only me. - any idea of the potential problem - Issue 2071: subclasses and withAllSubclasses should return a array. - Issue 2076: Clean Exceptions. - Issue 2072: clean RealEstateAgent. Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 25, 2010

[Pharo-project] in 11233 merging is broken?

by StÃ©phane Ducasse

Hi all I'm trying to integrate changes and apparently I cannot merge anymore nothing show up :). two questions: - do you get the behavior with 11233 or it is only me. - any idea of the potential problem - Issue 2071: subclasses and withAllSubclasses should return a array. - Issue 2076: Clean Exceptions. - Issue 2072: clean RealEstateAgent. Stef

Feb. 25, 2010

Re: [Pharo-project] We should run + fix the tests in 1.1

by StÃ©phane Ducasse

cool! Stef On Feb 25, 2010, at 4:27 PM, Yanni Chiu wrote: > StÃ©phane Ducasse wrote: >> ... testserver, where are you? > > I have: > > http://hudson.jooshr.org/job/Pharo1.1/ > > which builds once a day. There are other builds on the site. I only use > the Pharo1.0-Seaside3.0 configuration. The others were set up when I was > trying to decide what to base my development on. > > The builds often break (Pharo 1.1 and Seaside 3.0), which is to be > expected. Usually the problem is some dialog pops up waiting for a user > response. It often takes me a few days before I get around to fixing > these build problems. Anyhow, it's there for the moment, if people want > to use the results. > > -- > Yanni > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 25, 2010

Re: [Pharo-project] Thread UI

by Lukas Renggli

> From a test-clarity (and robustness) POV though, you'd be much much > better by instead asserting properties of the morphs layout/colors than > sampling of display colors... > | morph | > > Â Â Â Â morph := Morph new. > Â Â Â Â morph doLayoutIn: someBounds. > Â Â Â Â self assert: whatIExpectedWithAboveBounds equals: morph someLayoutVariable Also have a look the OB and Glamour morphic tests. They mostly does not display the actual morph to test it. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 25, 2010

Re: [Pharo-project] We should run + fix the tests in 1.1

by Yanni Chiu

StÃ©phane Ducasse wrote: > ... testserver, where are you? I have: http://hudson.jooshr.org/job/Pharo1.1/ which builds once a day. There are other builds on the site. I only use the Pharo1.0-Seaside3.0 configuration. The others were set up when I was trying to decide what to base my development on. The builds often break (Pharo 1.1 and Seaside 3.0), which is to be expected. Usually the problem is some dialog pops up waiting for a user response. It often takes me a few days before I get around to fixing these build problems. Anyhow, it's there for the moment, if people want to use the results. -- Yanni

Feb. 25, 2010

Re: [Pharo-project] Thread UI

by Henrik Johansen

Den 25.02.2010 15:05, skrev Alexandre Bergel: > Dear List, > > I am extending the current set of Mondrian tests. I would like to > force some system window to appear on the screen in order to properly > test the size of its composing morphs. However, I do not know how to > effectively make the morph show up on the screen in a test. > > For example, consider the following test with a contrived situation: > > testDummy > | morph c | > morph := Morph new openInWorld. > c := Display colorAt: 0@0. > morph delete. > self assert: c = morph color. > > If I run the test from a test runner, it will fail. However, if I open > a debugger and do a step by step, c = morph color is true. > > I guess the problem is that the morph is not actually displayed, since > the UI thread does not have the hand. Any idea how to force this? > > Cheers, > Alexandre > > You could insert World doOneCycle between the lines morph := and c := >From a test-clarity (and robustness) POV though, you'd be much much better by instead asserting properties of the morphs layout/colors than sampling of display colors... | morph | morph := Morph new. morph doLayoutIn: someBounds. self assert: whatIExpectedWithAboveBounds equals: morph someLayoutVariable Cheers, Henry

Feb. 25, 2010

Re: [Pharo-project] how to remove World?

by Henrik Johansen

Den 25.02.2010 13:49, skrev Esteban Lorenzano: > Ok, I tried passing a .st by command line: > > UIManager default: DummyUIManager new. > > Project uiProcess terminate. > > SmalltalkImage current snapshot: true andQuit: true. > > but I fail miserably :'( > (it stops do anything after "Project uiProcess terminate"... and the > same using "Project uiProcess suspend") > > Any idea of how can I proceed from here? (I confess: I'm totally lost here) > > Cheers, > Esteban > As Lukas already said, that's not very strange if the script is being executed by the uiProcess. (which it is if you're using the ProjectLauncher) You can't plan to kill yourself, then afterwards send a goodbye-letter to your friends, you need to get someone else to perform the actions if you want to be sure it happens. (ie. fork off the execution) Cheers, Henry

Feb. 25, 2010

Re: [Pharo-project] Diff tools

by GARY CHAMBERS

Done in Polymorph-Tools-Diff-gvc.23 on SqueakSource/UIEnhancements, includes (from version 22) keyboard shortcuts for existing menu items. ________________________________ From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> To: Pharo-project(a)lists.gforge.inria.fr Sent: Tuesday, 23 February, 2010 19:06:04 Subject: Re: [Pharo-project] Diff tools On Feb 23, 2010, at 7:04 PM, Gary Chambers wrote: > I'll give it a go (keyboard shortcuts included) in the next DiffTools > version... > I guess you won't want a warning dialog the "What you are choosing means > that any conflicts will be unchecked"... ;-) :) > So, "use incoming for all incoming conficts" and "use current for all > conflicts"? Yeap! _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 25, 2010