DigiGod Q Frasch� wrote:
> DesktopWidget would also have to handle adding and removing
> ToolbarWidgets and Im sure other things but thats slightly offtopic.
Again, removeToolbarWidget() is very similar to disposeWindow(). For the
same reason, I believe it should be a method on the model (and
controller). I think you will find that some widgets (including
DesktopWidget) will need to define /some/ public methods to handle
direct interactions between views (widgets). I have found this
unavoidable, but those methods are subordinate to the methods provided
by the model (and controller). They would be needed, for example, to
allow a ToolbarWidget component to be added (in AWT terms) to its
Container. This is a direct view <-> view interaction that requires
public widget methods.
> I think making the desktop a JDesktopPane is the worst way to go, it
> requires to many messy hacks to work could cause problems with AWT
> components and is somewhat small minded design wise. several times Ive
> proposed the use of a Screen.
Yes, JDesktopPane is probably not the best choice.
> we should decide what types of interfaces to design for the views and
> what to put in them, we could make a cheap imitation of a Desktop with a
> JWindow or even a JDesktopPane to test on, but I doubt will get that far
> so soon.
There is probably very little you can decide about the view interfaces
at this point in time. When you start to consider how the controllers
and models come in to play, your design will probably change completely.
I definately think it is easier to start designing from the model end.
Even then, your design will change a bit when you start to consider how
the view fits into the picture. But at least when you get there, you
will have already thought about the foundations of your MVC system.
--
Ryan Heise
http://www.progsoc.uts.edu.au/~rheise/
_______________________________________________
UI maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/ui
