On Tue, 18 Mar 2003 08:45:31 +0000, Michael Seele wrote:
can't wait for the gui-builder!!! when do you start with this new feature???
I'd be keen on seeing a healthy discussion about how we, as developers would like to see this gui-builder.
Hopefully one that abstracts the GUI cleanly away from the logic, but doesn't hide the code compleatly. And makes use of Action classes not just ActionListeners.
i hope/belief that the intellij guys make a good job and implement a realy good novel gui-builder which only make java files and not special gui-builder files for you application...!!!
On Wed, 19 Mar 2003 07:51:39 +0000, Michael Seele wrote:
i hope/belief that the intellij guys make a good job and implement a realy good novel gui-builder which only make java files and not special gui-builder files for you application...!!!
Depends how they do it, an XML based gui descriptor could be ok, if it was a standard. Such as say XUL, the loader/actionbinder would have to be open source/lgpl thou.
when the gui-builder generate classes where you don't have the source it's really bad because when there is a bug you can't fix it. i hope the gui-builder don't make classes but java files where you can debug/change. else i don't use the gui-builder!!!
I really, really expect IntelliJ folks to code a GUI builder that decouples presentation from logic.
XML bindings seems to be the most logical solution: The whole layout is described in a XML file and then loaded/constructed during object creation. For you who have coded GNOME (C) applications, I'm talking about something like GLADE[1].
I've never used anything like Glade in Java, but a quick search on google for "java gui builders" showed up to proeminent projects: JEasy[2] and JGB[3], the last one being an open source. Hint: JetBrains could "adopt" the JGB project and make it really happens.
Here's what I think it's essential in IntelliJ GUI builder:
1) No code for layout. Layout description should not be part of the source code. XML descriptors looks like the best solution.
2) Full Swing compatibility and extensibility through JavaBeans. Everything said. The GUI builder should be able to manipulate all swing controls out of the box and also components that follows the JavaBeans specification.
3) Action support. The GUI builder should support and encourage the use of Action classes.
4) Custom Models support. The GUI builder should encourage the use of custom models for most swing components. It's well known that the use of the default models are the cause of much criticism on swing performance, so IntelliJ should encourage and facilitate the use of custom models.
I'm sure there are more points to it. Let's discuss about it here, to let JetBrains folks know what we want.
We already use our GUI builder internally but there are some things to be done before openning it to the public. I think you have to wait for about a month.
Can you share some information in terms of some of the discussion points in this thread? Things such as:
Is the code generated at the time of gui generation like what Cafe used to do? Is the code generated on the fly at run time? Is the code generated at the time of using gui builder much like NetBeans?
Answers to some of these questions will be very helpful. We have an internal project about to start to do meta-data based gui/forms development and if we get some idea as what you are doing, we can probably postpone/cancel the internal story.
On Wed, 19 Mar 2003 16:10:23 +0300, Valentin Kipiatkov wrote:
We already use our GUI builder internally but there are some things to be done before openning it to the public. I think you have to wait for about a month.
Anything you can "leak" about this info-wise at all?
GUI form is stored in an xml file. It's compiled to the .class files when you compile the project. No source code is generated into user's sources (although it's generated internally).
Can you share some information in terms of some of the discussion points
in this thread? Things such as: >
Is the code generated at the time of gui generation like what Cafe used to
do?
Is the code generated on the fly at run time? Is the code generated at the time of using gui builder much like NetBeans?
>
Answers to some of these questions will be very helpful. We have an
internal project about to start to do meta-data based gui/forms development and if we get some idea as what you are doing, we can probably postpone/cancel the internal story. > >
sorry, forgot something: - you cannot develop in other ides or only in the text-editor when you has used the gui-builder from IDEA!!! - you cannot compile the hole code outside IDEA. For example on another pc who has only a java compiler and a jdk!!!
don't know what kind of bug. i only know that i has made guis with C++ Builder from borland and there where often bugs in the gui-code which was generated from borland!!! you can't debug this code because it's compiled code!!!
But surely because the gui builder generates class files and not source, you will have no problems compiling your project that uses these gui classes that you have built, as long as you are using the same version of the jdk used to generate the classes?
Other ide's understand class files, so that won't be a problem either?
Michael Seele wrote:
sorry, forgot something: - you cannot develop in other ides or only in the text-editor when you has used the gui-builder from IDEA!!! - you cannot compile the hole code outside IDEA. For example on another pc who has only a java compiler and a jdk!!!
- you cannot develop in other ides or only in the text-editor when you has
used the gui-builder from IDEA!!!
- you cannot compile the hole code outside IDEA. For example on another pc
who has only a java compiler and a jdk!!!
I am quite shure there is a way to export to java code if necessary. As Valentin said, the source is generated internally for compile anyway. I greatly appreciate this approach as it releases one to deal with the messy generated GUI code altogether. If there is a nice way to plug in callbacks to the model code I just say : Wow!
GUI form is stored in an xml file. It's compiled to the .class files when you compile the project. No source code is generated into user's sources (although it's generated internally).
That's VEEERY bad - please provide an option to keep the source code. Although ideally we'd never modify the generated code if a builder is used in production, it can be the case that you do prototype and so you're happy with hacking away something.
ALSO, from a geek perspective I'll simply ignore the product if it won't build sources I can see - just for the sake of it.
i know that i can work with the class-files in other ide's or somewhere else. but it's better when you can compile the source-files and start the programm only with the generated code(preformance builds...)!!! when IDEA generates a source-file anyway, why we can't use this file???
GUI form is stored in an xml file. It's compiled to the .class files when you compile the project. No source code is generated into user's sources (although it's generated internally).
What about dynamic GUI forms ? I'm going to work on some project that needs dynamically generated forms. For instance, depending on the SQL data table I'm browsing, it should build a form dependent on the table structure, with special fields, drop-down lists, radio buttons, checboxes and the like. Isnt it a too static way of doing things to compile a class file from the XML representation ? Wouldn't it be possible to be able to create dynamic forms ? I'm thinking about a Jar file containing an API that would transform my dynamically generated XML representation of the form into a .class file containing the final GUI form. Am I dreaming ?
You will need to write your own code for dynamically generated forms. GUI builder may be used for static parts of the form. We might think about supporting dynamic forms in the builder but not for Aurora.
GUI form is stored in an xml file. It's compiled to the .class files
when
you compile the project. No source code is generated into user's sources (although it's generated internally).
>
What about dynamic GUI forms ? I'm going to work on some project that needs dynamically generated forms. For instance, depending on the SQL data table I'm browsing, it should
build
a form dependent on the table structure, with special fields, drop-down lists, radio buttons, checboxes and the like. Isnt it a too static way of doing things to compile a class file from the XML representation ? Wouldn't it be possible to be able to create dynamic forms ? I'm thinking about a Jar file containing an API that would transform my dynamically generated XML representation of the form into a .class file containing the final GUI form. Am I dreaming ?
GUI form is stored in an xml file. It's compiled to the .class files when you compile the project. No source code is generated into user's sources (although it's generated internally).
What versions of Swing/JDK will the GUI builder support (compile to)? Will the GUI builder e.g. include workarounds for problems with specifick JDK versions. Or will it require you to always run with the latest JDK.
GUI form is stored in an xml file. It's compiled to the .class files when you compile the project. No source code is generated into user's sources (although it's generated internally).
>
>
What versions of Swing/JDK will the GUI builder support (compile to)? Will the GUI builder e.g. include workarounds for problems with specifick
JDK versions. Or will it require you to always run with the latest JDK. >
You will need to write your own code for dynamically generated forms. GUI builder may be used for static parts of the form. We might think about supporting dynamic forms in the builder but not for Aurora.
Okay Valentin, thank you very much for your answer. And good luck for this complicated task ;) I'll be glad to beta-test this feature.
If I'm doing an automated build from outwith IDEA, will it be possible to do the build from the XML files, rather than having to store the class files in VSS (or whatever)?
It would be (far) preferable to store the "source" - i.e. the XML - in VSS.
Will you provide a standalone JAR which can be used by a build process, and an ANT task on top of that?
problems with specifick JDK versions. Or will it require you to always run with the latest JDK.
What kind of problems do you mean?
I was thinking of something like focus handling ? I seem to remember that it behaves (slightly) different in different JDK/Swing releases (1.3/1.4). Specific bugs in Swing might also require a workaround until it is fixed. Is there any lowest supported Swing version for the generated code?
On Tue, 18 Mar 2003 08:45:31 +0000, Michael Seele wrote:
I'd be keen on seeing a healthy discussion about how we, as developers
would like to see this gui-builder.
Hopefully one that abstracts the GUI cleanly away from the logic, but
doesn't hide the code compleatly. And makes use of Action classes not
just ActionListeners.
mmm
i hope/belief that the intellij guys make a good job and implement a realy good novel gui-builder which only make java files and not special gui-builder files for you application...!!!
On Wed, 19 Mar 2003 07:51:39 +0000, Michael Seele wrote:
Depends how they do it, an XML based gui descriptor could be ok, if it was
a standard. Such as say XUL, the loader/actionbinder would have to be
open source/lgpl thou.
Maybe.
when the gui-builder generate classes where you don't have the source it's really bad because when there is a bug you can't fix it. i hope the gui-builder don't make classes but java files where you can debug/change. else i don't use the gui-builder!!!
I really, really expect IntelliJ folks to code a GUI builder that decouples presentation from logic.
XML bindings seems to be the most logical solution: The whole layout is described in a XML file and then loaded/constructed during object creation. For you who have coded GNOME (C) applications, I'm talking about something like GLADE[1].
I've never used anything like Glade in Java, but a quick search on google for "java gui builders" showed up to proeminent projects: JEasy[2] and JGB[3], the last one being an open source. Hint: JetBrains could "adopt" the JGB project and make it really happens.
Here's what I think it's essential in IntelliJ GUI builder:
1) No code for layout. Layout description should not be part of the source code. XML descriptors looks like the best solution.
2) Full Swing compatibility and extensibility through JavaBeans. Everything said. The GUI builder should be able to manipulate all swing controls out of the box and also components that follows the JavaBeans specification.
3) Action support. The GUI builder should support and encourage the use of Action classes.
4) Custom Models support. The GUI builder should encourage the use of custom models for most swing components. It's well known that the use of the default models are the cause of much criticism on swing performance, so IntelliJ should encourage and facilitate the use of custom models.
I'm sure there are more points to it. Let's discuss about it here, to let JetBrains folks know what we want.
http://glade.gnome.org
http://www.jeasy.de
http://jgb.sourceforge.net
We already use our GUI builder internally but there are some things to be
done before openning it to the public. I think you have to wait for about a
month.
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Michael Seele" <jiveadmin@jetbrains.com> wrote in message
news:2242217.1047977131053.JavaMail.jrun@is.intellij.net...
feature???
really great news!!!
Can you share some information in terms of some of the discussion points in this thread? Things such as:
Is the code generated at the time of gui generation like what Cafe used to do?
Is the code generated on the fly at run time?
Is the code generated at the time of using gui builder much like NetBeans?
Answers to some of these questions will be very helpful. We have an internal project about to start to do meta-data based gui/forms development and if we get some idea as what you are doing, we can probably postpone/cancel the internal story.
Any plans for supporting TableLayout ?
Kind regards
Thomas G?lden
Munich, Germany
On Wed, 19 Mar 2003 16:10:23 +0300, Valentin Kipiatkov wrote:
Anything you can "leak" about this info-wise at all?
I hope that these features can be plugged in optionally. There are many who build only server-side applications and so a gui-builder is superfluous.
It is not only disk-space that I am concerned about but the ever increasing memory footprint.
Sri
+1 to that, I don't even want to look at the button or menu item
GUI form is stored in an xml file. It's compiled to the .class files when
you compile the project. No source code is generated into user's sources
(although it's generated internally).
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Vinay Moharil" <vmohar98@yahoo.com> wrote in message
news:3044562.1048088634917.JavaMail.jrun@is.intellij.net...
in this thread? Things such as:
>
do?
>
internal project about to start to do meta-data based gui/forms development
and if we get some idea as what you are doing, we can probably
postpone/cancel the internal story.
>
>
>No source code is generated into user's sources
that's bad. when there is a bug in the code the IDEA user can't debug the code!?
Hmm... What kind of bug? I don't imagine any bug in that code which could be
debugged. Any example?
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Michael Seele" <jiveadmin@jetbrains.com> wrote in message
news:170898.1048156358022.JavaMail.jrun@is.intellij.net...
code!?
sorry, forgot something:
- you cannot develop in other ides or only in the text-editor when you has used the gui-builder from IDEA!!!
- you cannot compile the hole code outside IDEA. For example on another pc who has only a java compiler and a jdk!!!
don't know what kind of bug. i only know that i has made guis with C++ Builder from borland and there where often bugs in the gui-code which was generated from borland!!! you can't debug this code because it's compiled code!!!
But surely because the gui builder generates class files and not source, you
will have no problems compiling your project that uses these gui classes
that you have built, as long as you are using the same version of the jdk
used to generate the classes?
Other ide's understand class files, so that won't be a problem either?
Michael Seele wrote:
used the gui-builder from IDEA!!!
who has only a java compiler and a jdk!!!
I am quite shure there is a way to export to java code if necessary.
As Valentin said, the source is generated internally for compile anyway.
I greatly appreciate this approach as it releases one to deal with the messy
generated GUI code altogether. If there is a nice way to plug in callbacks
to the model code I just say : Wow!
Ciao
...Jochen
Valentin Kipiatkov wrote:
That's VEEERY bad - please provide an option to keep the source code.
Although ideally we'd never modify the generated code if a builder is
used in production, it can be the case that you do prototype and so
you're happy with hacking away something.
ALSO, from a geek perspective I'll simply ignore the product if it won't
build sources I can see - just for the sake of it.
Please reconsider.
thanks,
Edo
i know that i can work with the class-files in other ide's or somewhere else. but it's better when you can compile the source-files and start the programm only with the generated code(preformance builds...)!!! when IDEA generates a source-file anyway, why we can't use this file???
"Valentin Kipiatkov" <valentin@intellij.com> a ?crit dans le message de
news: b5c4on$3lq$1@is.intellij.net...
What about dynamic GUI forms ?
I'm going to work on some project that needs dynamically generated forms.
For instance, depending on the SQL data table I'm browsing, it should build
a form dependent on the table structure, with special fields, drop-down
lists, radio buttons, checboxes and the like.
Isnt it a too static way of doing things to compile a class file from the
XML representation ?
Wouldn't it be possible to be able to create dynamic forms ?
I'm thinking about a Jar file containing an API that would transform my
dynamically generated XML representation of the form into a .class file
containing the final GUI form.
Am I dreaming ?
Guillaume Laforge
You will need to write your own code for dynamically generated forms. GUI
builder may be used for static parts of the form. We might think about
supporting dynamic forms in the builder but not for Aurora.
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Guillaume Laforge" <glaforge@reflexe.fr> wrote in message
news:b5c81v$b7s$1@is.intellij.net...
>
when
>
build
>
>
>
What versions of Swing/JDK will the GUI builder support (compile to)?
Will the GUI builder e.g. include workarounds for problems with specifick JDK versions. Or will it require you to always run with the latest JDK.
Sincerely
Jens Peter Grosen
I think any starting from JDK 1.2. Is there any significant difference from
the GUI builder's point of view?
JDK versions. Or will it require you to always run with the latest JDK.
What kind of problems do you mean?
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Jens Peter Grosen" <jiveadmin@jetbrains.com> wrote in message
news:12697126.1048163613326.JavaMail.jrun@is.intellij.net...
>
JDK versions. Or will it require you to always run with the latest JDK.
>
>
>
>
"Valentin Kipiatkov" <valentin@intellij.com> a ?crit dans le message de
news: b5c9bh$ecr$1@is.intellij.net...
Okay Valentin, thank you very much for your answer.
And good luck for this complicated task ;)
I'll be glad to beta-test this feature.
Guillaume
If I'm doing an automated build from outwith IDEA, will it be possible to do the build from the XML files, rather than having to store the class files in VSS (or whatever)?
It would be (far) preferable to store the "source" - i.e. the XML - in VSS.
Will you provide a standalone JAR which can be used by a build process, and an ANT task on top of that?
Of course we'll provide an ant task for build.
--
Best regards,
Mike Aizatsky.
-
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
I was thinking of something like focus handling ? I seem to remember that it behaves (slightly) different in different JDK/Swing releases (1.3/1.4).
Specific bugs in Swing might also require a workaround until it is fixed.
Is there any lowest supported Swing version for the generated code?
Sincerely
Jens Peter Grosen
"Mike Aizatsky" <mike@intellij.com> a ?crit dans le message de news:
b5cgae$ae$1@is.intellij.net...
So if there is a custom ant task, it means it could be possible to use that
to dynamically create GUI forms from dynamically created XML files ?
Guillaume Laforge