Jason,
Well said. I would add the point I already made separately, which is that the work to connect sub-presenters is different, not in addition to, what is required in Morphic.
I agree that Morphic can be leveraged for views, and replaced at a later date if necessary. Anyone looking for another reason to at least have a layer on top of Morphic might consider that Morphic is going to get clobbered (has already been?) in Croquet. I am not happy about their reasoning and suspect they will eventually regret the decision; Morphic could easily suffer for it.
Morphic is certainly not all bad, and in a rewrite scenario, we should be able to clone (aka steal<g>) quite a lot of code from it, clearly classifying behavior as belonging to views, interactors (e.g. mouse tracking) and presenters. A lot of cruft will be left behind.
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bschwab@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
jason.johnson.081@gmail.com 09/16/07 8:25 AM >>>
On 9/15/07, Brad Fuller bradallenfuller@yahoo.com wrote:
Warning: I know NOTHING about Dolphin. I haven't even seen it. But, as
you
explain it, it seems like some extra steps to make MVP objects
interactive.
Morphic objects are by default interactive, with nothing to do to get
there.
Why would you want a system that makes you perform extra steps?
Because close coupling (and I'm assuming based on what I've read that Morphic is closely coupled to the models) makes a less flexable system.
The way I personally program any GUI, web or otherwise, is I make my model classes. These are classes that only understand the work to be done. They know nothing about "does someone need to confirm this?" or what order their instance variables might be displayed or anything. You could call these classes in a background process that has no GUI components at all.
Now, there will be lots of different ways of displaying these model classes and exposing the services they offer. It is very often the case that different people are going to be interested in different services. So to support this, the best way I have seen is to have a "presenter" class that described generically how the class would be presented to a "third party" if you will [1].
And even a given presentation may have different ways to view it (see Magritte for examples).
I agree the event processing in Morphic can be improved. And, from my
small
experience with it, there are things that need to be fixed. But, why
not put
energy into improving Morphic? It's already there and MVP seems like a
LOT of
work!
It will be a lot of work to be sure, but other systems have better means of doing GUI work right now then Squeak. It's time to catch up. And I am still asking and not hearing (probably my own fault): what does Morphic offer? Why bother with the huge clean up it needs? What power/flexability does it offer that other graphic systems don't have?
But as has been mentioned by myself and others already, making MVP has nothing to do with Morphic. Morphic can make a suitable view for the MVP framework.
[1] Note that Lukas seemed to arrive at this conclusion independantly with his Magritte framework that allows you to describe how a model will be presented, and then it can be viewed via the web, Morphic, anything that someone has written a "view" for. _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
On Sep 16, 2007, at 7:50 AM, Bill Schwab wrote:
Anyone looking for another reason to at least have a layer on top of Morphic might consider that Morphic is going to get clobbered (has already been?) in Croquet. I am not happy about their reasoning and suspect they will eventually regret the decision; Morphic could easily suffer for it.
Maybe so. Tweak has a lot of issues of its own IMHO. The division of responsibilities between costume and player is not well understood by most (I haven't found a good explanation anywhere anyhow) and because of this - most external contributions will likely end up bastardized - similar to what happened to Morphic with etoys.
Morphic is certainly not all bad, and in a rewrite scenario, we should be able to clone (aka steal<g>) quite a lot of code from it, clearly classifying behavior as belonging to views, interactors (e.g. mouse tracking) and presenters. A lot of cruft will be left behind.
The main problem with trying to ditch Morphic is that you'll end up rewriting all the tools yet again. At least that was my experience with I was experimenting with Bricks. Perhaps ToolBuilder has eliminated that problem. Conclusions I reached were:
1) The graphics model lacks sufficient abstraction for what I was trying to do - too pixel oriented and a vector model is really needed. No abstraction for "shapes" available. 2) Morphic's event delivery model is just weird and difficult to alter because of a lot of special case code for handling halos.
-Todd
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bschwab@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
jason.johnson.081@gmail.com 09/16/07 8:25 AM >>>
On 9/15/07, Brad Fuller bradallenfuller@yahoo.com wrote:
Warning: I know NOTHING about Dolphin. I haven't even seen it. But, as
you
explain it, it seems like some extra steps to make MVP objects
interactive.
Morphic objects are by default interactive, with nothing to do to get
there.
Why would you want a system that makes you perform extra steps?
Because close coupling (and I'm assuming based on what I've read that Morphic is closely coupled to the models) makes a less flexable system.
The way I personally program any GUI, web or otherwise, is I make my model classes. These are classes that only understand the work to be done. They know nothing about "does someone need to confirm this?" or what order their instance variables might be displayed or anything. You could call these classes in a background process that has no GUI components at all.
Now, there will be lots of different ways of displaying these model classes and exposing the services they offer. It is very often the case that different people are going to be interested in different services. So to support this, the best way I have seen is to have a "presenter" class that described generically how the class would be presented to a "third party" if you will [1].
And even a given presentation may have different ways to view it (see Magritte for examples).
I agree the event processing in Morphic can be improved. And, from my
small
experience with it, there are things that need to be fixed. But, why
not put
energy into improving Morphic? It's already there and MVP seems like a
LOT of
work!
It will be a lot of work to be sure, but other systems have better means of doing GUI work right now then Squeak. It's time to catch up. And I am still asking and not hearing (probably my own fault): what does Morphic offer? Why bother with the huge clean up it needs? What power/flexability does it offer that other graphic systems don't have?
But as has been mentioned by myself and others already, making MVP has nothing to do with Morphic. Morphic can make a suitable view for the MVP framework.
[1] Note that Lukas seemed to arrive at this conclusion independantly with his Magritte framework that allows you to describe how a model will be presented, and then it can be viewed via the web, Morphic, anything that someone has written a "view" for. _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui