Re: SWT History and Design Decisions (WAS: [platform-swt-dev] AWT Toolki

[Lane Sharman <lane@xxxxxxxxxxxxx>]

Christian Gruber wrote:

Mainly because with code-generation, you can’t actually be using the same objects in the builder as the user will see in the real-world, so you end up with a symbolic representation of the UI, and you have to compile-test-code-compile-test, etc.

 

With a standard, and highly configurable GUI and some state-saving mechanism (plain-text, xml, your-binary-format-du-jour, I don’t care), then you can have your builder actually manipulating the same objects live.  This drastically reduces the development cycle in my experience, having had to code the same app on Solaris/Motif, Windows, and NeXTSTEP back in the day.   The NeXTSTEP GUI was done and hooked into live working controllers while still in the Interface Builder app.  So could actually whiteboard with the stakeholders directly.  I cut weeks off of development, and what was produced had such a reduced maintenance cost compared to coded GUIs.

This is precisely how Conga works. just a fyi.

 

With that said, if you are transparently generating the GUI, and mandate no-tweaking (ie, use GUI Dev tool only) then you do get around the last point about code maintenance, as you should never have someone touch the code.  But using live instances during UI creation in my experience has an extreme shortening effect on the product development lifecycle.

 

You could still be flexible, if you needed a widget to be significantly different from the standard – but there, you subclassed the widget, did a proper development cycle on it, got it clean, THEN you gave it to the GUI builders.  It also allowed the GUI builders not to be coders, which meant you could have artists and people with Human Factors backgrounds but little programming actually doing what they’re supposed to.

 

It’s all preference at some level, people.  Let’s let this go.  Both are valid approaches with advantages and failings.  I just got annoyed by the “There are no advantages to non-generated GUIs” that Scott kept putting out there. ;)

When you start to work with stateful, evolvable, rewriteable representations
(GUI, a rule, et al), you get some terrific advantages at run time. This
is what Christian and i are discussing. A stateful, modifiable representation
regardless of physical format yields a different developer and end-user experience.

thanks,

Lane

 

Regards,

Christian.

 

 

-----Original Message-----
From: platform-swt-dev-admin@xxxxxxxxxxx [mailto:platform-swt-dev-admin@xxxxxxxxxxx] On Behalf Of Scott Stanchfield
Sent: Monday, January 20, 2003 8:34 AM
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))

 

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

-- 
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO