DigiGod Q Frasch� wrote:
> A CLI isnt going to have a taskbar, a XUI might not. JADE cant assume
> there is a taskbar, if there was a taskbar its only interaction would be
> that it uses JADE to get things like the process manager (to create the
> list of tasks)
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.
"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.
--
Ryan Heise
http://www.progsoc.uts.edu.au/~rheise/
_______________________________________________
UI maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/ui
