[
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))
|
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