Questionable Gui Designer Concepts

After I have had another look at the Gui deisgner, I must say I am quite disappointed.

It uses several concepts that are absolute no-nos in the
projects I am working on:

1. Non standard layout managers, which are less functional than the standard layout managers.

2. Gui design not maintained as source, but rather in some
external file. (Windows gui resources are back to haunt us. Why do you think Microsoft has done away with them in .net??)

3. Source code generation that is absolutely awful. What drove you to use $$$setupUI$$$() as a method name?

4. No generation of event handling code or data bindings. Generated is not usable to integrate with my own event handling code.

I would appreciate if Jetbrains could elaborate on their
ideas behind the gui designer.

Until now every feature that Jetbarains has implemented has been very thorough, and I love the idea ide, but this miles below standard.

Regards
Hans Marggraff
http://www.qintsoft.com

15 comments
Comment actions Permalink

2. Gui design not maintained as source, but rather in some
external file. (Windows gui resources are back to haunt us. Why do you think Microsoft has done away with them in .net??)

Microsoft has done away with them in .net? Really? I don't think so:

With "Longhorn" (next version of Windows) the complete GUI for an .net
app will be saved in an separate XML-File (exactly like IDEAs gui-
builder does it) and at compile-time the corresponding GUI-Layout-code
will be created in the class-file that is bound to the GUI-XML-file
(exactly like IDEA does it).

This new .net-subsystem is called "Avalon" and you can find infos about
it at:
http://msdn.microsoft.com/longhorn/understanding/pillars/avalon/default.
aspx?pull=/msdnmag/issues/04/01/Avalon/default.aspx


There is an really really (!!!) cool/funny movie (live demo) about
"Avalon" at:
http://msdn.microsoft.com/msdntv/episode.aspx?
xml=episodes/en/20031028LHORNDB/manifest.xml

4. No generation of event handling code or data bindings. Generated is not usable to integrate with my own event handling code.

How can the GUI-Builder know what event-handling framework/code-style
(eg.: one anonymous listener per button or one big inner-class-listener
for all the buttons or ...) you will use (or what code-style your
company/project-team is dictating you)?
I think everything an GUI-Builder should do is creating the code that is
painting the gui and nothing more.


Regards,
Tom

0
Comment actions Permalink

>>4. No generation of event handling code or data bindings. Generated is not usable to integrate with my own event handling code.


How can the GUI-Builder know what event-handling framework/code-style
(eg.: one anonymous listener per button or one big inner-class-listener
for all the buttons or ...) you will use (or what code-style your
company/project-team is dictating you)?


IIRC, in Java/Swing Actions are known to be THE framework.

I think everything an GUI-Builder should do is creating the code that is
painting the gui and nothing more.


IMHO a GUI-builder should be a "visual layouter". Only the layout
should be stored externally, not how a component should look like or how
it is created.

Friendly,
Tom

0
Comment actions Permalink

I think everything an GUI-Builder should do is creating the code that is
painting the gui and nothing more.


IMHO a GUI-builder should be a "visual layouter". Only the layout
should be stored externally, not how a component should look like or how
it is created.

Sorry, it was misleading terminology, by "painting" i meant "layouting".
Therefore: ACK

Regards,
Tom

0
Comment actions Permalink

>>4. No generation of event handling code or data bindings. Generated is not usable to integrate with my own event handling code.


How can the GUI-Builder know what event-handling framework/code-style
(eg.: one anonymous listener per button or one big inner-class-listener
for all the buttons or ...) you will use (or what code-style your
company/project-team is dictating you)?


IIRC, in Java/Swing Actions are known to be THE framework.

ok --> one more option in:
How can the GUI-Builder know what event-handling framework/code-style
(eg.: one anonymous listener per button or one big inner-class-listener
for all the buttons or ONE ACTION PER BUTTON or ...) you will use (or
what code-style your company/project-team is dictating you)

;)

Regards,
Tom

0
Comment actions Permalink

What I wanted to express was, that some GUI-builders might offer the
ability to define listeners, but not to handle Actions. Also, often
actions are used to create components, which is not supported by a lot
of GUI-builders.

BTW, does anybody knows, what GUI-builder let you
- create the components yourself,
- stores the layout externally (e.g. xml-file) and
- allows easy obfuscation of the code (=> no class name must be used in
the xml-file)?

Tom

0
Comment actions Permalink

Other Ides have come up with usable concepts for this.
Intellij's source engineering technology is certainly capable of supporting both approaches. If even Borland can do it...

0
Comment actions Permalink

Yes, but they emphasize, that all the same things can also be done in code, which was very hard before .net.

And Jetbrains are not Microsoft. If anyone is in the position to create such a language for Java, then it is Sun.

Swing sources are the most solid accepted standard in this area. I can get programmers an literature for that standard, but not for Intellijs undocumented ad-hoc language.

