> An
explicit state object, PropertyList, is what we use in Conga, not
introspection.
Sounds ok to me. Introspection, by the way, is a
term used by Java Beans. Introspection allows you to get additional
information, like default values. Sounds like your PropertyList is designed with
the same goals in mind. Reflection is the term used for what you can get out of
the naked API.
Bob
----- Original Message -----
Sent: Sunday, January 19, 2003 10:41
AM
Subject: Re: SWT History and Design
Decisions (WAS: [platform-swt-dev] AWT Toolkit using SWT (was: From Swing to
SWT))
Bob Foster wrote:
A cooperative GUI is one that is fully
introspective. this is done best thru a
structured object PropertyList. A class method introspector is insufficient.
It does not, for example, return the default value of a property. A method
signature is not a good way to expose to a non-engineer the "name" of a
property. See PropertyList at http://opendoors.com/conga/2.2/docs/javadoc/marimba/persist/PropertyList.html
for an example of the base class of the object which provides the property
state of an object instance tree.
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. PropertyList is not type neutral
as you will see from the API reference.
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. We agree that all properties must be
uniformly available to the Builder. User subclasses and the base Widget class
have all their properties materialized and edited thru a common Property
interface. An explicit state object, PropertyList, is what we use in Conga,
not introspection.
-Lane
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
--
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO
|