GUI designer, one more time?

Can somebody explain what is the main reason of having this GUI designer so complicated and not intuitive even for experienced developers?

A number of things trouble me the most:
1. No compile time check of binding between GUI element fields and mapped fields in the corresponding bound class
2. Need IDE every time when some changes are required to the either GUI element or bound class
3. Cannon reuse GUI element in the multiple classes, because nobody knows what is cooking inside
4. Very difficult implementation means a lot of bugs even for good team of Intellij

I asked already and want to ask again, why not to keep it simple? As far as I see, everything can be achieved by having simple but good Panel, JPanel, SWTPanel etc. builder and may be some kind of Menu, Jmenu, SWTMenu etc. builder and that is it. Every field should be accessible by standard getter method and events can be added latter if time left e.g. getFieldName().addEventLisyner(some ListenerClass))

If the goal is to keep the definition in the XML file it is still better to use the JSP approach, first generate java code then use standard compile to build the classes, it will make things more clear and possible for debugging.

Having all this in mind, the Idea team can concentrate on building GUI component instead of reinventing the wheel and patching byte code, BTW what they are going to do when SUN changes the compiler implementation or obfuscation is required?


On the other hand I might miss something, and what is done is really genius, which cannot be understood by ordinary person, or may be limited like myself.

0
70 comments

Hello,

It only first version :)
I belive that IntelliJ Team can make usability tool!

Source generation it no good idea, becose hard to track changes if you like to do some changes in generated code. Do you remember Rational Rose? :)

So making XML definition of form externaly - it no good too, becose XML can be changed by somebody else and it's not secure. The variant of:

This code will bottle nesk for hackers, becose xml definition may hold hidden fields or password fields.

And IntelliJ, for now time, choose BCEL for UI designer, maybe it's no good solution, but maybe good :)

I think we all must be patient and we must report our problems, than it help Intellij team to choose right solution.

Thank you!

0

Source generation it no good idea, becose hard to track changes if you like to do some changes in generated code.


I would say, generating source code during the build process
would be the best solution, because one would have the chance in the
future to get rid of the UIDesigner and continue to use this generated
source code.

Just my opinion: I would not use the UIDesigner, that cannot create
sources. I've seen so many necessary tool-switches in our different
products, that it would be too limiting to stick with this particular
UIDesigner forever.

Tom

0

Alexey Efimov wrote:

Source generation it no good idea, becose hard to track changes if you like to do some changes in generated code. Do you remember Rational Rose? :)


If you as a developer make manual changes to generated code, you're
shooting yourself in the foot and it's your own fault that it becomes
hard to track changes.

So making XML definition of form externaly - it no good too, becose XML can be changed by somebody else and it's not secure. The variant of:


So if the user changes the XML (which should be in a jar anyway) it
crashes the program. So what? It's their own damn fault for mucking
about with the innards of the application. You would get the same effect
if they edited the class files with a text editor!

   UIFactory.buildUIForm("myForm.xml");
> ]]>

This code will bottle nesk for hackers, becose xml definition may hold hidden fields or password fields.


I don't see the point of hidden fields in a form definition. And outting
security into your form definitions? That's not particularly wise in the
first place.

I think we all must be patient and we must report our problems, than it help Intellij team to choose right solution.


That's what all this discussion is about ;)

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://java.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: 416-643-4846 | Fax: 416-594-1919

0

If you as a developer make manual changes to generated code, you're
shooting yourself in the foot and it's your own fault that it becomes
hard to track changes.

But.... Is it true? :) Did you realy not make changes after forward
engeniring sometimes?
I not belive... You some generators will generate sourcecode, always someone
will change it, becose it not like him

So if the user changes the XML (which should be in a jar anyway) it
crashes the program. So what? It's their own damn fault for mucking
about with the innards of the application. You would get the same effect
if they edited the class files with a text editor!

Imagene that you have XML definition of user profile form with password
field. All this controls defined in XML in plain text format, and you can
change type
of field "password" to plain text field, after it you can read password.
If application fail after changes in XML - is good, but maybe changes in XML
will not crash the app...

I think we all must be patient and we must report our problems, than it

help Intellij team to choose right solution.
>

That's what all this discussion is about ;)


:))))

--
Alexey Efimov, Software Engineer
Sputnik Labs,
http://www.spklabs.com
"Gordon Tyler" <gordon.tyler@quest.com> wrote in message
news:bc7ihc$rh6$1@is.intellij.net...

