- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Why StringHolder

by Guillermo Polito

On Tue, Aug 10, 2010 at 6:00 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > > Benjamin started and rewrote the recentMessages and friends. > If people can review his code it would be great. > Ok, I'll watch it a few minutes this evening. > > > Related with the issue > http://code.google.com/p/pharo/issues/detail?id=2757 (Issue 2757: Refactor > StringHolder) I was looking at the StringHolder hierarchy, and well, it's > not very nice. Playing to see how difficult should it be to refactor the > hierarchy and decouple a bit those things, I took Workspace off from there, > and writing 2 methods it happened to work well (at least with what I tested, > hehe). > > > > Sooo, I wondered why a StringHolder, what responsibilities it has, and > what ones should it have... I found that most of the messages a > StringHolder understands are for browsing things and inspect things, such as > the Paragraph editor does :). And that's why Workspace could do all his > stuff when I made him inherit from Object... > > I think that we should > - Replace ParagraphEditor by SmalltalkEditor, TextEditor > (did not check but it should be like that in CUIS and > Squeak) > What's CUIS? :( > > In Squeak > > TextMorph >> initialize > "TextMorph initialize" > "Initialize the default text editor class to use" > DefaultEditorClass := SmalltalkEditor. > > - then we should probably rewrite some parts and do not inherit from > StringHolder > I never understood why MessageSet is a subclass of Browser :) > But I would focus on the > > on the ...? > > > StringHolder class comment says: "I am a kind of Model that includes a > piece of text. In some cases, the text can be edited, and in some the text > is a method." > > > > And I smell that its main responsibility is to hold a Text or a String in > its contents variable, and all its subclasses are there because of that... > And if so, I don't like that inheritance approach :). > > This is exact. > > > I want to destroy (literally) that hierarchy :). And maybe it helps us > in coming refactors and cleanings, so we can do them with less fear :P. > > So could you > review benjamin code? > This evening I'll check it and compare it with the existant RecentMessageSet and that stuff. > then check the texteditor/paragraphEditor I'll write it down in my TODO list :). But the idea is to replace ParagraphEditor with them, is it? > > > > Well, this mail is just for ask for advice and argue about the > correctness of this change (or not). > > > > Thanks for reading up to here! > > Guille > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 10, 2010

[Pharo-project] Poll: missing libraries to support business

by Stephan Eggermont

Philippe wrote: >Rather than imagining what problems non-users could have I'd focus on >what problems existing users have. Instead of building libraries that >you'll have to maintain forever I'd focus in infrastructure that allows >users to write the libraries they need themselves. >Executive summary: >- HTTP(S) >- SqueakDBX >- VM/Cog/kernel/FFI/Alien - making it possible to use all the memory in my system: 64 bit. Stephan

Aug. 10, 2010

Re: [Pharo-project] Autotest, proof-of-concept [was: About TDD and Pharo]

by Alexandre Bergel

Sorry to answer so late. I was having few days off. I am now up and running :-) > Now that I've managed to use Pharo at work (youhou !!) I'm in a case where I have very long tests (selenium acceptance tests) *and* I want them to run. Ideally I also want to queue and schedule them (if a test is saved twice in a queue, run only once and put it in higher position on the queue). How can a test be saved twice in a queue? If you accept twice the same method? > Solutions: > - have to running modes for Autotest (normal and batch) > - tagging > - ? tagging will not work I feel. We could have different modes for autotest: -exhaustive: run all the tests, including long ones -transparent: run no more than 2 short tests -test only: run the test only when I modify them Cheers, Alexandre > > > On Mon, Jul 26, 2010 at 8:01 AM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > Ideally, we should not tag long tests. The system should be smart enough to characterize a test as long. If it takes more than 200ms, then it is long. Autotest should then offer me to include long test or not in the automatic test execution. > > Using tags means that I have to go over each method test and tag them. This is a costly effort that is likely to not work in practice. > > We have > -=-=-=-=-=-=-=-=-=-=-=-= > TestCase class>>newTestDictionary > ^ Dictionary new at: #timeStamp put: TimeStamp now; > at: #passed put: Set new; > at: #failures put: Set new; > at: #errors put: Set new; > yourself > -=-=-=-=-=-=-=-=-=-=-=-= > > Maybe it should be extended with > -=-=-=-=-=-=-=-=-=-=-=-= > at: #long put: Set new > -=-=-=-=-=-=-=-=-=-=-=-= > > I guess the tweak in SUnit to identify long tests should not be that hard to implement. > > Cheers, > Alexandre > > > On 26 Jul 2010, at 07:44, laurent laffont wrote: > > > > > On Sat, Jul 24, 2010 at 10:16 AM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > > I have been using Autotest for a while already. I greatly reduce the window switching. This is cool. > > However, I have to disable Autotest when the tests take time to execute. > > > > > > An idea is to be able to tag tests with pragmas to put them in categories. So we can have a LongRunning category which is not run by default. Like NUnit (http://www.nunit.org/index.php?p=category&r=2.2) > > > > Then SUnit could be enhanced to show these categories. Useful to quickly select all tests related to a project for example; or run only performance tests. > > > > > > How would you name the tag ? Where the implementation should go ? (TestCase ?) > > > > > > Laurent. > > > > > > Alexandre > > > > > > On 15 Jun 2010, at 21:41, laurent laffont wrote: > > > > > Hi Alexandre, > > > > > > I've reorganized Autotest to write tests. The tests now run in a thread with lower priority. Thanks for feedback. > > > > > > Cheers, > > > > > > Laurent Laffont > > > > > > http://pharocasts.blogspot.com/ > > > http://magaloma.blogspot.com/ > > > > > > > > > On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > > > Hi Laurent, > > > > > > I tried to program while having AutoTest running. > > > More importantly than the interface, I experienced some problem with long executing tests. Basically, these tests should not be executed while I am programming. Or at least in a thread of a lesser priority. Am I the only one to experience this? > > > > > > Cheers, > > > Alexandre > > > > > > > > > On 11 Jun 2010, at 09:02, laurent laffont wrote: > > > > > > > On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > > > > Hi Laurent, > > > > > > > > I like Autotest. It is true that I always execute the test after modifying it. > > > > There are three horizontal panes. Why so? Is it just to open a debugger when necessary? > > > > > > > > I want to be able to open a debugger from autotest. I agree the GUI is crap now. > > > > > > > > > > > > We could imagine one standalone button instead with a green color to say the test I just edited is green, and yellow or red when it fails. In that case, clicking on the button open a debugger. > > > > > > > > I just feel the window of autotest takes a lot of space in the screen, without having a real benefit. > > > > > > > > Yes it's true. I'm still thinking on a good GUI. But I'm learning how to make GUI now :) > > > > > > > > If you look at Autotest package, AutotestView is just the GUI, so we can implement several GUI and see the best solution. I need to take the time to do it, repository is read / write so feel free to commit :) > > > > > > > > What I want to have is a dashboard docked on one side of the screen which acts like you're driving a car. It's always visible, you have to be able to look quickly at it as when you check the speed of your car, adjust your drive, .... > > > > > > > > Also another problem with the current version if that if a test fails, change it and fails again, you don't see it has run (nothing moves in the GUI). > > > > > > > > Finally, another problem is that you see that a test has failed, but you don't know why (SUnit TestRunner has the same problem). I want to display the exception message too. > > > > > > > > Thanks a lot for feedback. > > > > > > > > Laurent Laffont > > > > > > > > http://pharocasts.blogspot.com/ > > > > http://magaloma.blogspot.com/ > > > > > > > > > > > > > > > > Cheers, > > > > Alexandre > > > > > > > > > > > > On 3 Jun 2010, at 17:11, laurent laffont wrote: > > > > > > > > > Hi, > > > > > > > > > > I've written a proof-of-concept for Autotest. Draft/crappy code and no tests (exploration mode :) but it loads on PharoCore-1.1-11383-beta image. > > > > > > > > > > Load it: > > > > > Gofer new > > > > > squeaksource: 'Autotest'; > > > > > package: 'Autotest'; > > > > > load > > > > > > > > > > Open it: > > > > > AutotestView open > > > > > (there's en entry in WorldMenu > Tools) > > > > > > > > > > And change a tested method to see the results. > > > > > > > > > > There's a bug I need to find, maybe someone knows: > > > > > - Change Bag>>occurrencesOf: > > > > > - Autotest gives: > > > > > > > > > > 284 run, 281 passes, 0 expected failures, 1 failures, 2 errors, 0 unexpected passes > > > > > Failures: > > > > > CollectionRootTest>>#test0FixtureIterateTest > > > > > > > > > > Errors: > > > > > CollectionRootTest>>#testBasicCollect > > > > > CollectionRootTest>>#testDoWithout > > > > > > > > > > but in SUnit CollectionRootTest gives > > > > > 0 run, 0 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes ?? > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Laurent Laffont > > > > > > > > > > http://pharocasts.blogspot.com/ > > > > > http://magaloma.blogspot.com/ > > > > > > > > > > > > > > > On Thu, Jun 3, 2010 at 6:09 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > > > > > The idea is excellent. > > > > > > > > > > Cheers, > > > > > Alexandre > > > > > > > > > > > > > > > On 3 Jun 2010, at 10:22, laurent laffont wrote: > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 3, 2010 at 3:42 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > > > > > > > You may have a lot of noise. > > > > > > > > > > > > > > I guess that Ruby uses files as a unit of development/deployment. The closest Smalltalk/Pharo has is the class and the package. > > > > > > > > > > > > > > I would suggest that TestCase which would use this feature use some pragma/method to identify/declare which classes/packages this test depends upon. Then the "autotest" framework would register such tests and listen for changes in the given classes/packages, launching required tests whenever a change happen. > > > > > > > > > > > > > > Additionally, one could declare such a pragma on a single test method, when this test should be run for a specific class. > > > > > > > > > > > > > > Of course, you also to take care of long running tests, which you probably want to exclude from auto-testing. > > > > > > > > > > > > I see autotest in Pharo in a slighly different way: When I press save in the Monticello browser, I have a popup menu which asks me whether (i) I want to run all the tests or (ii) only the tests that cover that I changed from the last version. > > > > > > > > > > > > Does this make sense? > > > > > > > > > > > > Please no popup :) What I like in ruby autotest is that I can quickly look at test results if I want (or not) without stop writing. Often you want to see your tests failing, as you type / save code. I don't have to stop writing, click a button, wait test results, go again.... testing is done in background and I just see notifications whether it's OK or not. > > > > > > > > > > > > So test log in a Transcript is OK for me. > > > > > > > > > > > > > > > > > > For autotest unit of work is file: it runs the test file which has the same name as the code file, but you can customize this behavior. For autotest-rails: > > > > > > "A simplified version of Autotest heuristics in this mode would be: > > > > > > When changing a test file, only this file is run (e.g. test/unit/foo_test.rb âtest/unit/foo_test.rb). > > > > > > When changing a model file, only associated unit test file is run (e.g.app/models/foo.rb â test/unit/foo_test.rb). > > > > > > When changing a controller file, associated functional test file is run (e.g.app/controllers/foo_controller.rb âtest/functional/foo_controller_test.rb). > > > > > > When changing a fixture file, associated unit test and functional test are run (e.g.app/fixtures/foos.yml â test/unit/foo_test.rb +test/functional/foo_controller_test.rb). > > > > > > When changing a helper file, associated functional test file is run (e.g.app/helpers/foo_helper.rb âtest/functional/foo_controller_test.rb). > > > > > > When changing application_helper.rb file all functional test files are run (e.g.application_helper.rb â test/functional/*_test.rb). > > > > > > When changing a file under the config directory, all tests are run." > > > > > > > > > > > > Laurent > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > Alexandre > > > > > > -- > > > > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > > > > Alexandre Bergel http://www.bergel.eu > > > > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Pharo-project mailing list > > > > > > Pharo-project(a)lists.gforge.inria.fr > > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > > > > _______________________________________________ > > > > > > Pharo-project mailing list > > > > > > Pharo-project(a)lists.gforge.inria.fr > > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > > -- > > > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > > > Alexandre Bergel http://www.bergel.eu > > > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pharo-project mailing list > > > > > Pharo-project(a)lists.gforge.inria.fr > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > > _______________________________________________ > > > > > Pharo-project mailing list > > > > > Pharo-project(a)lists.gforge.inria.fr > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > -- > > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > > Alexandre Bergel http://www.bergel.eu > > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > Pharo-project(a)lists.gforge.inria.fr > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > Pharo-project(a)lists.gforge.inria.fr > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 10, 2010

Re: [Pharo-project] Question: How can I add a items to System Browser Window menu?

by Lukas Renggli

