Todd,
I had forgotten about the costumes - now I really want no part of Tweak :(
I am not sure that we are actually trying to ditch Morphic, so much as offer an alternative to it. Perhaps we can offer a choice between Morphic and "The Welch Thing" on a per-use basis. If we get it right, the tools will move in our direction, especially with Matt and Colin paying attention to this list. Our work should also be able to co-exist with Morphic to aid those who want to migrate to MVP, but not all at once.
Are you certain one needs vectors to get a GUI right? Good layout managers and setting font sizes in #onViewOpened (of MVP fame) should be enough - I think??? I tend to assume that anything beyond the basic widgets goes in an ImagePresenter and as such can scale as needed simply by rendering the image at an appropriate resolution.
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
tblanchard@mac.com 09/16/07 1:44 PM >>>
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
_______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
On 16-Sep-07, at 11:41 AM, Bill Schwab wrote:
Todd,
I had forgotten about the costumes - now I really want no part of Tweak
Costumes are in my opinion one of the more useful parts of the tweak design. You an change the look by changing the costume. Now tweak events... that's a different story. Nice idea but living with them in practice has been a real pain. Debugging when there are dozens of processes running, each handling an event related script has not been pleasant. I'm sure there must be a solution but we (as in 'the Sophie team' have not found it.
Perhaps we can offer a choice between Morphic and "The Welch Thing" on a per-use basis.
That would be 'the Welsh thing', if you don't mind, (http:// www.etymonline.com/index.php?search=welch&searchmode=none) or 'Ariethfa Ffenestri' or just ffenestri. Remember that ffenestri is *only* a system for creating and manipulating host windows and allowing us to draw upon them. Someone needs to implement whatever higher level code is need to make meaningful use of the window. Morphic, Tweak, even MVC could all do so. My preference would be to see something based on Cairo(http://cairographics.org/) since that offers quite good quality, reasonably portable, vector based drawing and fonts and image composition.
I really think that the conversations about use of MVP, MVC, whatever a re very premature. Right now I'd urge people to be thinking about what a UI should be able to do and not worry about just how to do it yet. What sort of interactions are needed? What widgets will support them? What sort of UI creation tool (s) would be nice? What sort of presentation devices should be supported - big screen, little screens, colour only or monochrome as well, touchscreeens, projected giant displays, web browsers via Web2.0-whatever ?
Take the time to really work out something sensible. Document what is worked out. Work through scenarios of use and programming of the design.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: YII: Yield to Irresistable Impulse
tim Rowledge schrieb:
I really think that the conversations about use of MVP, MVC, whatever a re very premature. Right now I'd urge people to be thinking about what a UI should be able to do and not worry about just how to do it yet. What sort of interactions are needed? What widgets will support them? What sort of UI creation tool (s) would be nice? What sort of presentation devices should be supported - big screen, little screens, colour only or monochrome as well, touchscreeens, projected giant displays, web browsers via Web2.0-whatever ?
Just some random thoughts:
After playing a little with seaside and its HTML rendering mechanism (which has some similarities to ToolBuilder's) I can imagine a combination of these things: 1. A way of specifying a GUI programmatically somewhat more similar to the HTML rendering in seaside (i.e. more concise, better structural nesting). Let's call it ToolBuilderToo since it would really be a slightly imrpoved ToolBuilder. 2. A mechanism for creating such "buildWith:" methods from existing GUIs which may have either been created using a kind of GUI painter, or are real live GUIs. For example, taking a live browser window, adding a button with some function, and storing its specification would be nice. Of course, it's entirely reasonable if this is only supported in one or two ToolBuilderToo targets, such as Morphic and Tweak for example. 3. A more powerful layout mechanism - GUIs built with ToolBuilder are pretty limited since it needs to cope with MVC's viewport/window transformation ugliness which essentially forces the GUI to have only proportionally scaled panes. I know that I have struggled with MVC and fixed-height panes ever since I first touched a Smalltalk-80 system 20 years ago, so this might not be easy. 4. (maybe in combination with 3) Something like cascading style sheets for specifying different layouts and colorings for GUIs. Maybe it would even be possible to specify GUI themes using some kind of CSS?
CSS allows for some pretty decent layout, and maybe using it as the method for specifying GUI layouts would lead to some synergy effects between web GUI and screen GUI developments.
Cheers, Hans-Martin
On 16-Sep-07, at 2:32 PM, Hans-Martin Mosner wrote:
CSS allows for some pretty decent layout, and maybe using it as the method for specifying GUI layouts would lead to some synergy effects between web GUI and screen GUI developments.
We've been using some CSS for UI layout in Sophie. Seems to work reasonably but decent integration would be useful. Having text files sitting around is not a good solution in my mind.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- If he were any more stupid, he'd have to be watered twice a week.
The HtmlViewer project on squeaksource does a reasonable job at layout - it passes acid 1 - but there are a lot of features missing yet. The author intends to continue working on it and I intend to help him.
On Sep 16, 2007, at 4:15 PM, tim Rowledge wrote:
On 16-Sep-07, at 2:32 PM, Hans-Martin Mosner wrote:
CSS allows for some pretty decent layout, and maybe using it as the method for specifying GUI layouts would lead to some synergy effects between web GUI and screen GUI developments.
We've been using some CSS for UI layout in Sophie. Seems to work reasonably but decent integration would be useful. Having text files sitting around is not a good solution in my mind.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- If he were any more stupid, he'd have to be watered twice a week.
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
tim Rowledge schrieb:
On 16-Sep-07, at 2:32 PM, Hans-Martin Mosner wrote:
CSS allows for some pretty decent layout, and maybe using it as the method for specifying GUI layouts would lead to some synergy effects between web GUI and screen GUI developments.
We've been using some CSS for UI layout in Sophie. Seems to work reasonably but decent integration would be useful. Having text files sitting around is not a good solution in my mind.
That's right, I was more interested in the functionality of style sheets than in the actual syntactic representation used in CSS files. What I am contemplating is a kind of "smalltalkization" of CSS such that a style sheet can be written as a method with ordinary message sends, somewhat analogous to the way HTML or window parts are specified in seaside and ToolBuilder, respectively. Parsing actual CSS files can be useful, too, but should not be the main mechanism for handling GUI layout CSS.
Cheers, Hans-Martin
On Sep 16, 2007, at 2:12 PM, tim Rowledge wrote:
Costumes are in my opinion one of the more useful parts of the tweak design. You an change the look by changing the costume.
Perhaps - but when wanting to make a custom control - it gets unclear (to me anyway) whether one should subclass one or both of the player/ class pair. This is the bit I expect people to get wrong often.
An example is the multi-column Mac OS X file browser - I sat down to try to make one of these a couple different times and never really got anywhere as I kept going around and around on whether I should just keep the existing file chooser player, but make a new costume, or make a new player to go along with it.
Having once built an event based system that relied on a pair of threads separated by a queue - I can see how debugging things can be a pain as you don't have that nice stack to figure out just how you got here.
-Todd Blanchard
On 9/16/07, tim Rowledge tim@rowledge.org wrote:
I really think that the conversations about use of MVP, MVC, whatever a re very premature. Right now I'd urge people to be thinking about what a UI should be able to do and not worry about just how to do it yet.
On this I'm actually of the oposite opinion. I don't think we can know what we will want to do graphically tommorow, but one thing never changes: We always some some domain object that does some kind of non-GUI work, and we always have one or more ways we wish to present it.
IMO, this is the power of the MVP concept, that we decouple these two always present components from the View which changes constanlty and often drastically (what did computing look like 10 years ago? The models are still mostly the same).
On 9/16/07, Bill Schwab BSchwab@anest.ufl.edu wrote:
I am not sure that we are actually trying to ditch Morphic, so much as offer an alternative to it.
With the MVP proposals I don't think we are doing either. I think Morphic could be used for the view if we want.
I hope people don't take my questioning of Morphic as an indication that MVP has to replace it. I think these are two totally different issues.
Perhaps we can offer a choice between Morphic and "The Welch Thing" on a per-use basis.
Personally I see this choice as the power of the MVP model. We can create a domain class, a presenter for it and a view (or a few) for each possible View type (e.g. Tweak, Morphic, OpenGL, Seaside?), which can be selected automatically depending on user preferences.
Well, there is the Model but there has to be a linkage for when the model changes. That's the basics. We need to decide on the way(s) we wish that to happen. I find changed/update rather inefficient. Much prefer when:send:to:.
But that's just the start. Pretty fundamental though.
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org] On Behalf Of Jason Johnson Sent: 18 September 2007 6:07 pm To: Squeak's User Interface Subject: Re: [UI] Well, shall we do something then?
On 9/16/07, Bill Schwab BSchwab@anest.ufl.edu wrote:
I am not sure that we are actually trying to ditch Morphic,
so much as
offer an alternative to it.
With the MVP proposals I don't think we are doing either. I think Morphic could be used for the view if we want.
I hope people don't take my questioning of Morphic as an indication that MVP has to replace it. I think these are two totally different issues.
Perhaps we can offer a choice between Morphic and "The Welch Thing" on a per-use basis.
Personally I see this choice as the power of the MVP model. We can create a domain class, a presenter for it and a view (or a few) for each possible View type (e.g. Tweak, Morphic, OpenGL, Seaside?), which can be selected automatically depending on user preferences. _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
On 18/09/2007, Gary Chambers gazzaguru2@btinternet.com wrote:
Well, there is the Model but there has to be a linkage for when the model changes. That's the basics. We need to decide on the way(s) we wish that to happen. I find changed/update rather inefficient. Much prefer when:send:to:.
But that's just the start. Pretty fundamental though.
Yes! And i think this is the point where we should start from. How to create flexible event system , how exchange data between view and model. Based on that we then can build up a model which will use it (MVP/Morphic whatever)
On Wed, Sep 19, 2007 at 12:38:44AM +0300, Igor Stasenko wrote:
On 18/09/2007, Gary Chambers gazzaguru2@btinternet.com wrote:
Well, there is the Model but there has to be a linkage for when the model changes. That's the basics. We need to decide on the way(s) we wish that to happen. I find changed/update rather inefficient. Much prefer when:send:to:.
But that's just the start. Pretty fundamental though.
Yes! And i think this is the point where we should start from. How to create flexible event system , how exchange data between view and model. Based on that we then can build up a model which will use it (MVP/Morphic whatever)
A note of caution: The #when:send:to: mechanism can have serious performance issues due to its use of weak dictionaries. Performance of the entire image is seriously impacted by weak array finalization as the number of these dictionaries increases. There is no easy fix for this, so make sure you know what you are getting into before you start with an approach based on this mechanism.
Dave
Isn't there just the one WeakIdentityKeyDictionary in ActionMaps on EventManager?
I guess you mean the finalization takes longer when there are more entries in the dictionary.
The same applies to changed/update when the model object doesn't inherit from Model (or also Morph, with the ui enhancements loaded).
In fact, the same approach can be taken to record events directly on the relevant object (as in the case of changed/update in the Model class).
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of David T. Lewis Sent: 19 September 2007 11:46 AM To: Squeak's User Interface Subject: Re: [UI] Well, shall we do something then?
On Wed, Sep 19, 2007 at 12:38:44AM +0300, Igor Stasenko wrote:
On 18/09/2007, Gary Chambers gazzaguru2@btinternet.com wrote:
Well, there is the Model but there has to be a linkage for
when the model
changes. That's the basics. We need to decide on the way(s)
we wish that to
happen. I find changed/update rather inefficient. Much prefer
when:send:to:.
But that's just the start. Pretty fundamental though.
Yes! And i think this is the point where we should start from. How to create flexible event system , how exchange data between view and model. Based on that we then can build up a model which will use it (MVP/Morphic whatever)
A note of caution: The #when:send:to: mechanism can have serious performance issues due to its use of weak dictionaries. Performance of the entire image is seriously impacted by weak array finalization as the number of these dictionaries increases. There is no easy fix for this, so make sure you know what you are getting into before you start with an approach based on this mechanism.
Dave
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
I've observed Martin Loewis' new WeakKeyDictionary implementations reduce the problem dramatically.
http://bugs.squeak.org/view.php?id=6348
I know sig has done similar work but I haven't had time yet to try it.
On 9/19/07, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Sep 19, 2007 at 12:38:44AM +0300, Igor Stasenko wrote:
On 18/09/2007, Gary Chambers gazzaguru2@btinternet.com wrote:
Well, there is the Model but there has to be a linkage for when the model changes. That's the basics. We need to decide on the way(s) we wish that to happen. I find changed/update rather inefficient. Much prefer when:send:to:.
But that's just the start. Pretty fundamental though.
Yes! And i think this is the point where we should start from. How to create flexible event system , how exchange data between view and model. Based on that we then can build up a model which will use it (MVP/Morphic whatever)
A note of caution: The #when:send:to: mechanism can have serious performance issues due to its use of weak dictionaries. Performance of the entire image is seriously impacted by weak array finalization as the number of these dictionaries increases. There is no easy fix for this, so make sure you know what you are getting into before you start with an approach based on this mechanism.
Dave
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
Yes, there have been a few attempts to address this. I took a stab at a part of the problem myself in http://bugs.squeak.org/view.php?id=2910. I don't know the status of Martin Loewis' proposal, so all I can say is that I hope it helps. I do know that Andreas Raab, who implemented the underlying finalization mechanism, has indicated that implementing a more scaleable approach is not a trivial undertaking. I believe that it would involve VM changes as well as image changes, but I'm getting out of my depth at this point, and I don't recall exactly what Andreas had to say about it. The discussion should be in the mailing list archives somewhere (possibly on the Seaside mailing list as well).
Dave
On Wed, Sep 19, 2007 at 10:48:24PM -0400, Chris Muller wrote:
I've observed Martin Loewis' new WeakKeyDictionary implementations reduce the problem dramatically.
http://bugs.squeak.org/view.php?id=6348I know sig has done similar work but I haven't had time yet to try it.
On 9/19/07, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Sep 19, 2007 at 12:38:44AM +0300, Igor Stasenko wrote:
On 18/09/2007, Gary Chambers gazzaguru2@btinternet.com wrote:
Well, there is the Model but there has to be a linkage for when the model changes. That's the basics. We need to decide on the way(s) we wish that to happen. I find changed/update rather inefficient. Much prefer when:send:to:.
But that's just the start. Pretty fundamental though.
Yes! And i think this is the point where we should start from. How to create flexible event system , how exchange data between view and model. Based on that we then can build up a model which will use it (MVP/Morphic whatever)
A note of caution: The #when:send:to: mechanism can have serious performance issues due to its use of weak dictionaries. Performance of the entire image is seriously impacted by weak array finalization as the number of these dictionaries increases. There is no easy fix for this, so make sure you know what you are getting into before you start with an approach based on this mechanism.
Dave
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
On 20/09/2007, Chris Muller asqueaker@gmail.com wrote:
I've observed Martin Loewis' new WeakKeyDictionary implementations reduce the problem dramatically.
http://bugs.squeak.org/view.php?id=6348I know sig has done similar work but I haven't had time yet to try it.
Btw, regarding weak finalization process, i posted a fix which should improve speed even more: http://bugs.squeak.org/view.php?id=6652 But it seems my post was ignored, no any comments, nor discussion..
On 9/19/07, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Sep 19, 2007 at 12:38:44AM +0300, Igor Stasenko wrote:
On 18/09/2007, Gary Chambers gazzaguru2@btinternet.com wrote:
Well, there is the Model but there has to be a linkage for when the model changes. That's the basics. We need to decide on the way(s) we wish that to happen. I find changed/update rather inefficient. Much prefer when:send:to:.
But that's just the start. Pretty fundamental though.
Yes! And i think this is the point where we should start from. How to create flexible event system , how exchange data between view and model. Based on that we then can build up a model which will use it (MVP/Morphic whatever)
A note of caution: The #when:send:to: mechanism can have serious performance issues due to its use of weak dictionaries. Performance of the entire image is seriously impacted by weak array finalization as the number of these dictionaries increases. There is no easy fix for this, so make sure you know what you are getting into before you start with an approach based on this mechanism.
Dave
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
I guess I missed your original post. I've starred your message, I'll try to try it out soon..
Thanks.
On 9/21/07, Igor Stasenko siguctua@gmail.com wrote:
On 20/09/2007, Chris Muller asqueaker@gmail.com wrote:
I've observed Martin Loewis' new WeakKeyDictionary implementations reduce the problem dramatically.
http://bugs.squeak.org/view.php?id=6348I know sig has done similar work but I haven't had time yet to try it.
Btw, regarding weak finalization process, i posted a fix which should improve speed even more: http://bugs.squeak.org/view.php?id=6652 But it seems my post was ignored, no any comments, nor discussion..
On 9/19/07, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Sep 19, 2007 at 12:38:44AM +0300, Igor Stasenko wrote:
On 18/09/2007, Gary Chambers gazzaguru2@btinternet.com wrote:
Well, there is the Model but there has to be a linkage for when the model changes. That's the basics. We need to decide on the way(s) we wish that to happen. I find changed/update rather inefficient. Much prefer when:send:to:.
But that's just the start. Pretty fundamental though.
Yes! And i think this is the point where we should start from. How to create flexible event system , how exchange data between view and model. Based on that we then can build up a model which will use it (MVP/Morphic whatever)
A note of caution: The #when:send:to: mechanism can have serious performance issues due to its use of weak dictionaries. Performance of the entire image is seriously impacted by weak array finalization as the number of these dictionaries increases. There is no easy fix for this, so make sure you know what you are getting into before you start with an approach based on this mechanism.
Dave
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
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
On 9/18/07, Gary Chambers gazzaguru2@btinternet.com wrote:
Well, there is the Model but there has to be a linkage for when the model changes. That's the basics. We need to decide on the way(s) we wish that to happen. I find changed/update rather inefficient. Much prefer when:send:to:.
By "changed/update" you mean "something changed, go reload the whole object"? I prefer the "register for this specific event from this model", but in MVP the Aspects were so fine grained I think even "changed/update" would work because you would be talking about changes to classes like string, number, etc. In other words, a presenter for a given class would have an aspect for each member as I recall.
But that's just the start. Pretty fundamental though.
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org] On Behalf Of Jason Johnson Sent: 18 September 2007 6:07 pm To: Squeak's User Interface Subject: Re: [UI] Well, shall we do something then?
On 9/16/07, Bill Schwab BSchwab@anest.ufl.edu wrote:
I am not sure that we are actually trying to ditch Morphic,
so much as
offer an alternative to it.
With the MVP proposals I don't think we are doing either. I think Morphic could be used for the view if we want.
I hope people don't take my questioning of Morphic as an indication that MVP has to replace it. I think these are two totally different issues.
Perhaps we can offer a choice between Morphic and "The Welch Thing" on a per-use basis.
Personally I see this choice as the power of the MVP model. We can create a domain class, a presenter for it and a view (or a few) for each possible View type (e.g. Tweak, Morphic, OpenGL, Seaside?), which can be selected automatically depending on user preferences. _______________________________________________ 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
-
Bill Schwab -
Chris Muller -
David T. Lewis -
Gary Chambers -
Hans-Martin Mosner -
Igor Stasenko -
Jason Johnson -
tim Rowledge -
Todd Blanchard