Alexey Efimov wrote:

Source generation it no good idea, becose hard to track changes if you

like to do some changes in generated code. Do you remember Rational Rose?
:)
>
>

So making XML definition of form externaly - it no good too, becose XML

can be changed by somebody else and it's not secure. The variant of:
>

So if the user changes the XML (which should be in a jar anyway) it
crashes the program. So what? It's their own damn fault for mucking
about with the innards of the application. You would get the same effect
if they edited the class files with a text editor!

>

 >   UIFactory.buildUIForm("myForm.xml");
> > ]]>

This code will bottle nesk for hackers, becose xml definition may hold

hidden fields or password fields.
>

I don't see the point of hidden fields in a form definition. And outting
security into your form definitions? That's not particularly wise in the
first place.

>

I think we all must be patient and we must report our problems, than it

help Intellij team to choose right solution.
>

That's what all this discussion is about ;)

>

Ciao,
Gordon

>

--
Gordon Tyler (Software Developer)
Quest Software <http://java.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: 416-643-4846 | Fax: 416-594-1919

>


0

I do not like to have UI to be generated as plain Java code.

Disatvantages:

  • Need to regenerate source code each time UI is changed, thus manual tweaks

are impossible

  • Need to parse source code to show the form in the UI designer. And it is

much harder to parse Java code, than to parse resource file of standartized
format.

  • If I need to change the size or arrangement of the components, or even

pictures or text, I have to recompile. Ok, I can load pictures and text from
resource bundle, but still.

I do not like some hidden hacks and bytecode patches either. But at least I
like the separation of UI and code.

I prefer the simple old resource files (ok, let them be XML resource files)
which can be modified separately, or even if the resouces are within the
executable file. If I use "non-standard" UI builder, then all I want to get
with is the designer, which creates proprietary resource file, and a
library, which handles this resource file. So, I can write something like
loadResource() in my code, and the library would create the corresponding UI
class structure. The library should allow me to address to the components
and to manipulate them. Looks like this is what IDEA UI Builder does, but I
DO NOT like hidden bytecode manipulation.

And I just love Delphi approach of "rich" resource file.

"Thomas Singer" <thomas.singer@NOregnisSPAM.de> wrote in message
news:cbieev4k8j04vh1kdv33cicam9p85rfnu1@4ax.com...

Source generation it no good idea, becose hard to track changes if you

like to do some changes in generated code.
>

I would say, generating source code during the build process
would be the best solution, because one would have the chance in the
future to get rid of the UIDesigner and continue to use this generated
source code.

>

Just my opinion: I would not use the UIDesigner, that cannot create
sources. I've seen so many necessary tool-switches in our different
products, that it would be too limiting to stick with this particular
UIDesigner forever.




0

>I do not like to have UI to be generated as plain Java code.

I guess, I wasn't clear enough. I do not want to get the source code
generated in the project, only as an intermediate step of the
build-process.

>* Need to regenerate source code each time UI is changed, thus manual tweaks
>are impossible

This is necessary with the byte-code manipulation, too.

>* Need to parse source code to show the form in the UI designer. And it is
>much harder to parse Java code, than to parse resource file of standartized
>format.

No, the source code does not holds the information, its just output of
the build-process.

Tom

0

I guess, I wasn't clear enough. I do not want to get the source code
generated in the project, only as an intermediate step of the
build-process.


Hmm.... Let's take a look how Delphi works (I might forget something,
haven't used it for 3 years).

All "forms" inherit from Form class. Why this is good? Because it is
Borland's own class. So Delphi can do some basic common window
initialization there, and also hide window proc in there. Why IDEA forms
should inherit standard JPanel? I think, all IDEA forms should also inherit
one and the only base UI class, which is provided by IntelliJ, not by Sun or
whoever else.

Now, Delphi class, associated with form, consists of two parts: first part
contains private fields, corresponding to window controls. One should not
delete them. Once the field is deleted, the control is removed from the form
(two-way editing, works so smooth! Just love it). But one can do whatever he
wants in the implementation section.

When you add control to a Delphi form, it adds a private field in the source
code file. Each control has name, which is basically a variable name in the
class file, and a textual description. See, how easy is that comparing to
boring binding thing: drop control, name it, and the private field of the
proper type would appear in the source file, no binding is necessary because
it already has proper name. Cool, eh?

And now you can do whatever you want in the implementation section, from
manipulating field properties (its type is already known) to getting window
handle and going wild.

So, I do not see the point in the binding process, this is so Windows 3.0.
Hey, it is 2003, not 1985.

I do not see the point in the bytecode patching either, because my form
inherits standard Form class. If someone does not like handling resource
file in runtime and to use proprietary libraries for this, then Form class
(I mean, each particular instance of it) is the perfect place to contain all
my controls, which I dropped on the form, and THIS class should be generated
under the scenes. In this case for each UI form IDEA would create two
*.class files: one is compiled from visible to the user custom form with
handlers, and another is generated and compiled from the form definition.

If someone prefer to use resources instead (and to be able to patch them in
the compiled app), then base Form instance would contain mapping between
fields in my custom class and the form resource. In this case the support
library would be needed.

Does it make sense?


0


"Alexey Efimov" <aefimov@spklabs.com> wrote in message
news:bc7j3u$sfk$1@is.intellij.net...

So if the user changes the XML (which should be in a jar anyway) it
crashes the program. So what? It's their own damn fault for mucking
about with the innards of the application. You would get the same effect
if they edited the class files with a text editor!

Imagene that you have XML definition of user profile form with password
field. All this controls defined in XML in plain text format, and you can
change type
of field "password" to plain text field, after it you can read password.
If application fail after changes in XML - is good, but maybe changes in

XML

will not crash the app...


Have you ever changed resources in compiled Windows executable? This is so
neat and sometimes very, very useful. I like to have the ability to change
the resources at the runtime. The point is, that in windows exe resources
are hidden better from the ordinary user, then in a java app. Even if you
ship jar file, it can be opened by WinZip. So the bigger point is to make
better format for java executable.


0

The GUI Designer could give me the option of using the .form resources or generating code. I see advantages to each method.

Need to regenerate source code each time UI is changed, thus manual tweaks

are impossible

This cuts both ways. I have yet to see a situation that I could tweak code and then manage it in a GUI editor.

Need to parse source code to show the form in the UI designer. And it is
much harder to parse Java code, than to parse resource file of standartized format.


So store the form config in the resource file and have the option to generate the form to code. That way users can have dynamic editing, and if they want to cut loose of the tool they can generate code.

I do not like some hidden hacks and bytecode patches either. But at least I
like the separation of UI and code.


I totally agree. However, this separation could be achieved just by separating into separate java classes.

0

This cuts both ways. I have yet to see a situation
that I could tweak code and then manage it in a GUI
editor.


This might sound heretical, but I find the Netbeans GUI builder pretty reasonable. You get a fair amount of control in the GUI builder, where it allows you to insert your own code in various places.

I regularly use Netbeans and IDEA together, on the same source code at the same time, when building UIs. Netbeans' internationalization wizard and GUI builder work well for me, while IDEA is tops for everything else. I find it a productive combination, and the GUI construction is done by code which Netbeans generates (with your code interspersed here and there as you specify). It's a fairly productive combination, as long as you have enough memory :)



0

I really like the direction that Intellij is taking. It reminds me of the approach taken by Interface Builder from NeXT. Now, let's be conscious of the fact that it is a first alpha release and, therfore

1. No compile time checking of binding ...
This can be done at compile time. I don't see the diffculty posed by separating gui layout and code. When compiling a form, IDEA would check whether the bindings exist. In fact, Intellij could also provide a Java tool such that the checking can be done in an Ant script.

2. Need IDE every time when some chanages are required ...
If the XML format is well documented, one can edit the form file directly. When I used to do EJB development using Weblogic, I always created the xml files manually.

3. Cannot reuse GUI element...
This is because the API is not documented. Furthermore, I would rather make calls like UIFactory.loadForm(comp) and UIFactory can then use introspection to bind component instead of the current mechanism of some under handed trickery pulled by idea.jar. This situation is no different from Interface Builder; one can create a component and embed in another component. Consequently, let's not call it form. A form is top level UI component and, thus, it imples that it cannot be embedded into another component.

4. Very difficult implementation means a lot of bugs...
Well, this tool is immature at this stage. I would even venture to say implementing a language parser is also relatively difficult and this does not prevent people from writing good parsers.

