[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] SWT on top of swing?
|
Hi Michael,
You definitely want to join the NetAmie project because our visions are
nearly equivalent.
For your information, we have a basic reference application (a Desktop
Login) running under SWT, Swing and Conga such that both the M and C of
the MVC are identical. The controller sees the GUI through an interface
contract which specifies what a widget adapter can do, what call backs
the controller must handle.
I will look at anonymous CVS. Do you want to join and possible commit
some code?
NetAmie is opposed to SWT verus Swing shoot-outs. Both toolkits have a
space and history for the Java Desktop. As might, for example, Flash.
The goal is to furnish GUI Service Providers with an elegant contract
which allows the application to view the GUI at a higher level of
abstraction. Similar to JSDK and the JDBC Service Contracts. Multiple
database and servlet container providers have invigorated the Java
marketplace. We believe this to be the case for Java as well.
-Lane
Michael Scharf wrote:
Lane,
NetAmie is a project on java.net which abstracts out SWT and Swing
for the application (also AWT, Flash, and Conga and OpenGL). The
application will not care whether it is Swing or SWT. Therefore, you
remove your application dependency on the specific tool kit.
That's cool. I'm currently working on a similar project called
GuiModel. Here the idea is, to clearly separate the GUI from
the GuiModel. Client code is written against the GuiModel. You
build the gui (well it's intended to be used for dialogs) with
your favorite widgetset or guibuilder. All you have to do is to
register the widgets with slots in the gui model. The interaction
between the GUI and the model is done in the GUI specific adapter (e.g
the SWTAdapter or the SwingAdapter)....
All the logic of the dialog is encoded in the GuiModel. That makes
it easy to change the GUI witout touching any of the logic of
the application. An additional advantage is, that you can change
values in the model and the GUI is automatically listening to
the model changes. Or the user changes the state of a GUI widget
and the model gets changed (and listeners to the model get
notified). Because the model is generic, it's easy to add
a "cancel" or "defaults" behaviour in a general way.
You can plug in a data implementation of your choice for the
model representation. That way it's easy to directly drive e.g.
eclipse Preferences or a custom data implementation of your
choice....
This approach is slighty less ambitios then netamie (as I
understand it), because the creation of the GUI remains
specific to he used widgetset, but changing the GUI should
not have an impact on the application (because there should
be no application logic in the GUI part...)
However, as we say in German, "the devil is in the detail".
So, I'm experimenting with my preliminary implementation to
see if this is usable in the real world....
The GuiModel is really restricted to dialogs, wizzard pages
etc. It's not meant to cover the the logic of an application.
You have an interface contract which abstracts out the details of the
graphics implementation. Think JDO which abstracts out the specific
persistence store.
The project is https://netamie.dev.java.net/ . Look forward to your
comments or participation.
I tryed to check out the code, but neither
cvs -d :pserver:anoncvs@xxxxxxxxxxxxxxxx:/cvs login
nor
cvs -d :pserver:guest@xxxxxxxxxxxxxxxx:/cvs login
seem to work (what's the anonymous password?)
Michael
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
--
Lane Sharman
Just Do IT, Better.
858-755-2868
