Skip to main content

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

Title: Message
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:
  1. If you modify the code, you must do it consistently with the way JBuilder expects to read the code.
  2. 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
-----Original Message-----
From: platform-swt-dev-admin@xxxxxxxxxxx [mailto:platform-swt-dev-admin@xxxxxxxxxxx]On Behalf Of Brad O'Hearne
Sent: Sunday, January 19, 2003 9:45 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))

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
-----Original Message-----
From: platform-swt-dev-admin@xxxxxxxxxxx [mailto:platform-swt-dev-admin@xxxxxxxxxxx] On Behalf Of Scott Stanchfield
Sent: Saturday, January 18, 2003 3:59 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))

I've got to totally disagree here... Round tripping is totally unnecessary if:
  1. You have a well-separated design
  2. You have a "good" UI builder (like the VCE in VisualAge for Java)
  3. 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
-----Original Message-----
From: platform-swt-dev-admin@xxxxxxxxxxx [mailto:platform-swt-dev-admin@xxxxxxxxxxx]On Behalf Of Brad O'Hearne
Sent: Friday, January 17, 2003 6:30 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))

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
-----Original Message-----
From: platform-swt-dev-admin@xxxxxxxxxxx [mailto:platform-swt-dev-admin@xxxxxxxxxxx] On Behalf Of Bob Foster
Sent: Friday, January 17, 2003 2:29 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))

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?


Back to the top