But in OB that should be easy. You can add, remove and change any command without the need for an override. The only exception is the code pane which gets its is commands from the Paragraph editor. Lukas On Tuesday, August 10, 2010, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > what would be create is to step by step make all menus easily extenesible. Like nowadays with the world menu and pragmas > > Carla, once I had a similar problem and the only solution was to override that method with a *MyPackage in that method, and add there the menu entried I wanted...this is completly wrong and sucks...but was the only thing I found > > cheers > > 2010/8/10 Carla F. Griggio <carla.griggio(a)gmail.com> > > Thanks!!! I'll try that! :D > > 2010/8/10 laurent laffont <laurent.laffont(a)gmail.com> > > > > 2010/8/10 Carla F. Griggio <carla.griggio(a)gmail.com> > > > > > > Ohh, I understand now. > I was using the OmniBrowser System Browser. > > Either case, I don't know how I can customize the menu that appears when I right click on a category without changing the original code :( I want to "extend" that, not change it, just add a new comand option. > Do you know if it's possible? > > You need to create a subclass of OBCommand which define these methods:execute: what to do when clicking on itgroup: answers a symbol to know in which group it will be displayed in > > > > > isActive: answers if the item is enabled/disabledkeystroke: answers the char for shortcutlabel: answers the labelorder: answers the position > example: > > > > > > OBCommand subclass: #OBCmdRunAutotest instanceVariableNames: '' classVariableNames: '' > > > > > poolDictionaries: '' category: 'OB-Autotest' > > > execute |method| method := target theClass >> target selector. > > OBWaitRequest block: [ Â AutotestDashboard default triggerAutotestOn: method ]. > group ^ #testing > > > > > > isActive ^ (requestor isSelected: target) and: [target isKindOf: OBMethodNode ] > keystroke > > ^ $T > label ^ 'trigger autotest' > > > order ^ '3' > > Look at OBCommand subclasses for more examples. > > Cheers,Â Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ > > > > Â I can change it adding an option in Morph>>buildMetaMenu: evt, but I wanted to keep that code clean... > > > > > > > > On Tue, Aug 10, 2010 at 12:25 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > 2010/8/9 Carla F. Griggio <carla.griggio(a)gmail.com>: >> Exactly what Guille captured in the image he attached. When I open that >> window from the World menu it says 'System Browser', although it could >> actually be an OmniBrowser on the system categories internally... Are they >> two different things? > > I don't know which image you are using, some Pharo images includes the > OmniBrowser package already loaded and this is what you're probably > opening from the World menu. > > It isn't clear from the world menu which browser (System or Omni) > you're going to open. > You mi -- Lukas Renggli www.lukas-renggli.ch

Aug. 10, 2010

[Pharo-project] NullTextStyler

by StÃ©phane Ducasse

Hi fernando benjamin did a NullTextStyler. I did a pass but I'm not sure this is good :) Gofer new squeaksource: 'PharoTaskForces'; package: 'RecentSubmissions'; load. Could you have a look at it and I would like to push it in the image because I think that this is a nice infrastructural class to have. Stef

Aug. 10, 2010

Re: [Pharo-project] Early days of an MVP framework

by Gary Chambers

Rather than use ComposableMorph directly you will be better off just using it to build the morphs you need. A PanelMorph will pass on #enabled: to its submorphs, rows and columns are made from PanelMorphs too. An example: |row| row := UITheme builder newRow: { UITheme builder newCheckboxFor: nil getSelected: nil setSelected: nil label: 'Checkbox in a panel' help: nil. UITheme builder newButtonFor: nil action: nil label: 'Button in panel' help: nil}. row vResizing: #spaceFill; listCentering: #center; wrapCentering: #center. ((UITheme builder newColumn: { row. UITheme builder newRow: { (UITheme builder newButtonFor: row action: #enabled: label: 'Enable panel' help: nil) arguments: {true}. (UITheme builder newButtonFor: row action: #enabled: label: 'Disable panel' help: nil) arguments: {false}}}) extent: 300@100; openInWindow) setLabel: 'Panel Enablement' Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, August 10, 2010 5:19 AM Subject: Re: [Pharo-project] Early days of an MVP framework > Gary, > > Is there a way to disable a ComposableMorph and all of its children? > > Bill > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr > [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm > K [bschwab(a)anest.ufl.edu] > Sent: Monday, August 09, 2010 10:38 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Early days of an MVP framework > > Gary, > > I have a composite GUI that appears to work. I need to mask about 3,000 > images in pairs of three that repeat in sequences (don't worry, you'll be > happier if you don't understand<g>). I am hoping to use the first triad > in each sequence as the basis for a "fill down" command that will > hopefully leave me making only minor edits to most of the masks. > > Thanks! > > Bill > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr > [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm > K [bschwab(a)anest.ufl.edu] > Sent: Monday, August 09, 2010 7:05 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Early days of an MVP framework > > Gary, > > I tried making some changes and found it very easy to end up with an empty > shell. It appears that you are using the builder as a factory and are > completely uninterested in hanging on to it :) Is that accurate? Is it > good design? > > Bill > > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > Schwab,Wilhelm K > Sent: Monday, August 09, 2010 5:06 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Early days of an MVP framework > > Gary, > > Thanks for the examples. One thing is driving me nuts: in the past, I > thought that creating a new row or column made a morph but did not add it > to the morph being created. Might I have added them redundantly? Does > re-adding a child have no effect or somehow replace it? Is this a > morphi/Polymorph beginner trap? Be honest, I can take it :) > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary > Chambers > Sent: Monday, August 09, 2010 5:45 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Early days of an MVP framework > > And with a stack layout... > > (UITheme builder > newColumn: { > UITheme builder newTabGroup: { > 'First page' -> ((UITheme builder newStack: { > (UITheme builder > newAlphaImage: UITheme current warningIcon > help: nil) > alpha: 0.5. > CircleMorph new > hResizing: #spaceFill; > vResizing: #spaceFill}) > fillStyle: Color red; > hResizing: #spaceFill; > vResizing: #spaceFill). > 'Second page' -> (UITheme builder newPanel > fillStyle: Color green; > hResizing: #spaceFill; > vResizing: #spaceFill)}. > (UITheme builder newRow: { > UITheme builder newOKButton. > UITheme builder newCancelButton}) > listCentering: #bottomRight}) > extent: 200@300; > openInWindow > > Regards, Gary > > ----- Original Message ----- > From: "Gary Chambers" <gazzaguru2(a)btinternet.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, August 09, 2010 11:30 AM > Subject: Re: [Pharo-project] Early days of an MVP framework > > >> This even (to get buttons on right with correct tab key navigation >> ordering... >> >> (UITheme builder >> newColumn: { >> UITheme builder newTabGroup: { >> 'First page' -> (UITheme builder newPanel >> fillStyle: Color red; >> hResizing: #spaceFill; >> vResizing: #spaceFill). >> 'Second page' -> (UITheme builder newPanel >> fillStyle: Color green; >> hResizing: #spaceFill; >> vResizing: #spaceFill)}. >> (UITheme builder newRow: { >> UITheme builder newOKButton. >> UITheme builder newCancelButton}) >> listCentering: #bottomRight}) >> extent: 200@300; >> openInWindow >> >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Gary Chambers" <gazzaguru2(a)btinternet.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Monday, August 09, 2010 11:07 AM >> Subject: Re: [Pharo-project] Early days of an MVP framework >> >> >>> Any Morph can use a layoutPolicy. >>> Available are >>> none (position based) >>> Prorportional (frame/fractions/offsets) >>> Table (overly complex too) >>> Row (one of mine, quicker for simple rows) >>> Stack (mine, overlay morphs on top of each other) >>> >>> TEasilyThemed provides some methods like... >>> >>> newRow: {aMorph, anotherMorph} >>> newColumn: >>> >>> Something like this works... >>> >>> (UITheme builder >>> newColumn: { >>> UITheme builder newPanel >>> fillStyle: Color red; >>> hResizing: #spaceFill; >>> vResizing: #spaceFill. >>> UITheme builder newRow: { >>> UITheme builder newOKButton. >>> UITheme builder newCancelButton}}) >>> extent: 200@300; >>> openInHand >>> >>> (can use openInWindow also)... >>> >>> Rather busy today, hope this helps in the meantime... >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> >>> To: <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Sunday, August 08, 2010 11:46 PM >>> Subject: [Pharo-project] Early days of an MVP framework >>> >>> >>>> Gary, >>>> >>>> I was on an unstoppable roll (salvaged early on by Andreas' bitblt >>>> coaching), until I needed to repeat a "complex" GUI component and >>>> wanted/insisted on doing so with some reuse. Seaside gives us >>>> components on web pages; we need them for GUI code too. I tried >>>> turning my presenter-like structures into factories that would add >>>> morphs to a single shell, but it fell apart when it came time to set >>>> the framing values. I was not particularly interested in fixing it, >>>> because if I could do that, I would simply build proper composite >>>> widgets using the fix. >>>> >>>> The problem appears to be in SystemWindow, which does some >>>> incredibly complicated things, all of which (correct me if I am >>>> wrong) would be unnecessary if only there were a good set of layout >>>> managers. I can get very simple-minded about things, but it would >>>> make a whole lot more sense to me to create rows and columns of >>>> widgets, adding splitters between them until the whole things >>>> behaves as intended, rather than writing code (present only in a >>>> top-level shell) that tries to split things up into rows using its >>>> own judgment. Not good. I realize you did not create the >>>> situation, and have done wonders to make it work far better than when >>>> you found it. >>>> >>>> Some time ago, I built an emulated widget framework for Dolphin, >>>> which I needed because the combination of Dolphin's view resources >>>> and Windows itself was too slow for what I was trying to do. That >>>> project included a somewhat strange set of layout classes, but the >>>> basics are present, and it is not Object Arts' IP. I ported the >>>> classes to Pharo and did some work on stub View and Presenter >>>> classes that I had added to Pharo largely to passify my code that I >>>> was importing from Dolphin. The layouts think in terms of emulated >>>> widgets, and I see no reason to change their minds: I might want to >>>> replicate the framework. However, dynamic typing and a couple of >>>> extra methods allow them to work with just about anything. My goals >>>> are modest. Being able to compose rows and columns would do a lot >>>> for me. Add splitters and the ability to fix the size of some items, >>>> and I could almost anything I would need. >>>> >>>> View class>>example >>>> | row column dot square out shell | >>>> dot := ( Form dotOfSize:100 ) asFormOfDepth:32. >>>> square := ( Form squareOfSize:100 ) asFormOfDepth:32. >>>> out := Array writeStream. >>>> >>>> row := ContainerView row. >>>> 2 timesRepeat:[ >>>> column := row addSubview:ContainerView column. >>>> 2 timesRepeat:[ >>>> out nextPut:( >>>> column addSubview:ImageView new >>>> ). >>>> ]. >>>> ]. >>>> >>>> out contents with:{ dot copy. square copy. square copy. dot copy. } >>>> do:[ :view :form | view morph image:form. >>>> ]. >>>> >>>> row rectangle:( 0@0 extent:400@400 ). >>>> row layout. >>>> >>>> shell := StandardWindow labelled:'Hello MVP'. >>>> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself. >>>> >>>> >>>> The above code produces an array of dots and squares, as intended. >>>> One quirk is that the grid does not resize as the shell resizes, a >>>> consequence of my not having hooked it up to resize events. I might >>>> get some interesting meltdowns once I begin to do that =:0 I used >>>> your PanelMorph as the "view" associated with ContainerView. What, >>>> ContainView isn't a view??? No. The code is biased toward Morphic, >>>> but hopefully the same code should extend to wx, GTK, etc. >>>> Dolphin's views have a handle instance variable to control the >>>> external resource; these views have an instance variable pointing to >>>> their morph. Handling of sub views works pretty much as in Dolphin: >>>> any view/morph can have children, but adding them is "legal" only for >>>> composites. >>>> >>>> Most systems I have seen treat coordinates relative to the >>>> parent/owner, but not Morphic. I remember seeing plans to make the >>>> change, but nothing after that. The view instances provide a >>>> natural place to fix things, so I took the plunge. If we switch to >>>> some other graphical realization, we can simply remove the the >>>> transformation. >>>> >>>> Are the existing splitters as strange as SystemWindow? By that I >>>> mean, would it be reasonable to add them between other morphs and >>>> look for events from them, or will they have to be replaced? I will >>>> eventually need splitters, but I could initially live without them >>>> if I can get reliable composition where I need it. >>>> >>>> There are very few view classes at present. MorphView can wrap >>>> almost anything, so it might be better to create a rich set of >>>> presenters instead. Dolphin's view resources are going to be >>>> interesting to replace. There are some complexities that I suspect >>>> are in deference to Windows, and some that might be avoidable. For >>>> our purposes, it might be enough to use SIXX to serialize a bunch of >>>> message sends and gzip the results to save memory. Another option >>>> might be to rely on class methods; having full closures won't hurt; >>>> they might allow sufficient hooking that resources in the Dolphin sense >>>> won't even be necessary. >>>> The desire for them quickly arises because views get realized in >>>> places know nothing about how the views should be configured; at >>>> least I think that is what happened to me after just a couple of >>>> hours. I am far less interested in having a graphical view editor >>>> than I am in being able to write **GOOD** code that assembles things >>>> as I want. If the result happens to allow a graphical editor too, so >>>> much the better. >>>> >>>> Any interest? >>>> >>>> Bill >>>> >>>> >>>> ----------------------------- >>>> >>>> View >>>> MorphViev >>>> ImageView >>>> ContainerView >>>> >>>> ViewGadgetLayoutAbstract >>>> ScrollerGadgetLayout >>>> NullViewGadgetLayout >>>> FixedStretchFixedGadgetLayout >>>> ProportionalGadgetLayout >>>> PreferredExtentsGadgetLayout >>>> GridGadgetRowsLayout >>>> VerticalListLayout >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 10, 2010

Re: [Pharo-project] Fwd: Re: Squeaksource XML Parser - Enhanced support for CDATA Sections

by StÃ©phane Ducasse

> > coalesceCDATASections: aBoolean > > or > > enableCoalescing > disableCoalescing most of the time you need the 3 because the first one let you easily build scripts for me > coalesceCDATASections: aBoolean is a setter not a testing selector

Aug. 10, 2010

Re: [Pharo-project] Early days of an MVP framework

by Gary Chambers

UITheme builder answers a singleton ComposableMorph so is technically reused. Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, August 10, 2010 12:05 AM Subject: Re: [Pharo-project] Early days of an MVP framework > Gary, > > I tried making some changes and found it very easy to end up with an empty > shell. It appears that you are using the builder as a factory and are > completely uninterested in hanging on to it :) Is that accurate? Is it > good design? > > Bill > > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > Schwab,Wilhelm K > Sent: Monday, August 09, 2010 5:06 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Early days of an MVP framework > > Gary, > > Thanks for the examples. One thing is driving me nuts: in the past, I > thought that creating a new row or column made a morph but did not add it > to the morph being created. Might I have added them redundantly? Does > re-adding a child have no effect or somehow replace it? Is this a > morphi/Polymorph beginner trap? Be honest, I can take it :) > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary > Chambers > Sent: Monday, August 09, 2010 5:45 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Early days of an MVP framework > > And with a stack layout... > > (UITheme builder > newColumn: { > UITheme builder newTabGroup: { > 'First page' -> ((UITheme builder newStack: { > (UITheme builder > newAlphaImage: UITheme current warningIcon > help: nil) > alpha: 0.5. > CircleMorph new > hResizing: #spaceFill; > vResizing: #spaceFill}) > fillStyle: Color red; > hResizing: #spaceFill; > vResizing: #spaceFill). > 'Second page' -> (UITheme builder newPanel > fillStyle: Color green; > hResizing: #spaceFill; > vResizing: #spaceFill)}. > (UITheme builder newRow: { > UITheme builder newOKButton. > UITheme builder newCancelButton}) > listCentering: #bottomRight}) > extent: 200@300; > openInWindow > > Regards, Gary > > ----- Original Message ----- > From: "Gary Chambers" <gazzaguru2(a)btinternet.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, August 09, 2010 11:30 AM > Subject: Re: [Pharo-project] Early days of an MVP framework > > >> This even (to get buttons on right with correct tab key navigation >> ordering... >> >> (UITheme builder >> newColumn: { >> UITheme builder newTabGroup: { >> 'First page' -> (UITheme builder newPanel >> fillStyle: Color red; >> hResizing: #spaceFill; >> vResizing: #spaceFill). >> 'Second page' -> (UITheme builder newPanel >> fillStyle: Color green; >> hResizing: #spaceFill; >> vResizing: #spaceFill)}. >> (UITheme builder newRow: { >> UITheme builder newOKButton. >> UITheme builder newCancelButton}) >> listCentering: #bottomRight}) >> extent: 200@300; >> openInWindow >> >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Gary Chambers" <gazzaguru2(a)btinternet.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Monday, August 09, 2010 11:07 AM >> Subject: Re: [Pharo-project] Early days of an MVP framework >> >> >>> Any Morph can use a layoutPolicy. >>> Available are >>> none (position based) >>> Prorportional (frame/fractions/offsets) >>> Table (overly complex too) >>> Row (one of mine, quicker for simple rows) >>> Stack (mine, overlay morphs on top of each other) >>> >>> TEasilyThemed provides some methods like... >>> >>> newRow: {aMorph, anotherMorph} >>> newColumn: >>> >>> Something like this works... >>> >>> (UITheme builder >>> newColumn: { >>> UITheme builder newPanel >>> fillStyle: Color red; >>> hResizing: #spaceFill; >>> vResizing: #spaceFill. >>> UITheme builder newRow: { >>> UITheme builder newOKButton. >>> UITheme builder newCancelButton}}) >>> extent: 200@300; >>> openInHand >>> >>> (can use openInWindow also)... >>> >>> Rather busy today, hope this helps in the meantime... >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> >>> To: <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Sunday, August 08, 2010 11:46 PM >>> Subject: [Pharo-project] Early days of an MVP framework >>> >>> >>>> Gary, >>>> >>>> I was on an unstoppable roll (salvaged early on by Andreas' bitblt >>>> coaching), until I needed to repeat a "complex" GUI component and >>>> wanted/insisted on doing so with some reuse. Seaside gives us >>>> components on web pages; we need them for GUI code too. I tried >>>> turning my presenter-like structures into factories that would add >>>> morphs to a single shell, but it fell apart when it came time to set >>>> the framing values. I was not particularly interested in fixing it, >>>> because if I could do that, I would simply build proper composite >>>> widgets using the fix. >>>> >>>> The problem appears to be in SystemWindow, which does some >>>> incredibly complicated things, all of which (correct me if I am >>>> wrong) would be unnecessary if only there were a good set of layout >>>> managers. I can get very simple-minded about things, but it would >>>> make a whole lot more sense to me to create rows and columns of >>>> widgets, adding splitters between them until the whole things >>>> behaves as intended, rather than writing code (present only in a >>>> top-level shell) that tries to split things up into rows using its >>>> own judgment. Not good. I realize you did not create the >>>> situation, and have done wonders to make it work far better than when >>>> you found it. >>>> >>>> Some time ago, I built an emulated widget framework for Dolphin, >>>> which I needed because the combination of Dolphin's view resources >>>> and Windows itself was too slow for what I was trying to do. That >>>> project included a somewhat strange set of layout classes, but the >>>> basics are present, and it is not Object Arts' IP. I ported the >>>> classes to Pharo and did some work on stub View and Presenter >>>> classes that I had added to Pharo largely to passify my code that I >>>> was importing from Dolphin. The layouts think in terms of emulated >>>> widgets, and I see no reason to change their minds: I might want to >>>> replicate the framework. However, dynamic typing and a couple of >>>> extra methods allow them to work with just about anything. My goals >>>> are modest. Being able to compose rows and columns would do a lot >>>> for me. Add splitters and the ability to fix the size of some items, >>>> and I could almost anything I would need. >>>> >>>> View class>>example >>>> | row column dot square out shell | >>>> dot := ( Form dotOfSize:100 ) asFormOfDepth:32. >>>> square := ( Form squareOfSize:100 ) asFormOfDepth:32. >>>> out := Array writeStream. >>>> >>>> row := ContainerView row. >>>> 2 timesRepeat:[ >>>> column := row addSubview:ContainerView column. >>>> 2 timesRepeat:[ >>>> out nextPut:( >>>> column addSubview:ImageView new >>>> ). >>>> ]. >>>> ]. >>>> >>>> out contents with:{ dot copy. square copy. square copy. dot copy. } >>>> do:[ :view :form | view morph image:form. >>>> ]. >>>> >>>> row rectangle:( 0@0 extent:400@400 ). >>>> row layout. >>>> >>>> shell := StandardWindow labelled:'Hello MVP'. >>>> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself. >>>> >>>> >>>> The above code produces an array of dots and squares, as intended. >>>> One quirk is that the grid does not resize as the shell resizes, a >>>> consequence of my not having hooked it up to resize events. I might >>>> get some interesting meltdowns once I begin to do that =:0 I used >>>> your PanelMorph as the "view" associated with ContainerView. What, >>>> ContainView isn't a view??? No. The code is biased toward Morphic, >>>> but hopefully the same code should extend to wx, GTK, etc. >>>> Dolphin's views have a handle instance variable to control the >>>> external resource; these views have an instance variable pointing to >>>> their morph. Handling of sub views works pretty much as in Dolphin: >>>> any view/morph can have children, but adding them is "legal" only for >>>> composites. >>>> >>>> Most systems I have seen treat coordinates relative to the >>>> parent/owner, but not Morphic. I remember seeing plans to make the >>>> change, but nothing after that. The view instances provide a >>>> natural place to fix things, so I took the plunge. If we switch to >>>> some other graphical realization, we can simply remove the the >>>> transformation. >>>> >>>> Are the existing splitters as strange as SystemWindow? By that I >>>> mean, would it be reasonable to add them between other morphs and >>>> look for events from them, or will they have to be replaced? I will >>>> eventually need splitters, but I could initially live without them >>>> if I can get reliable composition where I need it. >>>> >>>> There are very few view classes at present. MorphView can wrap >>>> almost anything, so it might be better to create a rich set of >>>> presenters instead. Dolphin's view resources are going to be >>>> interesting to replace. There are some complexities that I suspect >>>> are in deference to Windows, and some that might be avoidable. For >>>> our purposes, it might be enough to use SIXX to serialize a bunch of >>>> message sends and gzip the results to save memory. Another option >>>> might be to rely on class methods; having full closures won't hurt; >>>> they might allow sufficient hooking that resources in the Dolphin sense >>>> won't even be necessary. >>>> The desire for them quickly arises because views get realized in >>>> places know nothing about how the views should be configured; at >>>> least I think that is what happened to me after just a couple of >>>> hours. I am far less interested in having a graphical view editor >>>> than I am in being able to write **GOOD** code that assembles things >>>> as I want. If the result happens to allow a graphical editor too, so >>>> much the better. >>>> >>>> Any interest? >>>> >>>> Bill >>>> >>>> >>>> ----------------------------- >>>> >>>> View >>>> MorphViev >>>> ImageView >>>> ContainerView >>>> >>>> ViewGadgetLayoutAbstract >>>> ScrollerGadgetLayout >>>> NullViewGadgetLayout >>>> FixedStretchFixedGadgetLayout >>>> ProportionalGadgetLayout >>>> PreferredExtentsGadgetLayout >>>> GridGadgetRowsLayout >>>> VerticalListLayout >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 10, 2010

Re: [Pharo-project] Early days of an MVP framework

by Gary Chambers

Making a new morph doesn't necessarily add it... the helper methods from TEasilyThemed (used by ComposableMorph for instance) generally take a collection of morphs as parameter to do that for you though. Re-adding will keep the same morph but typically position it at the front or back depending on the method used (addMorph: addMorphBack: etc.). Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, August 09, 2010 11:05 PM Subject: Re: [Pharo-project] Early days of an MVP framework > Gary, > > Thanks for the examples. One thing is driving me nuts: in the past, I > thought that creating a new row or column made a morph but did not add it > to the morph being created. Might I have added them redundantly? Does > re-adding a child have no effect or somehow replace it? Is this a > morphi/Polymorph beginner trap? Be honest, I can take it :) > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary > Chambers > Sent: Monday, August 09, 2010 5:45 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Early days of an MVP framework > > And with a stack layout... > > (UITheme builder > newColumn: { > UITheme builder newTabGroup: { > 'First page' -> ((UITheme builder newStack: { > (UITheme builder > newAlphaImage: UITheme current warningIcon > help: nil) > alpha: 0.5. > CircleMorph new > hResizing: #spaceFill; > vResizing: #spaceFill}) > fillStyle: Color red; > hResizing: #spaceFill; > vResizing: #spaceFill). > 'Second page' -> (UITheme builder newPanel > fillStyle: Color green; > hResizing: #spaceFill; > vResizing: #spaceFill)}. > (UITheme builder newRow: { > UITheme builder newOKButton. > UITheme builder newCancelButton}) > listCentering: #bottomRight}) > extent: 200@300; > openInWindow > > Regards, Gary > > ----- Original Message ----- > From: "Gary Chambers" <gazzaguru2(a)btinternet.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, August 09, 2010 11:30 AM > Subject: Re: [Pharo-project] Early days of an MVP framework > > >> This even (to get buttons on right with correct tab key navigation >> ordering... >> >> (UITheme builder >> newColumn: { >> UITheme builder newTabGroup: { >> 'First page' -> (UITheme builder newPanel >> fillStyle: Color red; >> hResizing: #spaceFill; >> vResizing: #spaceFill). >> 'Second page' -> (UITheme builder newPanel >> fillStyle: Color green; >> hResizing: #spaceFill; >> vResizing: #spaceFill)}. >> (UITheme builder newRow: { >> UITheme builder newOKButton. >> UITheme builder newCancelButton}) >> listCentering: #bottomRight}) >> extent: 200@300; >> openInWindow >> >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Gary Chambers" <gazzaguru2(a)btinternet.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Monday, August 09, 2010 11:07 AM >> Subject: Re: [Pharo-project] Early days of an MVP framework >> >> >>> Any Morph can use a layoutPolicy. >>> Available are >>> none (position based) >>> Prorportional (frame/fractions/offsets) >>> Table (overly complex too) >>> Row (one of mine, quicker for simple rows) >>> Stack (mine, overlay morphs on top of each other) >>> >>> TEasilyThemed provides some methods like... >>> >>> newRow: {aMorph, anotherMorph} >>> newColumn: >>> >>> Something like this works... >>> >>> (UITheme builder >>> newColumn: { >>> UITheme builder newPanel >>> fillStyle: Color red; >>> hResizing: #spaceFill; >>> vResizing: #spaceFill. >>> UITheme builder newRow: { >>> UITheme builder newOKButton. >>> UITheme builder newCancelButton}}) >>> extent: 200@300; >>> openInHand >>> >>> (can use openInWindow also)... >>> >>> Rather busy today, hope this helps in the meantime... >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> >>> To: <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Sunday, August 08, 2010 11:46 PM >>> Subject: [Pharo-project] Early days of an MVP framework >>> >>> >>>> Gary, >>>> >>>> I was on an unstoppable roll (salvaged early on by Andreas' bitblt >>>> coaching), until I needed to repeat a "complex" GUI component and >>>> wanted/insisted on doing so with some reuse. Seaside gives us >>>> components on web pages; we need them for GUI code too. I tried >>>> turning >>>> my presenter-like structures into factories that would add morphs to a >>>> single shell, but it fell apart when it came time to set the framing >>>> values. I was not particularly interested in fixing it, because if I >>>> could do that, I would simply build proper composite widgets using the >>>> fix. >>>> >>>> The problem appears to be in SystemWindow, which does some incredibly >>>> complicated things, all of which (correct me if I am wrong) would be >>>> unnecessary if only there were a good set of layout managers. I can >>>> get >>>> very simple-minded about things, but it would make a whole lot more >>>> sense to me to create rows and columns of widgets, adding splitters >>>> between them until the whole things behaves as intended, rather than >>>> writing code (present only in a top-level shell) that tries to split >>>> things up into rows using its own judgment. Not good. I realize you >>>> did not create the situation, and have done wonders to make it work far >>>> better than when you found it. >>>> >>>> Some time ago, I built an emulated widget framework for Dolphin, which >>>> I >>>> needed because the combination of Dolphin's view resources and Windows >>>> itself was too slow for what I was trying to do. That project included >>>> a somewhat strange set of layout classes, but the basics are present, >>>> and it is not Object Arts' IP. I ported the classes to Pharo and did >>>> some work on stub View and Presenter classes that I had added to Pharo >>>> largely to passify my code that I was importing from Dolphin. The >>>> layouts think in terms of emulated widgets, and I see no reason to >>>> change their minds: I might want to replicate the framework. However, >>>> dynamic typing and a couple of extra methods allow them to work with >>>> just about anything. My goals are modest. Being able to compose rows >>>> and columns would do a lot for me. Add splitters and the ability to >>>> fix >>>> the size of some items, and I could almost anything I would need. >>>> >>>> View class>>example >>>> | row column dot square out shell | >>>> dot := ( Form dotOfSize:100 ) asFormOfDepth:32. >>>> square := ( Form squareOfSize:100 ) asFormOfDepth:32. >>>> out := Array writeStream. >>>> >>>> row := ContainerView row. >>>> 2 timesRepeat:[ >>>> column := row addSubview:ContainerView column. >>>> 2 timesRepeat:[ >>>> out nextPut:( >>>> column addSubview:ImageView new >>>> ). >>>> ]. >>>> ]. >>>> >>>> out contents with:{ dot copy. square copy. square copy. dot copy. } >>>> do:[ :view :form | >>>> view morph image:form. >>>> ]. >>>> >>>> row rectangle:( 0@0 extent:400@400 ). >>>> row layout. >>>> >>>> shell := StandardWindow labelled:'Hello MVP'. >>>> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself. >>>> >>>> >>>> The above code produces an array of dots and squares, as intended. One >>>> quirk is that the grid does not resize as the shell resizes, a >>>> consequence of my not having hooked it up to resize events. I might >>>> get >>>> some interesting meltdowns once I begin to do that =:0 I used your >>>> PanelMorph as the "view" associated with ContainerView. What, >>>> ContainView isn't a view??? No. The code is biased toward Morphic, >>>> but >>>> hopefully the same code should extend to wx, GTK, etc. Dolphin's views >>>> have a handle instance variable to control the external resource; these >>>> views have an instance variable pointing to their morph. Handling of >>>> sub views works pretty much as in Dolphin: any view/morph can have >>>> children, but adding them is "legal" only for composites. >>>> >>>> Most systems I have seen treat coordinates relative to the >>>> parent/owner, >>>> but not Morphic. I remember seeing plans to make the change, but >>>> nothing after that. The view instances provide a natural place to fix >>>> things, so I took the plunge. If we switch to some other graphical >>>> realization, we can simply remove the the transformation. >>>> >>>> Are the existing splitters as strange as SystemWindow? By that I mean, >>>> would it be reasonable to add them between other morphs and look for >>>> events from them, or will they have to be replaced? I will eventually >>>> need splitters, but I could initially live without them if I can get >>>> reliable composition where I need it. >>>> >>>> There are very few view classes at present. MorphView can wrap almost >>>> anything, so it might be better to create a rich set of presenters >>>> instead. Dolphin's view resources are going to be interesting to >>>> replace. There are some complexities that I suspect are in deference to >>>> Windows, and some that might be avoidable. For our purposes, it might >>>> be enough to use SIXX to serialize a bunch of message sends and gzip >>>> the >>>> results to save memory. Another option might be to rely on class >>>> methods; having full closures won't hurt; they might allow sufficient >>>> hooking that resources in the Dolphin sense won't even be necessary. >>>> The desire for them quickly arises because views get realized in places >>>> know nothing about how the views should be configured; at least I think >>>> that is what happened to me after just a couple of hours. I am far >>>> less >>>> interested in having a graphical view editor than I am in being able to >>>> write **GOOD** code that assembles things as I want. If the result >>>> happens to allow a graphical editor too, so much the better. >>>> >>>> Any interest? >>>> >>>> Bill >>>> >>>> >>>> ----------------------------- >>>> >>>> View >>>> MorphViev >>>> ImageView >>>> ContainerView >>>> >>>> ViewGadgetLayoutAbstract >>>> ScrollerGadgetLayout >>>> NullViewGadgetLayout >>>> FixedStretchFixedGadgetLayout >>>> ProportionalGadgetLayout >>>> PreferredExtentsGadgetLayout >>>> GridGadgetRowsLayout >>>> VerticalListLayout >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 10, 2010

Re: [Pharo-project] Early days of an MVP framework

by Gary Chambers

Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, August 09, 2010 11:05 PM Subject: Re: [Pharo-project] Early days of an MVP framework > Gary, > > Thanks for the examples. One thing is driving me nuts: in the past, I > thought that creating a new row or column made a morph but did not add it > to the morph being created. Might I have added them redundantly? Does > re-adding a child have no effect or somehow replace it? Is this a > morphi/Polymorph beginner trap? Be honest, I can take it :) > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary > Chambers > Sent: Monday, August 09, 2010 5:45 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Early days of an MVP framework > > And with a stack layout... > > (UITheme builder > newColumn: { > UITheme builder newTabGroup: { > 'First page' -> ((UITheme builder newStack: { > (UITheme builder > newAlphaImage: UITheme current warningIcon > help: nil) > alpha: 0.5. > CircleMorph new > hResizing: #spaceFill; > vResizing: #spaceFill}) > fillStyle: Color red; > hResizing: #spaceFill; > vResizing: #spaceFill). > 'Second page' -> (UITheme builder newPanel > fillStyle: Color green; > hResizing: #spaceFill; > vResizing: #spaceFill)}. > (UITheme builder newRow: { > UITheme builder newOKButton. > UITheme builder newCancelButton}) > listCentering: #bottomRight}) > extent: 200@300; > openInWindow > > Regards, Gary > > ----- Original Message ----- > From: "Gary Chambers" <gazzaguru2(a)btinternet.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, August 09, 2010 11:30 AM > Subject: Re: [Pharo-project] Early days of an MVP framework > > >> This even (to get buttons on right with correct tab key navigation >> ordering... >> >> (UITheme builder >> newColumn: { >> UITheme builder newTabGroup: { >> 'First page' -> (UITheme builder newPanel >> fillStyle: Color red; >> hResizing: #spaceFill; >> vResizing: #spaceFill). >> 'Second page' -> (UITheme builder newPanel >> fillStyle: Color green; >> hResizing: #spaceFill; >> vResizing: #spaceFill)}. >> (UITheme builder newRow: { >> UITheme builder newOKButton. >> UITheme builder newCancelButton}) >> listCentering: #bottomRight}) >> extent: 200@300; >> openInWindow >> >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Gary Chambers" <gazzaguru2(a)btinternet.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Monday, August 09, 2010 11:07 AM >> Subject: Re: [Pharo-project] Early days of an MVP framework >> >> >>> Any Morph can use a layoutPolicy. >>> Available are >>> none (position based) >>> Prorportional (frame/fractions/offsets) >>> Table (overly complex too) >>> Row (one of mine, quicker for simple rows) >>> Stack (mine, overlay morphs on top of each other) >>> >>> TEasilyThemed provides some methods like... >>> >>> newRow: {aMorph, anotherMorph} >>> newColumn: >>> >>> Something like this works... >>> >>> (UITheme builder >>> newColumn: { >>> UITheme builder newPanel >>> fillStyle: Color red; >>> hResizing: #spaceFill; >>> vResizing: #spaceFill. >>> UITheme builder newRow: { >>> UITheme builder newOKButton. >>> UITheme builder newCancelButton}}) >>> extent: 200@300; >>> openInHand >>> >>> (can use openInWindow also)... >>> >>> Rather busy today, hope this helps in the meantime... >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> >>> To: <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Sunday, August 08, 2010 11:46 PM >>> Subject: [Pharo-project] Early days of an MVP framework >>> >>> >>>> Gary, >>>> >>>> I was on an unstoppable roll (salvaged early on by Andreas' bitblt >>>> coaching), until I needed to repeat a "complex" GUI component and >>>> wanted/insisted on doing so with some reuse. Seaside gives us >>>> components on web pages; we need them for GUI code too. I tried >>>> turning >>>> my presenter-like structures into factories that would add morphs to a >>>> single shell, but it fell apart when it came time to set the framing >>>> values. I was not particularly interested in fixing it, because if I >>>> could do that, I would simply build proper composite widgets using the >>>> fix. >>>> >>>> The problem appears to be in SystemWindow, which does some incredibly >>>> complicated things, all of which (correct me if I am wrong) would be >>>> unnecessary if only there were a good set of layout managers. I can >>>> get >>>> very simple-minded about things, but it would make a whole lot more >>>> sense to me to create rows and columns of widgets, adding splitters >>>> between them until the whole things behaves as intended, rather than >>>> writing code (present only in a top-level shell) that tries to split >>>> things up into rows using its own judgment. Not good. I realize you >>>> did not create the situation, and have done wonders to make it work far >>>> better than when you found it. >>>> >>>> Some time ago, I built an emulated widget framework for Dolphin, which >>>> I >>>> needed because the combination of Dolphin's view resources and Windows >>>> itself was too slow for what I was trying to do. That project included >>>> a somewhat strange set of layout classes, but the basics are present, >>>> and it is not Object Arts' IP. I ported the classes to Pharo and did >>>> some work on stub View and Presenter classes that I had added to Pharo >>>> largely to passify my code that I was importing from Dolphin. The >>>> layouts think in terms of emulated widgets, and I see no reason to >>>> change their minds: I might want to replicate the framework. However, >>>> dynamic typing and a couple of extra methods allow them to work with >>>> just about anything. My goals are modest. Being able to compose rows >>>> and columns would do a lot for me. Add splitters and the ability to >>>> fix >>>> the size of some items, and I could almost anything I would need. >>>> >>>> View class>>example >>>> | row column dot square out shell | >>>> dot := ( Form dotOfSize:100 ) asFormOfDepth:32. >>>> square := ( Form squareOfSize:100 ) asFormOfDepth:32. >>>> out := Array writeStream. >>>> >>>> row := ContainerView row. >>>> 2 timesRepeat:[ >>>> column := row addSubview:ContainerView column. >>>> 2 timesRepeat:[ >>>> out nextPut:( >>>> column addSubview:ImageView new >>>> ). >>>> ]. >>>> ]. >>>> >>>> out contents with:{ dot copy. square copy. square copy. dot copy. } >>>> do:[ :view :form | >>>> view morph image:form. >>>> ]. >>>> >>>> row rectangle:( 0@0 extent:400@400 ). >>>> row layout. >>>> >>>> shell := StandardWindow labelled:'Hello MVP'. >>>> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself. >>>> >>>> >>>> The above code produces an array of dots and squares, as intended. One >>>> quirk is that the grid does not resize as the shell resizes, a >>>> consequence of my not having hooked it up to resize events. I might >>>> get >>>> some interesting meltdowns once I begin to do that =:0 I used your >>>> PanelMorph as the "view" associated with ContainerView. What, >>>> ContainView isn't a view??? No. The code is biased toward Morphic, >>>> but >>>> hopefully the same code should extend to wx, GTK, etc. Dolphin's views >>>> have a handle instance variable to control the external resource; these >>>> views have an instance variable pointing to their morph. Handling of >>>> sub views works pretty much as in Dolphin: any view/morph can have >>>> children, but adding them is "legal" only for composites. >>>> >>>> Most systems I have seen treat coordinates relative to the >>>> parent/owner, >>>> but not Morphic. I remember seeing plans to make the change, but >>>> nothing after that. The view instances provide a natural place to fix >>>> things, so I took the plunge. If we switch to some other graphical >>>> realization, we can simply remove the the transformation. >>>> >>>> Are the existing splitters as strange as SystemWindow? By that I mean, >>>> would it be reasonable to add them between other morphs and look for >>>> events from them, or will they have to be replaced? I will eventually >>>> need splitters, but I could initially live without them if I can get >>>> reliable composition where I need it. >>>> >>>> There are very few view classes at present. MorphView can wrap almost >>>> anything, so it might be better to create a rich set of presenters >>>> instead. Dolphin's view resources are going to be interesting to >>>> replace. There are some complexities that I suspect are in deference to >>>> Windows, and some that might be avoidable. For our purposes, it might >>>> be enough to use SIXX to serialize a bunch of message sends and gzip >>>> the >>>> results to save memory. Another option might be to rely on class >>>> methods; having full closures won't hurt; they might allow sufficient >>>> hooking that resources in the Dolphin sense won't even be necessary. >>>> The desire for them quickly arises because views get realized in places >>>> know nothing about how the views should be configured; at least I think >>>> that is what happened to me after just a couple of hours. I am far >>>> less >>>> interested in having a graphical view editor than I am in being able to >>>> write **GOOD** code that assembles things as I want. If the result >>>> happens to allow a graphical editor too, so much the better. >>>> >>>> Any interest? >>>> >>>> Bill >>>> >>>> >>>> ----------------------------- >>>> >>>> View >>>> MorphViev >>>> ImageView >>>> ContainerView >>>> >>>> ViewGadgetLayoutAbstract >>>> ScrollerGadgetLayout >>>> NullViewGadgetLayout >>>> FixedStretchFixedGadgetLayout >>>> ProportionalGadgetLayout >>>> PreferredExtentsGadgetLayout >>>> GridGadgetRowsLayout >>>> VerticalListLayout >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 10, 2010