|
Don't have any good advice on the money
front.
A cooperative GUI is one that is fully
introspective. You can obtain from a widget all of the properties necessary
to instantiate an exact copy of the widget. The value of this is two-fold: it
makes (the discussed to death) round-tripping possible and it allows a GUI
builder to self-configure itself to work with customer widgets (ones it isn't
specifically built to handle). The basic requirement of a cooperative GUI is
that no properties are write-only. It doesn't matter what kind of public API is
used to read the properties, but it must be possible to discover what properties
exist for a given widget, what the value types of the properties are and to
read them all. get/setProperty is not the best possible interface because it is
type-neutral. Individual getters and setters are better.
As you probably know,
the standard technique for implementing a GUI builder with an uncooperative
GUI is to shadow each GUI object with one that cooperates. Within the GUI
builder, the shadow object does all the configuration of the GUI object and
remembers the state, effectively layering get/setProperty on top of the GUI,
esp. for properties that are write-only in the GUI itself. This is most
successful if the shadow objects are specifically tailored to the GUI, so that
the properties are native to the GUI (use the same terminology) and no
configuration options are lost.
This can work, but it won't have the benefits I
listed above.
Bob
----- Original Message -----
Sent: Saturday, January 18, 2003 9:16
PM
Subject: Re: SWT History and Design
Decisions (WAS: [platform-swt-dev] AWT Toolkit using SWT (was: From Swing to
SWT))
Hi Bob,
Thanks for your insights below.
Plainly
speaking, I want Java to succeed in a painful way. I have been working with
platform neutral technology since 1977 and I am just very angry that so much
good engineering talent has been absorbed in so many trivial areas. One thing
MS has done really well is to magnify the importance of visualization. Their
downsides have been amply covered. Java needs good visualization tools and,
clearly, the graphics approach of Eclipse appeals to me.
Let me take a
stab in answering your question concretely as to why Eclipse appears difficult
to me develop a builder. I am used to working with a widget set that was built
to support a Builder.
Technical Difficulty
====================
I
have examined the package docs pretty carefully: o.e.s.widgets. Could
you please examine the package marimba.gui? Here is the url:
http://opendoors.com/conga/2.2/docs/javadoc/marimba/gui/package-summary.html
Consider
the base class above, conveniently named Widget, comparing apples to
apples:
a) There is direct support in m.g.Widget for Property
Extraction, Delivery via the PropertyObject implementation.
b) Editor
Support. The base class supports widget editability. A widget can be in edit
mode versus run mode.
c) m.g.Widget enforces a lifecycle:
Materialization
setProperties()
init()
start()
action()
destroy()
d)
Scriptability. Every widget contains a member to load its subclass at
runtime.
e) Adapter. If a widget's adapter property variable is non-null,
this class will be instantiated as a delegate for (c) lifecycle method
handling of messages to the Presentation's Controller.
f) Abstraction. The
m.g has several key abstract classes which form base classes for common GUI
patterns: GroupWidget, ChoiceWidget, ButtonWidget, ShapeWidget and
ResourceWidget are base classes for several distinct
hierarchies.
Financial Difficulty
====================
Knowing
what you and I know... building, testing, documenting, supporting a
commercial-grade, production Builder for SWT on a class with MS Studio
requires at least one good deep pocket. Sadly, that is not mine at this time.
I would really like to tackle this but ... if i told my wife I was tackling a
new, big project without any compensation. She would kill me, then divorce me
:).
Alternatives
==================
What are the alternatives,
Bob? Do you see the above difficulties as being solved by the generic methods,
setObject(), getObject()? Are there funding sources for a commercial-grade
Builder for Eclipse?
regards,
Lane
Bob Foster wrote:
My posting wasn't directed to you - I knew you
have a GUI builder - but to those who think that GUI builders are trivial
applications. Since you charge for yours, I assume you understand it is
non-trivial. ;-}
Thanks for the link. I will check it out. But since you
have already told me what I wanted to know...
There are GUI builders that generate source
code and those that don't (like yours). My feeling has always been that
round-tripping is a *requirement* and if you want to generate source code
then you open yourself up to having to round-trip from the source (or
object) code. However, if you don't generate source code you are free to
round-trip from whatever intermediate representation you have chosen. Either
way satisfies the requirement. One of them (the source code path) is much
harder than the other.
Your GUI builder generates "property resource
files". So it is in the long and honorable tradition of GUI builders like
NextStep, Apple's Project/Interface builder, even Visual Studio. Personally,
I think this is a good approach.
What I don't understand is why you started this
thread? There has to be some failing of either SWT or your descriptive
techniques that leads you to think that adapting Conga to SWT would be hard.
Specifically, what are they?
Bob
PS The word 'paradigm' tends to set me off.
;-}
Lane Sharman wrote:
Bob
Foster wrote:
So where's your GUI builder? (Or Scott's,
for that matter? ;-) http://opendoors.com/conga
Download
it for a free 30 trial. Also, be sure to read the link on the page and in
the distro, "A Guide to Using Conga with a Team of Graphic Artists and
Java Programmers". I believe Conga is completely production grade. Please
be sure to drop me a note with any issues offline. Really looking forward
to working with you.
I'm not seriously challenging that you
could make one. I just want to look at the GUI builder that
results.
The issue isn't whether you can make a GUI
builder for SWT. You can make a GUI builder for any library...provided
that you don't have to "round trip" (convert source/object code into the
representation used internally by the GUI
builder). Conga does not generate/manage code.
This is a failing of most GUI builders: they generate reams of code which
statically describe at design time the UI. Conga's Builder manages
property resource files. Code generation of a UI is basically an evil
practice which should be avoided given the dynamic nature of a UI.
I know from previous discussion that Scott
thinks this is not a requirement. I also know that many commercial GUI
builders do allow round-tripping. Enough so that many would consider
this a competitive requirement. Further, in my
own apps, I routinely rewrite the property resource files as easily as one
would save a data file to preserve user interaction state with the UI.
Kinda hard to rewrite and compile a a java source tree in a business
app.
I am not trying to brag or anything. In fact, Arthur Van Hoff
and his team deserves all the credit because this was his baby some time
back and he is about an order of magnitude superior to me as a programmer.
It is just that Conga reflects some really outstanding design features
and, at this critical juncture in Java's story, we need some help on the
desktop to compete with Visual Studio.
Kindest,
Lane
Bob
-----
Original Message -----
Sent:
Friday, January 17, 2003 1:08 PM
Subject:
RE: SWT History and Design Decisions (WAS: [platform-swt-dev] AWT
Toolkit using SWT (was: From Swing to SWT))
Its entirely
possible
its just that some designers make API, or at least paradigm
assumptions about the GUI library they design with, and sometimes
those assumptions are incompatible with an alternate GUI
library. Im not sure this is the case in the
mentioned systems, but its the only real impediment.
Building a natively SWT-aware builder is not particularly hard
compared with another GUI library.
Regards,
Christian.
-----Original
Message-----
From: platform-swt-dev-admin@xxxxxxxxxxx
[mailto:platform-swt-dev-admin@xxxxxxxxxxx]
On Behalf Of Jan
Venema
Sent: Friday,
January 17, 2003 10:49 PM
To: platform-swt-dev@xxxxxxxxxxx
Subject: Re: SWT History and
Design Decisions (WAS: [platform-swt-dev] AWT Toolkit using SWT (was:
>From Swing to SWT))
Can
sombody please explain to me why it is not possible to build a GUI
designer in SWT.
I've been following the discussions here, but I
haven't realy heard an answer. On the properties pattern thing. Does
setData(String key, Object value) solve your problem? And since
SWT is native widgets How does Visual Studio do it?
<!--[if
!supportLineBreakNewLine]-->
<!--[endif]-->
--
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO
--
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO
|
