Attached is code to produce something I need. It shows a list of items; click one and the text goes into the box below the list. The user can also type into that box; there is no sense of responsibility about saving the user's work. The mind set is that the list provides most things of interest, and it should be possible to "say anything" just in case. Click the button, and the text in the bottom field goes into a log file, complete with time stamp. It's not big deal, but neither should be creating it. Start with a model: EventLogger>>initialize super initialize. quickList := ListModel new list:#( 'Start' 'BP down' 'BP up' 'End' '***SNAFU***' ); yourself. fileSequence := ... "the log" Add the attached code. Among the important features are transparent handling of the selection index for the list and having something (following Dolphin, call them presenters) between the model and views (morphs). Models should not know or care about their selection index; the morph/view should do that (in Pharo, the ListPresenter is the natural home for it), and can do so in a way that "just works" for most purposes. The text presenters have been more trouble than I expected, but they bring with them some very important concepts. Dolphin's ViewResource is looking for a home (whether it will find one is open for bets), and the volley of events between model, view and presenter is starting to appear. Among the important tests (not yet realized as unit tests - sorry) is one model with multiple views; change the model and the views update. Dolphin's layout managers are very powerful, and while the pieces to make them exist in Pharo, I have yet to master their use. A common trap is to use top-level views when something composable is possible and desirable. I am not yet sure what to do about that. 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 3:48 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Toward MVP: SimpleGridExample vs. ClassListExample, etc. 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
