DigiGod Q Frasch� wrote:
>
> Ryan Heise wrote:
> > 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.
>
> we could have a very abstract model, it doesnt even need to be aware of
> the components its using, we could represent them as Rectangles to it.
> all it would have is a view rectangle (the screen) and a stack of
> rectangles that it was in charge of z-ordering and the like. the
> controller would handle conversion between windows and rectangles and
> the view (DesktopScreen) would render accordingly.
>
> this could be reused by many things, even a UI that doesnt use AWT or
> Swing to do windowing (for whatever reason).
I don't quite see the usefulness of this. For example, when you
implement the Swing or AWT widgets, they will handle rectangles and
z-ordering in their own way.
If you were suggesting the idea in response to my observation that there
needs to be some view <-> view interactions, are you trying to eliminate
these interactions? I think when you get around to implementing your
Swing widgets, you will find that the most sensible thing to do is to
have direct view <-> view interactions when they are needed. For
example, when a JComponent needs to be graphically added to a JPanel.
Just keep in mind that these view <-> view methods are internal
implementation methods, and the real methods to add a ToolbarWidget to a
DesktopWidget are in the controller and model classes.
> > 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.
>
> you may be right, but we could at least get a basic idea of what we need
> to put them in, but more importantly (and Ive tried to stress this) of
> which ones to include that list I gave was far from complete, and some
> of them should have different, more appropriate, names.
That's reasonable. Ok,
PagerWidget - control for virtual desktops
MenuWidget - for example, you could dock a start menu to the
TaskBarWidget.
I'm thinking we should call it a system menu, not a start menu.
--
Ryan Heise
http://www.progsoc.uts.edu.au/~rheise/
_______________________________________________
UI maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/ui
