[Pharo-project] Toward MVP: SimpleGridExample vs. ClassListExample, etc.
I have a couple of GUIs to create, and took another look at my (very) slowly evolving MVP package. A small update appears below, but the question of the day is one of performance of MorphTreeMorph in its various incarnations. ClassListExample is very impressive and reasonably quick. SimpleGridExample is very nice, but quite slow. Profiling its opening reveals that it spends a lot of time making morphs, but that's not super surprising. It's the total time that is of concern. Any takers on why? I ask, because I am trying to create basic presenter classes for lists, trees, (more or less working), text (will be easy - I *think*), and another big item is multi-column lists. My objective is to be able to easily construct things that (unless told to do otherwise) automatically deal with the selected index, updates, etc. None of this stuff is terribly difficult to do when following the Polymorph examples, PharoCasts, etc., but hopefully we can have MVP and stop repeating ourselves at the same time. The next thing I am missing is a grid. Any strong thoughts on examples to follow/reuse, or things that should NOT be used for any reason? Bill
On Jun 4, 2011, at 6:08 PM, Schwab,Wilhelm K wrote:
I have a couple of GUIs to create, and took another look at my (very) slowly evolving MVP package. A small update appears below, but the question of the day is one of performance of MorphTreeMorph in its various incarnations.
ClassListExample is very impressive and reasonably quick. SimpleGridExample is very nice, but quite slow. Profiling its opening reveals that it spends a lot of time making morphs, but that's not super surprising. It's the total time that is of concern. Any takers on why?
did you check on 1.3 because igor and ben spent some time optimizing it a bit.
I ask, because I am trying to create basic presenter classes for lists, trees, (more or less working), text (will be easy - I *think*), and another big item is multi-column lists. My objective is to be able to easily construct things that (unless told to do otherwise) automatically deal with the selected index, updates, etc. None of this stuff is terribly difficult to do when following the Polymorph examples, PharoCasts, etc., but hopefully we can have MVP and stop repeating ourselves at the same time.
I'm interested in that MVP framework. Do you have some code somewhere? With igor we discussed about killing pluggable.... but for now one step at the time.
The next thing I am missing is a grid. Any strong thoughts on examples to follow/reuse, or things that should NOT be used for any reason?
did you check HPI library or void nullpointer widgets? I would love to have a gorup of people pushing that.
Bill
Stef, Thanks for the homework assignments :) I have not specifically looked at simple grid in 1.3, but I will do so - gotta go for a run first. My MVP code is not yet available, but I intend to release it once it is remotely worth having. I was pleasantly surprised to find more than I thought I had working. Maybe I should soon put a "first draft" where people can see it. The design (if that word applies<g>) is a compromise between Dolphin's approach to GUIs where it makes sense to follow them, realizing that the Dolphin view composer isn't here, some "going along with the flow" where Polymorph makes things too easy to ignore, and finally some Seaside influence. Dolphin uses a GUI to assemble views. I am planning to do that with code, but ultimately that should not be forced. It will take some time to balance all of that.
did you check HPI library or void nullpointer widgets?
I am not familiar with them, but I will look. I suspect I am finding smoke screens on HPI, but the null pointer widgets look like I found what you have in mind. It looks like you are "thinking big," which is great. I am not a big believer that native widgets equate to speed, but, there are times when some native code goes a LONG way in that direction. I would like to see us able to use one native window per tool shell, if not be able to go completely native. I think it would be painful, but ultimately good for us. Short term, I am not so much thinking of replacing the GUI (though my stuff would hopefully run on top of any widgets - with some work) as I am with reducing the redundant work that goes in to a GUI, and moving us toward MVP. The latter is for two reasons: (1) it is a nice framework; (2) I have a lot of old code that I would like to see have a home on Linux. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, June 04, 2011 12:23 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Toward MVP: SimpleGridExample vs. ClassListExample, etc. On Jun 4, 2011, at 6:08 PM, Schwab,Wilhelm K wrote:
I have a couple of GUIs to create, and took another look at my (very) slowly evolving MVP package. A small update appears below, but the question of the day is one of performance of MorphTreeMorph in its various incarnations.
ClassListExample is very impressive and reasonably quick. SimpleGridExample is very nice, but quite slow. Profiling its opening reveals that it spends a lot of time making morphs, but that's not super surprising. It's the total time that is of concern. Any takers on why?
did you check on 1.3 because igor and ben spent some time optimizing it a bit.
I ask, because I am trying to create basic presenter classes for lists, trees, (more or less working), text (will be easy - I *think*), and another big item is multi-column lists. My objective is to be able to easily construct things that (unless told to do otherwise) automatically deal with the selected index, updates, etc. None of this stuff is terribly difficult to do when following the Polymorph examples, PharoCasts, etc., but hopefully we can have MVP and stop repeating ourselves at the same time.
I'm interested in that MVP framework. Do you have some code somewhere? With igor we discussed about killing pluggable.... but for now one step at the time.
The next thing I am missing is a grid. Any strong thoughts on examples to follow/reuse, or things that should NOT be used for any reason?
did you check HPI library or void nullpointer widgets? I would love to have a gorup of people pushing that.
Bill
On Jun 4, 2011, at 6:55 PM, Schwab,Wilhelm K wrote:
Stef,
Thanks for the homework assignments :)
I have not specifically looked at simple grid in 1.3, but I will do so - gotta go for a run first.
My MVP code is not yet available, but I intend to release it once it is remotely worth having. I was pleasantly surprised to find more than I thought I had working. Maybe I should soon put a "first draft" where people can see it.
yes please do :)
The design (if that word applies<g>) is a compromise between Dolphin's approach to GUIs where it makes sense to follow them, realizing that the Dolphin view composer isn't here, some "going along with the flow" where Polymorph makes things too easy to ignore, and finally some Seaside influence.
Dolphin uses a GUI to assemble views. I am planning to do that with code, but ultimately that should not be forced. It will take some time to balance all of that.
did you check HPI library or void nullpointer widgets?
I am not familiar with them, but I will look. I suspect I am finding smoke screens on HPI,
I think that they have some nice widgets to get inspired from.
but the null pointer widgets look like I found what you have in mind. It looks like you are "thinking big," which is great. I am not a big believer that native widgets equate to speed, but, there are times when some native code goes a LONG way in that direction. I would like to see us able to use one native window per tool shell, if not be able to go completely native. I think it would be painful, but ultimately good for us.
I'm not talking about native. just getting some good foundation.
Short term, I am not so much thinking of replacing the GUI (though my stuff would hopefully run on top of any widgets - with some work) as I am with reducing the redundant work that goes in to a GUI, and moving us toward MVP. The latter is for two reasons: (1) it is a nice framework; (2) I have a lot of old code that I would like to see have a home on Linux.
yes work on it and let us see it.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, June 04, 2011 12:23 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Toward MVP: SimpleGridExample vs. ClassListExample, etc.
On Jun 4, 2011, at 6:08 PM, Schwab,Wilhelm K wrote:
I have a couple of GUIs to create, and took another look at my (very) slowly evolving MVP package. A small update appears below, but the question of the day is one of performance of MorphTreeMorph in its various incarnations.
ClassListExample is very impressive and reasonably quick. SimpleGridExample is very nice, but quite slow. Profiling its opening reveals that it spends a lot of time making morphs, but that's not super surprising. It's the total time that is of concern. Any takers on why?
did you check on 1.3 because igor and ben spent some time optimizing it a bit.
I ask, because I am trying to create basic presenter classes for lists, trees, (more or less working), text (will be easy - I *think*), and another big item is multi-column lists. My objective is to be able to easily construct things that (unless told to do otherwise) automatically deal with the selected index, updates, etc. None of this stuff is terribly difficult to do when following the Polymorph examples, PharoCasts, etc., but hopefully we can have MVP and stop repeating ourselves at the same time.
I'm interested in that MVP framework. Do you have some code somewhere?
With igor we discussed about killing pluggable.... but for now one step at the time.
The next thing I am missing is a grid. Any strong thoughts on examples to follow/reuse, or things that should NOT be used for any reason?
did you check HPI library or void nullpointer widgets?
I would love to have a gorup of people pushing that.
Bill
yes, it is slow. the idea would be to build the list in background. you can try the lazy version also. LazyMorphTreeMorph. a row is built only when it is visible. Cheers Alain Le 04/06/2011 18:08, Schwab,Wilhelm K a écrit :
I have a couple of GUIs to create, and took another look at my (very) slowly evolving MVP package. A small update appears below, but the question of the day is one of performance of MorphTreeMorph in its various incarnations.
ClassListExample is very impressive and reasonably quick. SimpleGridExample is very nice, but quite slow. Profiling its opening reveals that it spends a lot of time making morphs, but that's not super surprising. It's the total time that is of concern. Any takers on why?
I ask, because I am trying to create basic presenter classes for lists, trees, (more or less working), text (will be easy - I *think*), and another big item is multi-column lists. My objective is to be able to easily construct things that (unless told to do otherwise) automatically deal with the selected index, updates, etc. None of this stuff is terribly difficult to do when following the Polymorph examples, PharoCasts, etc., but hopefully we can have MVP and stop repeating ourselves at the same time.
The next thing I am missing is a grid. Any strong thoughts on examples to follow/reuse, or things that should NOT be used for any reason?
Bill
Alain, Stef might be correct about it being better in 1.3. In fairness, the Hudson 1.3 image is not as big as my 1.1.1 working image, so the comparison might have some flaws. The class examples are paginated, deferring some work. There is a separate LazyClassListExample; it seems to work properly, and the only change that I see relative to ClassListExample is its use of LazyMorphTreeMorph. Making that same substitution for SimpleGridMorph produces weird side effects ("extra morphs" created on some rows) in 1.3. In 1.1.1, the window opens quickly, but is ultimately sluggish until all morphs are created. The latter is not terribly surprising, but one could hope for 1.3's speed with 1.1.1's stability :) Getting back to my MVP focus, I note that MorphTreeMorph is both slower than Dolphin's enhanced (multi-column) lists, and also more powerful. It has a lot in common with the lists in the PaneHolders package that I created for Dolphin (with some additions and omissions). As non-oo as it might be, there is arguably room for a text-only grid that is very fast. Whether Object Arts put it in Dolphin "because it was there" in Windows, because they knew it would a good compromise, or somewhere in between is open for discussion. Regardless, it is a useful widget. Maybe PluggableMultiColumnListMorph is where I should start for the short term?? Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alain Plantec [alain.plantec@yahoo.com] Sent: Saturday, June 04, 2011 12:46 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Toward MVP: SimpleGridExample vs. ClassListExample, etc. yes, it is slow. the idea would be to build the list in background. you can try the lazy version also. LazyMorphTreeMorph. a row is built only when it is visible. Cheers Alain Le 04/06/2011 18:08, Schwab,Wilhelm K a écrit :
I have a couple of GUIs to create, and took another look at my (very) slowly evolving MVP package. A small update appears below, but the question of the day is one of performance of MorphTreeMorph in its various incarnations.
ClassListExample is very impressive and reasonably quick. SimpleGridExample is very nice, but quite slow. Profiling its opening reveals that it spends a lot of time making morphs, but that's not super surprising. It's the total time that is of concern. Any takers on why?
I ask, because I am trying to create basic presenter classes for lists, trees, (more or less working), text (will be easy - I *think*), and another big item is multi-column lists. My objective is to be able to easily construct things that (unless told to do otherwise) automatically deal with the selected index, updates, etc. None of this stuff is terribly difficult to do when following the Polymorph examples, PharoCasts, etc., but hopefully we can have MVP and stop repeating ourselves at the same time.
The next thing I am missing is a grid. Any strong thoughts on examples to follow/reuse, or things that should NOT be used for any reason?
Bill
Hi Bill, thanks for your feedbacks! Le 06/06/2011 01:11, Schwab,Wilhelm K a écrit :
Maybe PluggableMultiColumnListMorph is where I should start for the short term??
yes. Cheers Alain
Bill
participants (3)
-
Alain Plantec -
Schwab,Wilhelm K -
Stéphane Ducasse