Ryan Heise wrote:
> This issue can be easily solved using a Model/View/Controller model. We
> explored MVC in some detail about a year ago on this list. The idea of a
> process manager matches the concept of a "model", while the taskbar is
> an example of a "view". You may have already been aware of the
> similarity, but speaking in terms of MVC will probably lead to a clearer
> design.
>
> For those who missed the discussion way back then, I think we decided on
> a combination of Java Beans and MVC, where model beans maintained data
> structures such as process lists and window lists, while view beans
> implemented displays or user interfaces of those data structures.
>
> For example, there may be a view that displays the list of open windows
> - the user could click on a window item to raise that window on the
> desktop (yes, like that significant component of the taskbar). There
> could be another "view" of the same window list "model" that shows your
> miniature virtual desktops. This view would mirror the exact window
> positions of each window on a smaller scale but allow you to select
> windows in the same way as the taskbar. The most interesting view is
> actually the window manager itself. It should also be a view of the
> window list.
we also decided that virtual windows would be handled by a special JADE
PUI that allows other UI's to plug into it (I know what your saying but
I wanted to remind us)
say the DesktopScreen (extends Screen extends OutputDevice?) has an
inner class WindowManager which does all that nasty window overlap code
(gracefully, of course) this would be the 'M', the TaskbarWidget
(TaskbarController?) would be the 'C' and whatever component implements
that would be the 'V'
> "Window list" is not necessarily the best way to divide the model space
> but it is enough to demonstrate the concept.
>
> > the answer is all the
> > desktop widgets must be designed via interface.
> >
> > public interface Taskbar extends DesktopWidget {
> > //bla bla bla
> > }
>
> This corresponds to a view. I have no objection to the term "widget",
> but you should also think up a term that corresponds to "model". I know
> I haven't mentioned "controller" yet. Typically a controller is
> responsible for handling a use case in a system. Swing uses a modified
> MVC model where the controller is combined with the view. The argument
> is that creating a separate controller class for everything can be an
> overkill. This is probably the way to go unless we can foresee a
> specific need to have controllers separate.
so we leave the M up to the OS/JADE to be reperesented as best they can
and put the VC into the widgets (or whatever)?
Cheers,
DigiGod
_________________________
[EMAIL PROTECTED]
AIM:DigiGod 86
_________________________
Quote of the Moment:
Thus spake the master Ninjei:
"To the intelligent man, one word, to the fleet horse
one whip, to the well-written program, a single
command"
_________________________
Prank of the Moment:
Using the conferencing feature of your office phone, dial
one Induhvidual, then while it's ringing dial another and
conference them together. Put your own phone on mute
and listen to see how long they'll make small talk before
figuring out that neither one placed the call.
O-
_______________________________________________
UI maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/ui