This kind of vendor dependence is simply out of the question.

If xml definition of guis were such a good idea, then why isn't anyone using XUL?

0
Comment actions Permalink

Yes, but they emphasize, that all the same things can also be done in code, which was very hard before .net.

But the gui-designing-paradigma for longhorns .net will definitely be
XAML for GUI-Layout definitions (in most cases created by an gui-
builder-tool) and C#-code for event-handling.

And Jetbrains are not Microsoft. If anyone is in the position to create such a language for Java, then it is Sun.

ACK.
But anyone has to do the "first step". And JetBrains is known for many
innovative "first steps" they have done in the past and hopefully will
do in the future.
And I'm 100% sure that there will be an concrete JSR specified (and
implemented) in the near future for an XAML-like deklarative code-
layouting-language for Java.
(like Sun copied "syntactic sugar"-statements (foreach, enums,
Autoboxing, etc.) from .net/C# they will certainly copy XAML ;))

This kind of vendor dependence is simply out of the question.

full ACK.
That is one of my biggest complaints with IDEAs GUI-Builder. I know,
there is an free ant-task for compiling the XML-files, but in order to
visually design a gui I need IDEA at the moment (maybe someone is
writing an free GUI-Designer for IDEAs GUI-XML-dialect).

If xml definition of guis were such a good idea, then why isn't anyone using XUL?

Because time wasn't ready for that and the popular commercial GUI-
Frameworks (MFC/current .NET) offered no such possibillites.
In the apple-world (Mac OS X) everyone was/is creating (COCOA-)GUIs with
the "gui is stored in an xml-resource-file which is loaded and
interpreted at runtime"-paradigma for ages without
complaining/discussing. The same is true for Delphi.
It's simply much more flexible than the imho deprecated way of
programmatically layouting guis.
And with longhorns .net Microsoft (and every .net-GUI-application
developer) will definitely go the same way ("Avalon").

Regards,
Tom

0
Comment actions Permalink

Other Ides have come up with usable concepts for this.
Intellij's source engineering technology is certainly capable of supporting both approaches. If even Borland can do it...

Borland can do it, BUT JBuilder is dictating you the event-handling-
coding style (afaik one extra Method per Button which gets called from
one anonymous listener per button --> very ugly imho). If someone can
life with that IDE-dictated event-coding-paradigma - fine.

0
Comment actions Permalink

Swing sources are the most solid accepted standard in this
area. I can get programmers an literature for that
standard, but not for Intellijs undocumented ad-hoc
language.


That is the argument that we made back when we first saw the UI Designer. It initially fell on deaf ears because all we got as a response was "Build a plugin to generate source if you really want source", so I did (it'[s called GuiSource, check the plugin manager). JetBrains did add a switch to generate UI source, but after looking at the source it was clear that the plugin was still needed. This turned out to be a very religious argument with the folks who liked the JetBrains approach hell bent on making sure that source code could not be generated. Personally I think it should be like the rest of the things in Idea, user selectable, then everyone is happy.

0
Comment actions Permalink

On Mon, 02 Feb 2004 14:24:17 +0100, Thomas Singer wrote:

IIRC, in Java/Swing Actions are known to be THE framework.


Yet all other GUI builders inject anonymous ActionListeners amongst the
GUI contstruction/layout code. This is one of my biggest gripes with
Netbeans/JBuilder and the like. mixing the event code in the same place
as the design code.

0
Comment actions Permalink

Thank you, I will look at your GuiSource generator. Yes I was indeed surprised of the "religious fervour" in defence of Ideas approach.

However personal taste is not asked for here. The projects I work on are too large and long-lived to enable me to use ideas gui stuff. As a result I am paying for a feature that is useless.

I know of at least one European Fortune100 company that considered Idea and stayed with JBuilder for that reason.

Cheers Hans

0
Comment actions Permalink

On Tue, 03 Feb 2004 08:04:02 +0000, hmf wrote:

I know of at least one European Fortune100 company that considered Idea
and stayed with JBuilder for that reason.


Knowing that JBuilder likes you to use their own custom layouts and
databound controls in GUI apps, I wonder if they succombed to using those
as well, could make moving to ANYTHING a pain.

0
Comment actions Permalink

"hmf" <hmf@qint.de> wrote in message
news:32123011.1075734044556.JavaMail.itn@is.intellij.net...

Yes, but they emphasize, that all the same things can also be done in

code, which was very hard before .net.

That is not true, everything that can be done in Windows using resources,
can be done programmaticaly. But why one would write a code to handle a
simple dialog window? Resources, whether binary or XML, are very convenient.


0
Comment actions Permalink

And what about AUIML by IBM developped for eclipse?
http://www.alphaworks.ibm.com/tech/auiml

0

Please sign in to leave a comment.