My personal observations
1. Use Interface Builder's event binding mechnism; it is intuitive. However, the tool should allow more than just control action binding (this is one of my major gripe against IB). VisualAge way of event binding is preferrable because it is self-documenting and easy to use. Otherwise, why not just have a plugin that can use Netbean's GUI designer from within Intellij? Almost every GUI tool nowadays use a two column table to represent event binding. This is usable but not very self documenting because you cannot see all of the senders and receivers of events in the form in one glance. You would have to click every GUI object to see if it generates events.

2. I would even suggest copying IB's (or VisualAge's) look and feel. These are proven tools and use a paradigm that is tried and true.

3. Release Intellij's GUI roadmap to us so that we can critique it before they spend a bunch of time and resources implementing something no one would use. GUI designers are not cutting edge technology and people have tried numerous different paradigms. Therefore, I don't think releasing a roadmap would jeopardize Intellij's business advantage.


0

On Wed, 11 Jun 2003 23:23:32 +0000, Krasna Halopti wrote:

I regularly use Netbeans and IDEA together, on the same source code at the
same time, when building UIs. Netbeans' internationalization wizard and
GUI builder work well for me, while IDEA is tops for everything else. I
find it a productive combination, and the GUI construction is done by code
which Netbeans generates (with your code interspersed here and there as
you specify). It's a fairly productive combination, as long as you have
enough memory :)


Careful you don't get hit with the problem I've hit ( and have added to
the tracker ). A project I'm working on has Netbeans based .form's in the
CVS tree, IDEA picked up these and complains of an unexpected element.

Sadly, neither Netbeans nor IDEA's XML files provide any DocType's or
DTD/XSD references to match against ;(

Sadly, this means the project can't be built/compiled/debugged by IDEA.

Mark


--
...turn to the light - don't be frightened by the shadows it creates,
...turn to the light - turning away could be a terrible mistake
...dream theater - the great debate


0

On Thu, 12 Jun 2003 04:54:29 +0000, Futeh Kao wrote:

1. Use Interface Builder's event binding mechnism; it is intuitive.
However, the tool should allow more than just control action binding (this
is one of my major gripe against IB). VisualAge way of event binding is
preferrable because it is self-documenting and easy to use. Otherwise,
why not just have a plugin that can use Netbean's GUI designer from within
Intellij? Almost every GUI tool nowadays use a two column table to
represent event binding. This is usable but not very self documenting
because you cannot see all of the senders and receivers of events in the
form in one glance. You would have to click every GUI object to see if it
generates events.


And use Action classes, as well as ActionListeners ( or instead of ).


--
...turn to the light - don't be frightened by the shadows it creates,
...turn to the light - turning away could be a terrible mistake
...dream theater - the great debate


0

In this case for each UI form IDEA would create two
*.class files: one is compiled from visible to the user custom form with
handlers, and another is generated and compiled from the form definition.
Does it make sense?


You made me think of the following thing :
The problem for JetBrains is if people change the generated source code,
right ?
So, as there are custom editors for Form UI files, as soon as we "bind" a
form to a class, they could simply prevent the user from editing that file
by locking it ! And if in any case he/she modifies it externally, the file
would be regenerated from the form file.
And if the user wants to customize that somewhat, he/she would simply
subclass it and make appropriate changes.
At least, the source file would exist (in source code format), and if 10
years from now they want to modify that application, they would be able to
dive into the source code, rather than using an old piece of ant task and
aging libraries for regenerating the byte-code-weaved classes.

Would it make sense ?

Guillaume Laforge


0

>1. Use Interface Builder's event binding mechnism; it is intuitive.

I don't know Interface Builder, but wouldn't it be better to separate
the layout (form) from the event handling? IMHO, the listeners should
be attached in the class explicitely.

Tom

0

Since the GUI builder would be open sourced, and the format would stabilize after a few
builds, nothing would stop anyone with creating alternative implementation of the Ant task
which would use reflection or/and dynamic form loading.

Any volunteers?

-- dimiter

0

Since the GUI builder would be open sourced


I guess that only compilation/runtime part of code has big chances to be
open sources. Builder itself has less chances :) .

--
Best regards,
Mike Aizatsky.
-


JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


0

