GUI Polymorph
Locked
 
|
CONTENTS DELETED
The author has deleted this message.
|
|
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: [hidden email] [mailto:[hidden email]] On Behalf Of Hilaire Fernandes Sent: Thursday, June 10, 2010 10:11 AM To: [hidden email] 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by hilaire
On Thu, Jun 10, 2010 at 5:11 PM, Hilaire Fernandes <[hidden email]> wrote: Hello, 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.
_______________________________________________ Pharo-project mailing list [hidden email] 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. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2010/6/11 Fernando olivero <[hidden email]>
Laurent -> Hilaire :)
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Fernando olivero
CONTENTS DELETED
The author has deleted this message.
|
|
|
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: [hidden email] [mailto:[hidden email]] On Behalf Of Hilaire Fernandes Sent: Friday, June 11, 2010 7:04 AM To: [hidden email] 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
CONTENTS DELETED
The author has deleted this message.
|
|
|
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: [hidden email] [[hidden email]] On Behalf Of Hilaire Fernandes [[hidden email]] Sent: Friday, June 11, 2010 9:46 AM To: [hidden email] 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] 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" <[hidden email]> To: <[hidden email]> 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: [hidden email] [[hidden email]] On Behalf Of Hilaire Fernandes [[hidden email]] Sent: Friday, June 11, 2010 9:46 AM To: [hidden email] 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] 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: [hidden email] [[hidden email]] On Behalf Of Gary Chambers [[hidden email]] Sent: Friday, June 11, 2010 10:47 AM To: [hidden email] 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" <[hidden email]> To: <[hidden email]> 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: [hidden email] [[hidden email]] On Behalf Of Hilaire Fernandes [[hidden email]] Sent: Friday, June 11, 2010 9:46 AM To: [hidden email] 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
Administrator
|
In reply to this post by hilaire
> 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. +1 for having both: * simple, intuitive * and optimized And for keeping them separate. Like "this is how you would use the beautiful expressiveness of Smalltalk to do it first, and this is how you'd optimize it after profiling showed it was too slow." Sean p.s. Loving all this documentation!!! Wish it was there when I started ;-) _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Cheers,
Sean |
Re: GUI Polymorph: lazy initialization
|
|
In reply to this post by hilaire
On Jun 11, 2010, at 2:04 PM, Hilaire Fernandes wrote:
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
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |