[Pharo-project] GUI Polymorph
Hello, Here is some documentation about Polymoprh programming http://book.pharo-project.org/book/GUI/TypicalPolymorphApplication Comments and English checking welcome. Hilaire
Hilaire, This is great! I am starting to see light (albeit still dim) at the end of a couple of tunnels. One thing I am thinking of doing to Painter is to make it draw line segments from "the" previous point to the current point, which clearly requires some special handling for the first point of any stroke. Do you make any attempt to optimize drawing? If so, I am missing it, but the performance is reasonable enough that it seems hard to believe that it replaces the entire form with each stroke?? For very complex graphics, it would be nice to have a form, alter small pieces of it, and then transfer only the modified portion to the display. Is that happening now? If not, what would be required to do it? Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Hilaire Fernandes Sent: Thursday, June 10, 2010 10:11 AM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] GUI Polymorph Hello, Here is some documentation about Polymoprh programming http://book.pharo-project.org/book/GUI/TypicalPolymorphApplication Comments and English checking welcome. Hilaire _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thu, Jun 10, 2010 at 5:11 PM, Hilaire Fernandes < hilaire.fernandes@gmail.com> wrote:
Hello,
Here is some documentation about Polymoprh programming
http://book.pharo-project.org/book/GUI/TypicalPolymorphApplication
Comments and English checking welcome.
Hi Hilaire, at Pharo sprint in Bern, Doru explained me that we should avoid setting header with ! like !Installing the components as it's hardly translated to Latex. It's better to create subsections. Cheers, Laurent.
Hilaire
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Laurent, great work! We need more documentation! Just a little coding style i would like to point out. I see you are using lazy initialization, but in this case i believe its a miss-use of the pattern. Because you always will have a toolbar and a menu bar, since the creation you are sure you need them, why not go and just initialize them before installing. Let me know what you think. So i propose changing the implementation to : initialize super initialize. self initializeMenuBar. self initializeToolbar. .... and initializeMenuBar | menu | menu := self window newMenu. menu addToggle: 'Load' target: self selector: #load. menu addToggle: 'Save' target: self selector: #save. menubar := self window newToolDockingBar. menubar add: 'File' font: self window theme menuBarFont icon: nil help: 'File operations' subMenu: menu.
2010/6/11 Fernando olivero <oliverof@lu.unisi.ch>
Hi Laurent, great work! We need more documentation!
Laurent -> Hilaire :)
Just a little coding style i would like to point out.
I see you are using lazy initialization, but in this case i believe its a miss-use of the pattern. Because you always will have a toolbar and a menu bar, since the creation you are sure you need them, why not go and just initialize them before installing.
Let me know what you think.
So i propose changing the implementation to :
initialize super initialize. self initializeMenuBar. self initializeToolbar. ....
and
initializeMenuBar | menu | menu := self window newMenu. menu addToggle: 'Load' target: self selector: #load. menu addToggle: 'Save' target: self selector: #save. menubar := self window newToolDockingBar. menubar add: 'File' font: self window theme menuBarFont icon: nil help: 'File operations' subMenu: menu.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Fernando, Sure we can be more optimal in execution term, but it is not my objective. I want the example to be concise and optimal under this term, so smaller then may be easier to catch. Bill, Yes, you can draw segment. Yes you can optimze but it is not the purpose of the documentation. I try to optimize the documentation to its target: get started with GUI programming with Polymorph, and let the reader enjoy. Please consider proposing, additional advanced chapter in the CollaborActive book for some idea about optimization GUI. I will be really happy to read, to learn and to comment on that. Laurent, I removed the heading sections and replace it with Bold style. Thanks for your feedback. Hilaire Fernando olivero a écrit :
Hi Laurent, great work! We need more documentation!
Just a little coding style i would like to point out.
I see you are using lazy initialization, but in this case i believe its a miss-use of the pattern. Because you always will have a toolbar and a menu bar, since the creation you are sure you need them, why not go and just initialize them before installing.
Let me know what you think.
So i propose changing the implementation to :
initialize super initialize. self initializeMenuBar. self initializeToolbar. ....
and
initializeMenuBar | menu | menu := self window newMenu. menu addToggle: 'Load' target: self selector: #load. menu addToggle: 'Save' target: self selector: #save. menubar := self window newToolDockingBar. menubar add: 'File' font: self window theme menuBarFont icon: nil help: 'File operations' subMenu: menu.
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hilaire, It was interesting to watch MS' position on GUI examples change over time. Visual C++ started out teaching how to create efficient software. Then one day those examples were gone and all they could talk about was "smooth scrolling" which turned out to be a way to make the machine do the inefficient thing four times instead of once. The idea of altering the model, finding out what is invalidated, marking that as closely as can be done within bounds of common sense (or until diminishing returns), and then drawing just the changed parts is non-intuitive and VERY important. You have done a wonderful job so far, but optimization deserves attention. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Hilaire Fernandes Sent: Friday, June 11, 2010 7:04 AM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] GUI Polymorph Hi Fernando, Sure we can be more optimal in execution term, but it is not my objective. I want the example to be concise and optimal under this term, so smaller then may be easier to catch. Bill, Yes, you can draw segment. Yes you can optimze but it is not the purpose of the documentation. I try to optimize the documentation to its target: get started with GUI programming with Polymorph, and let the reader enjoy. Please consider proposing, additional advanced chapter in the CollaborActive book for some idea about optimization GUI. I will be really happy to read, to learn and to comment on that. Laurent, I removed the heading sections and replace it with Bold style. Thanks for your feedback. Hilaire Fernando olivero a écrit :
Hi Laurent, great work! We need more documentation!
Just a little coding style i would like to point out.
I see you are using lazy initialization, but in this case i believe its a miss-use of the pattern. Because you always will have a toolbar and a menu bar, since the creation you are sure you need them, why not go and just initialize them before installing.
Let me know what you think.
So i propose changing the implementation to :
initialize super initialize. self initializeMenuBar. self initializeToolbar. ....
and
initializeMenuBar | menu | menu := self window newMenu. menu addToggle: 'Load' target: self selector: #load. menu addToggle: 'Save' target: self selector: #save. menubar := self window newToolDockingBar. menubar add: 'File' font: self window theme menuBarFont icon: nil help: 'File operations' subMenu: menu.
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Schwab,Wilhelm K a écrit :
Hilaire,
It was interesting to watch MS' position on GUI examples change over time. Visual C++ started out teaching how to create efficient software. Then one day those examples were gone and all they could talk about was "smooth scrolling" which turned out to be a way to make the machine do the inefficient thing four times instead of once.
The idea of altering the model, finding out what is invalidated, marking that as closely as can be done within bounds of common sense (or until diminishing returns), and then drawing just the changed parts is non-intuitive and VERY important. You have done a wonderful job so far, but optimization deserves attention.
Please fell free to search and to document it. As I wrote in my previous email, my objective writing this documentation was not how to efficiently implement a paint canvas. Hilaire
Hilaire, I will indeed consider it, but it will take me time to get to your level of understanding of Polymorph. My priorities are networking, serial communications, printing (which I am dreading) and then finally GUI construction. The last two are backwards, but the GUI does me no good if I can't print on Linux. Somewhere in there I hope to pull a big thorn out of my foot by moving various machines to Linux. With a working GUI+printing, the rest of the boxes go to Linux, and the drinks are on me :) Understood about your objectives, but I think they SHOULD include teaching efficient updates. When MS did this correctly, they did the simplest thing that would work, and then separately modified it for efficiency. Smalltalk is not the fastest language in existence, Pharo is not the fastest among its peers, and even if it were, we should be doing things better and more efficiently than the rest of the world. It is nuts that we need 2GB of RAM to boot an OS and read email; while that sloppiness arguably begins in Redmond, it can be attenuated here. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Hilaire Fernandes [hilaire.fernandes@gmail.com] Sent: Friday, June 11, 2010 9:46 AM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] GUI Polymorph Schwab,Wilhelm K a écrit :
Hilaire,
It was interesting to watch MS' position on GUI examples change over time. Visual C++ started out teaching how to create efficient software. Then one day those examples were gone and all they could talk about was "smooth scrolling" which turned out to be a way to make the machine do the inefficient thing four times instead of once.
The idea of altering the model, finding out what is invalidated, marking that as closely as can be done within bounds of common sense (or until diminishing returns), and then drawing just the changed parts is non-intuitive and VERY important. You have done a wonderful job so far, but optimization deserves attention.
Please fell free to search and to document it. As I wrote in my previous email, my objective writing this documentation was not how to efficiently implement a paint canvas. Hilaire _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Take a look at Morph>>invalidRect: as opposed to #changed for more optimal screen updates if required ;-) Nice job on the tutorial Hilaire btw. Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr> Sent: Friday, June 11, 2010 2:59 PM Subject: Re: [Pharo-project] GUI Polymorph Hilaire, I will indeed consider it, but it will take me time to get to your level of understanding of Polymorph. My priorities are networking, serial communications, printing (which I am dreading) and then finally GUI construction. The last two are backwards, but the GUI does me no good if I can't print on Linux. Somewhere in there I hope to pull a big thorn out of my foot by moving various machines to Linux. With a working GUI+printing, the rest of the boxes go to Linux, and the drinks are on me :) Understood about your objectives, but I think they SHOULD include teaching efficient updates. When MS did this correctly, they did the simplest thing that would work, and then separately modified it for efficiency. Smalltalk is not the fastest language in existence, Pharo is not the fastest among its peers, and even if it were, we should be doing things better and more efficiently than the rest of the world. It is nuts that we need 2GB of RAM to boot an OS and read email; while that sloppiness arguably begins in Redmond, it can be attenuated here. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Hilaire Fernandes [hilaire.fernandes@gmail.com] Sent: Friday, June 11, 2010 9:46 AM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] GUI Polymorph Schwab,Wilhelm K a écrit :
Hilaire,
It was interesting to watch MS' position on GUI examples change over time. Visual C++ started out teaching how to create efficient software. Then one day those examples were gone and all they could talk about was "smooth scrolling" which turned out to be a way to make the machine do the inefficient thing four times instead of once.
The idea of altering the model, finding out what is invalidated, marking that as closely as can be done within bounds of common sense (or until diminishing returns), and then drawing just the changed parts is non-intuitive and VERY important. You have done a wonderful job so far, but optimization deserves attention.
Please fell free to search and to document it. As I wrote in my previous email, my objective writing this documentation was not how to efficiently implement a paint canvas. Hilaire _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Gary, That's great to know! There are natural questions, such as whether the rectangle is in screen or morph-relative coordinates (I fear the former), and how to get the same information when rendering (to allow non-visible objects to be skipped), but I'm guessing those answers will flow from browsing beginning with #invalidRect:. At the last steps of this journey, I'm going to need every clock cycle I can get :( Thanks! Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers [gazzaguru2@btinternet.com] Sent: Friday, June 11, 2010 10:47 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] GUI Polymorph Take a look at Morph>>invalidRect: as opposed to #changed for more optimal screen updates if required ;-) Nice job on the tutorial Hilaire btw. Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr> Sent: Friday, June 11, 2010 2:59 PM Subject: Re: [Pharo-project] GUI Polymorph Hilaire, I will indeed consider it, but it will take me time to get to your level of understanding of Polymorph. My priorities are networking, serial communications, printing (which I am dreading) and then finally GUI construction. The last two are backwards, but the GUI does me no good if I can't print on Linux. Somewhere in there I hope to pull a big thorn out of my foot by moving various machines to Linux. With a working GUI+printing, the rest of the boxes go to Linux, and the drinks are on me :) Understood about your objectives, but I think they SHOULD include teaching efficient updates. When MS did this correctly, they did the simplest thing that would work, and then separately modified it for efficiency. Smalltalk is not the fastest language in existence, Pharo is not the fastest among its peers, and even if it were, we should be doing things better and more efficiently than the rest of the world. It is nuts that we need 2GB of RAM to boot an OS and read email; while that sloppiness arguably begins in Redmond, it can be attenuated here. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Hilaire Fernandes [hilaire.fernandes@gmail.com] Sent: Friday, June 11, 2010 9:46 AM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] GUI Polymorph Schwab,Wilhelm K a écrit :
Hilaire,
It was interesting to watch MS' position on GUI examples change over time. Visual C++ started out teaching how to create efficient software. Then one day those examples were gone and all they could talk about was "smooth scrolling" which turned out to be a way to make the machine do the inefficient thing four times instead of once.
The idea of altering the model, finding out what is invalidated, marking that as closely as can be done within bounds of common sense (or until diminishing returns), and then drawing just the changed parts is non-intuitive and VERY important. You have done a wonderful job so far, but optimization deserves attention.
Please fell free to search and to document it. As I wrote in my previous email, my objective writing this documentation was not how to efficiently implement a paint canvas. Hilaire _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jun 11, 2010, at 2:04 PM, Hilaire Fernandes wrote:
Hi Fernando,
Sure we can be more optimal in execution term, but it is not my objective. I want the example to be concise and optimal under this term, so smaller then may be easier to catch.
Hi Hilarie, i was not speaking of optimization. Just pointing out the miss use of the pattern , conceptually. Which i think when writing tutorials is important. Lazy initialization is conceptually used when the internal collaborator is hard to initialize and maybe would never be used. Which is not the case with the window, toolbar, etc Please don't take the wrong way, just wanted to point out the design problem. I think you have done a great work by coding a tutorial, which i found very useful for building a Gaucho control panel for the next version. Fernando
Hilaire
Fernando olivero a écrit :
Hi Laurent, great work! We need more documentation!
Just a little coding style i would like to point out.
I see you are using lazy initialization, but in this case i believe its a miss-use of the pattern. Because you always will have a toolbar and a menu bar, since the creation you are sure you need them, why not go and just initialize them before installing.
Let me know what you think.
So i propose changing the implementation to :
initialize super initialize. self initializeMenuBar. self initializeToolbar. ....
and
initializeMenuBar | menu | menu := self window newMenu. menu addToggle: 'Load' target: self selector: #load. menu addToggle: 'Save' target: self selector: #save. menubar := self window newToolDockingBar. menubar add: 'File' font: self window theme menuBarFont icon: nil help: 'File operations' subMenu: menu.
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
It is fine. Even miss used, I found lazy initialization comfortable. Please consider adding a nice comment in the documentation about the lazy initialisation pattern, external link will be nice as well. I am sure it will be use full. Hilaire Fernando olivero a écrit :
Please don't take the wrong way, just wanted to point out the design problem. I think you have done a great work by coding a tutorial, which i found very useful for building a Gaucho control panel for the next version.
participants (5)
-
Fernando olivero -
Gary Chambers -
Hilaire Fernandes -
laurent laffont -
Schwab,Wilhelm K