I agree with Thomas 1000% (that's one thousand percent, not a typo). Holding the definition of the UI in an XML file is a reasonable solution to the problems associated with trying to parse and understand UI code in the editor (especially if someone has changed that code by hand outside of the editor), but I would like to see source code generated from the XML at build time (or even better yet, as a seperate option off of the build menu with the ability to have the regular build process optionally generate the UI source before beginning each build). That way I have the source and if I need to work with it outside of Idea I can, or more importantly, if I have to provide the source code to a customer as a deliverable under a contract then they can do whatever they like with the source using whatever editor/ide they want to. I would still like to be able to edit the generated source code with Idea, but with the caveat that if I regenerate the code from the XML, my changes will be lost. This will support the needs of those who want to only use GUI designer to create and modify forms as well as the needs of those who don't want to use a GUI designer for anything but the initial creation of the form (not to mention the real die hards who don't believe in using a GUI designer at all).

As for the byte code manipulation, I do not like this at all! The argument I hear for it is that Javac does it so why shouldn't Idea. The answer is that Javac is a compiler and compilers are supposed to produce byte code (and in certain cases, like optimization, modify it). An editor is supposed to produce source code. I would rather see a system where the programmer adds the required code to the source themselves, possible with the help of a new feature that is similar to the existing "generate source" features in Idea like "surround with".

My 0.02 cents worth.

0

Ralph Saunders wrote:

As for the byte code manipulation, I do not like this at all! The argument I hear for it is that Javac does it so why shouldn't Idea. The answer is that Javac is a compiler and compilers are supposed to produce byte code (and in certain cases, like optimization, modify it). An editor is supposed to produce source code. I would rather see a system where the programmer adds the required code to the source themselves, possible with the help of a new feature that is similar to the existing "generate source" features in Idea like "surround with".

My 0.02 cents worth.


And GUIBuilder is supposed to produce UI interface not a code.
I like the current approach as long as it works correctly. This is a
really nice separation of the logic and UI and most of the time I don't
care how gui construction code looks like, just like most of the time I
don't care how my app server implements remove object and home
interfaces of my session beans.

/kesh

0

And what do you think of the following approach (copy'n paste from my answer
to Michael) :

>So, as there are custom editors for Form UI files, as soon as we "bind" a
>form to a class, they could simply prevent the user from editing that file
>by locking it ! And if in any case he/she modifies it externally, the file
>would be regenerated from the form file.
>And if the user wants to customize that somewhat, he/she would simply
>subclass it and make appropriate changes.
>At least, the source file would exist (in source code format), and if 10
>years from now they want to modify that application, they would be able to
>dive into the source code, rather than using an old piece of ant task and
>aging libraries for regenerating the byte-code-weaved classes.

Wouldn't it be better to have the source code generated but that we could
not modify (even externally speaking) ?
The source file would be overwritten each time the project builds.
And if you really wish to do some tweaks, you'd have to tweak a subclass of
this generated class.
Wouldn't it be better for everybody ?

Guillaume Laforge


0

And GUIBuilder is supposed to produce UI interface not a code.

It is supposed to produce a user interface; the problem here is, how it does it.

Extra build tools that will need updating? Hacking into compiled bytecode? And this is just to prevent folk from playing with the code? How about just generating the code with a comment that says "DON'T PLAY WITH THIS CODE!" Wouldn't that be easier?

+This is a really nice separation of the logic and UI and most of the time I don't
care how gui construction code looks like, just like most of the time I don't care how my app server implements remove object and home interfaces of my session beans.+

I think you can take this notion too far. At some point I would like to look at the code and see some relationship between the form and the code. Even if it's just a call to display it.

0

This is a really nice separation of the logic and UI and most of the time

I don't

care how gui construction code looks like


Source code also has another advantage: begginers (and even advanced) swing
users can learn a lot jus't by looking at the generated code - even if it's
badly written.



0


"Guillaume Laforge" <glaforge@reflexe.fr> wrote in message
news:bc9apm$cn0$1@is.intellij.net...

In this case for each UI form IDEA would create two
*.class files: one is compiled from visible to the user custom form with
handlers, and another is generated and compiled from the form

definition.

Does it make sense?

>

You made me think of the following thing :
The problem for JetBrains is if people change the generated source code,
right ?
So, as there are custom editors for Form UI files, as soon as we "bind" a
form to a class, they could simply prevent the user from editing that file
by locking it ! And if in any case he/she modifies it externally, the file
would be regenerated from the form file.


I do not like the idea of binding at all. All I want is to drop a component
on the form, and to get a field of the proper type in my source file. If I
rename the object in the UI editor, the variable is renamed too (with all
its usages, should not be a big deal for IDEA). If I remove field from the
class, the component (and all contained components) is removed from the
form. My class would be the owner of all form components, even if the form
itself is not a direct parent for all of them. Again, Delphi rules.

And if the user wants to customize that somewhat, he/she would simply
subclass it and make appropriate changes.


Form always should be subclassed. I have event handlers and I do whatever I
want in my subclass (except removing fields, if I do it component is
removed). And full Java code for UI components is generated in the parent
class. I always get two classes for one visual form.

Btw, Delphi allows to inherit forms visually. How about this feature in IDEA
UI builder?

At least, the source file would exist (in source code format), and if 10
years from now they want to modify that application, they would be able to
dive into the source code, rather than using an old piece of ant task and
aging libraries for regenerating the byte-code-weaved classes.


Before Borland decided to provide tools to obtain source code for DFMs, a
lot of tools were created to reverse-engineer Pascal code from DFM files. I
am pretty sure that IDEA community will do the same for IDEA if it would be
needed :)



0

I disagree with your assertion that a GUI builder should not produce source code. That is like saying that the editor should not produce source code.

Again, i am not opposed to having the GUI definition stored in an XML file, what i am opposed to is being in a position where I (or my customer) cannot modify the GUI without using some propriatary tool.

0


"Ralph Saunders" <jiveadmin@jetbrains.com> wrote in message
news:27391577.1055435731574.JavaMail.itn@is.intellij.net...

I disagree with your assertion that a GUI builder should not produce

source code. That is like saying that the editor should not produce source
code.
>

Again, i am not opposed to having the GUI definition stored in an XML

file, what i am opposed to is being in a position where I (or my customer)
cannot modify the GUI without using some propriatary tool.

Can you modify winapp GUI without resource editor? And even if you have
resource editor, some RCDATA sections may be illegible for you. So what? You
take this as given, right? How Java app is different?


0

I didn't build winapp GUI, but if I had, as a developer I would want to be able to modify it without being required to use some propriatary tool. The only way to achieve this is to have ALL the source code.

Hiding things from developers is a very, very bad thing because it just ends up creating developers that don't know what is going on, they just know "what button to press".

0

This is an approach i could live with. It would be nice if I could decide when to regenerate the UI code, as opposed to having it automatically regenerated every time I do a build, but at least I could turn over the source code to a customer and they would be able to modify it as they see fit using Idea or any other IDE or editor that they want to.

0


"Ralph Saunders" <jiveadmin@jetbrains.com> wrote in message
news:4596140.1055436509665.JavaMail.itn@is.intellij.net...

I didn't build winapp GUI, but if I had, as a developer I would want to be

able to modify it without being required to use some propriatary tool.
The only way to achieve this is to have ALL the source code.
>

Hiding things from developers is a very, very bad thing because it just

ends up creating developers that don't know what is going on, they just know
"what button to press".

How's that? one exactly knows what happens: the resource is loaded from the
resource storage, this is it. One can add resource manually or use fancy
tools, this does not change what happens under the hood. And because
resources are defined with a separate "language", one may not want to know
about it, if all that he needs is just to put two edit fields and two
buttons on a dialog.

You do not manually create EJB objects for your remote definitions, do you?

The only question is about resource editor for IDEA UI, but I guess IntelliJ
will provide it. Or someone else ;)


0

>Wouldn't it be better to have the source code generated but that we could
>not modify (even externally speaking) ?
>The source file would be overwritten each time the project builds.
>And if you really wish to do some tweaks, you'd have to tweak a subclass of
>this generated class.
>Wouldn't it be better for everybody ?

The GUI builder should have 3 "views":
- the visual view, where one can drag-and-drop components and gets and
impression, how it'll look like,
- the xml view (the storage format),
- the intermediate, read-only source code (not stored!), that is --
for instance -- useful for debugging

Am I right?

Tom

0

...and your "only question" is exactly why I am opposed to the approach, namely that it requires some speical tool to change the UI. If a user of the IDE doesn't want to know what is going on then they can simply not look at the code. My opposition is to the approach of not producing source code from the XML definition file.

0

Please sign in to leave a comment.