[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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))
It’s entirely
possible… it’s 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. I’m not sure this is the case in the
mentioned systems, but it’s 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