RE
"Especially if the tool is one that generates code, I think you have to
count on the fact that there will be a need to tweak
it
Why a
"need"? You're implying that if it generates resource
files that noone will ever need to tweak them, countering your own
first sentence...
What makes a resource file approach so darn powerful?
Noone has yet to answer
this...
AFAICS, a resource file based tool (or any that provides
generated-resource/code round tripping) is much more prone to lock-in. Look at
JBuilder -- they support code round tripping, but:
- If
you modify the code, you must do it consistently with the way JBuilder expects
to read the code.
- Because of #1, optimization and change of code-generation style is
pretty much a dead issue
(Resource files severely restrict what the user can modify, and the code
that builds the UI could change to be optimized. This is no different, IMHO,
than placing rules on if/how generated code can be tweaked.)
I'm a
compiler guy, and I liken this to modifying the ASM code generated by a
compiler. Imagine what would happen if people tweaked the ASM code and the
compiler had to re-read that code and figure out how to display it as "C" code.
That's exactly the same thing as round-tripping souce for a GUI
builder. If we wanted that support in a C compiler, people would be forced to
tweak such that the compiler could figure out what C statements their code
represented. Forget optimization, as most optimizations really mangle the ASM
code, so much that there's really no way to reverse it back to C (or at least
back to anything that even resembled the original C source).
That's
why my design is pluggable (easy to do, thanks to Eclipse)... This allows
different toolkits, persisted forms, visualizations, and styles of code
generation (including round tripping source code if someone else really wants to
write it.) If someone doesn't like the generated code, they can tweak
the code generator, not the generated
code.
RE:
alternate patterns
I'm
basing my tool around the style of visual programming used in VAJ (including
connections). The way you use the connections depends on the pattern you want to
use. In my book, Effective VisualAge for Java, I describe several
patterns that can be used in the VCE, and there are many more (and many yet to
come).
If
connections won't support the pattern you want to use, then AFAICS, no
available visual tool (that I'm aware of)
will support that pattern, and it's time to rethink UI
tools. Not a crazy thought at all; that will happen... I just don't see
it happenning for a while. By being very pluggable, I hope to
From
what I've heard of other tools in development, they're much more restrictive on
how you can use them...
-
Scott
I'll
kindly take issue. *ANY* tool, be it GUI or more general IDE,
case tool, etc., that assumes that its view of the world is the only one
that is needed, is almost bound to be wrong. Building a tool on the
philosophy that no one would ever have other needs is nearly
guaranteeing a problem down the road -- I would guess this is a pretty
common viewpoint from various IDE vendors, as a number of them seem to be
designed with such things in mind. Especially if the tool is one that generates code, I think you have to
count on the fact that there will be a need to tweak
it.
In fact, let me just throw out a crazy thought here
-- sure, MVC is the common design pattern for GUIs, but what if someone
comes up with an alternate pattern they wish to build around...is your tool
out the window?
BradO
I've got to totally disagree here... Round tripping is totally
unnecessary if:
- You have a well-separated design
- You have a "good" UI builder (like the VCE in VisualAge for
Java)
- You use some good strategies in that UI
builder.
I've written several UIs using VisualAge, and never had to
tweak the code. It's all about MVC and proper use of a good
tool...
--
Scott
Regarding this
point:
---
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 "round trip" (convert source/object code into the
representation used internally by the GUI
builder).
---
I disagree from the standpoint that you *do* have
to be able to round trip (but I don't think that this means parsing object
code). I think that visual presentation should be represented
separately from the behavior via meta-data -- and from the little I know,
this is the idea behind Conga. If presentation is manipulated via a
meta-data layer, then round-tripping should be fairly
straightforward. Moreover, it is the lack of round-tripping that
make commercial GUI builders fairly useless for anything but a 1st draft
skeleton model.
BradO
So where's your GUI builder? (Or Scott's,
for that matter? ;-)
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).
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.
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?
|