Someone made a comment about tools having to bind directly to widgets
(due to lack of introspection). Introspection itself can be nice, but is usually
insufficient because you really want to add descriptions, possible enumeration
values, icons, and reasonable default values.
So
widgets that want to participate in a UI builder need some extra information.
For JavaBeans, that's the BeanInfo (though it falls short on default values).
For SWT, there may need to be something else (I haven't thought about BeanInfo
for SWT; it might be possible, but still not completely
sufficient). (This doesn't mean you could use SWT in a JavaBean builder,
but we might use BeanInfo as a common way to pass metadata).
Anyway, my point is that a BeanInfo approach or a PropertyList approach
still requires some custom metadata for use in a UI builder. Introspection
of a bare JavaBean class isn't sufficient for effective use in a UI
builder. It can serve as an ok starting point, but it misses some very
useful information.
I'll
look into the BeanInfo for SWT idea a bit more -- an alternate introspector
might be able to be created, though I'm sure there are some wrinkles. This would
definitely help when folks create custom components. Either that, or have an SWT
metadata tool that allows a user to specify metadata for their custom SWT
components....
--
Scott
> 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
|