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?
|