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
请先登录再写评论。
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
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
>>4. No generation of event handling code or data bindings. Generated is not usable to integrate with my own event handling code.
IIRC, in Java/Swing Actions are known to be THE framework.
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
Sorry, it was misleading terminology, by "painting" i meant "layouting".
Therefore: ACK
Regards,
Tom
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
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
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...
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?
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.
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 ;))
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).
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
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.
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.
On Mon, 02 Feb 2004 14:24:17 +0100, Thomas Singer wrote:
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.
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
On Tue, 03 Feb 2004 08:04:02 +0000, hmf wrote:
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.
"hmf" <hmf@qint.de> wrote in message
news:32123011.1075734044556.JavaMail.itn@is.intellij.net...
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.
And what about AUIML by IBM developped for eclipse?
http://www.alphaworks.ibm.com/tech/auiml