DigiGod Q Frasch� wrote:
>
> I use widget in a broad sense not tied to either the AWT or Swing.
>
> JADE's widgets should be defined in this broad sense, hence we should
> define them first as interfaces create a default set using swing then
> extends that to create the "JOS Standard GUI" widgets.
>
> here's all the widgets I can think of
>
> Widget
> |
> +-DesktopWidget
> |
> +-ClockWidget
> |
> +-DockWidget
> |
> +-TaskbarWidget
> |
> +-ToolbarWidget
> |
> +-PropertyPageWidget
>
> Widget is the super interface (it doesnt even have to define any
> methods).
>
> DesktopWidget represents the actual desktop and has methods for moving
> windows around, adding widgets (like a taskbar) and the like.
If you take the MVC approach, the methods in DesktopWidget would not be
at all interesting. In fact DesktopWidget could be defined to have no
methods. Instead, we have the following design:
class DesktopModel
- showWindow(win)
- hideWindow(win)
- selectWindow(win)
- disposeWindow(win)
- moveWindow(win, x, y)
- resizeWindow(win, w, h)
interface DesktopListener
- windowShown(event)
- windowHidden(event)
- windowSelected(event)
- windowDisposed(event)
- windowMoved(event)
- windowResized(event)
Then perhaps:
class SwingDesktopWidget extends JDesktopPane implements Widget
{
class SwingDesktopListener implements DesktopListener
{
public void windowShown(DesktopEvent e)
{
findWindow(e.getWindow()).setVisible(true);
}
}
}
As you can see, there is no need for a DesktopWidget interface that
defines methods to move windows around. In MVC, you would call
controller.moveWindow(...) to move the window. As a result, all
DesktopListeners will be notified through the windowMoved() method,
which as you can see I have handled with an inner class to prevent
people from calling these methods directly.
I mentioned in another email that you don't really need a separate
controller class, SwingDesktopWidget could interact directly with
DesktopModel to move the window but SwingDesktopWidget itself has no
public methods to move a window. It is not an interface for moving
windows, it is just a view that internally is allowed to move windows.
Now, the class design above was just given to demonstrate MVC. It is not
necessarily the best design. It is possible to divide DesktopModel into
a finer set of model components.
If you go with MVC, the first step is to define the *Model, *Listener
and *Event interfaces. As for the Widget interfaces, I think you will
need only a single Widget interface. The requirements for the view layer
will become clearer later on.
--
Ryan Heise
http://www.progsoc.uts.edu.au/~rheise/
_______________________________________________
UI maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/ui
