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).
:o(
But before I start flaming, I'd like to ask a few questions about it: 1) What sort of XML is it? Is it a proprietary XML format or some sort of a standard? I know there are some project that are using XML to describe GUI in one way or another... the idea in itself is fine IMHO but there doesn't seem to be any sort of standard. Is this XML format "human friendly"? In other words, will I be able to read through the XML files and get a grasp on what will be displayed without actually needing the GUI builder to show me? It seems that IntelliJ will introduce some sort of a proprietary XML format here... Will this format be opened up to the community (I could even think of starting a community to define an industry standard!)?
2) As has been said already, Ant tasks are an absolute must and the "compiler" must be loosly coupled with IDEA in order to set up a build box without having to install IDEA on that machine.
Will you be providing a standalone JAR which you can copy and put in your classpath, or will you have to have IDEA installed on your build machine?
I believe Mike already told me in an earlier thread that they will provide the "compiler" as a standalone downloadable product (I'm hoping it will just require a valid IDEA license file). He said you won't have to install IDEA on your build machine.
And what about people who don't use Ant in their build process, but want to access the functionality?
It would be nice if IntelliJ could provide a command-line interface to the compiler in addition to the Ant task.
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
So would you need a separate license for your build machine, or else make sure you're not running IDEA at the time with the same license? Maybe it doesn't do the check for "Is IDEA already running with this license?".
Regarding command line, it might also be useful to have a Java API into the compiler, as well as command-line and an Ant task.
Hmm... What kind of bug? I don't imagine any bug in that code which could
be
debugged. Any example?
It's clear that allthough idea is feature full, most things aren't gui intensive. This is clearly visible for example in the very basic handling of events/gui constructs in IDE Options, Project options, etc.
Note that I think this is as it should be:
IDE Options and/or Project Options are used only once in a while, so a very polished interface isn't necessary.
On the other side, writing code is done constantly, so very polished/precise refactorings, intentions, etc is a must.
But, when writing an app gui intensive, there are many problems that can only be resolved by debugging the gui framework. I recently recompiled the jdk sources with the debug switch, only so that I could debug LookAndFeel actions, renderers, swing events, etc.
I also think that a sourcepath for the generated gui files is a must.
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.
>
Guillaume Laforge
The need of a .class isn't strictly necessary. My framework reads the directly the xml file and creates the gui at runtime.
For simple forms, there's no apparent delay (to the user) while reading/creating the form.
Complex forms (300+ gui elements) have a slower creation time. The problem isn't so great, as for these kind of forms, the time spent getting the data from the backend is so high that the creation time (in the background) of the form isn't significant.
1) It's a propietrary XML format. You might edit it manually if you want but it's not a preferrable way of doing development :-). 2) What's the problem with installing IDEA on the build machine?
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).
>
:o(
>
But before I start flaming, I'd like to ask a few questions about it: 1) What sort of XML is it? Is it a proprietary XML format or some sort of
a standard? I know there are some project that are using XML to describe GUI in one way or another... the idea in itself is fine IMHO but there doesn't seem to be any sort of standard. Is this XML format "human friendly"? In other words, will I be able to read through the XML files and get a grasp on what will be displayed without actually needing the GUI builder to show me?
It seems that IntelliJ will introduce some sort of a proprietary XML
format here... Will this format be opened up to the community (I could even think of starting a community to define an industry standard!)? >
2) As has been said already, Ant tasks are an absolute must and the
"compiler" must be loosly coupled with IDEA in order to set up a build box without having to install IDEA on that machine. >
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.
>
Guillaume Laforge
>
The need of a .class isn't strictly necessary. My framework reads the directly the xml file and creates the gui at runtime.
>
For simple forms, there's no apparent delay (to the user) while reading/creating the form.
>
Complex forms (300+ gui elements) have a slower creation time. The problem isn't so great, as for these kind of forms, the time spent getting the
data
from the backend is so high that the creation time (in the background) of the form isn't significant.
The first problem with installing IDEA on the build machine is simply the license fee. The second problem is that it's not just the build machine, it's also the development machines of every developer who doesn't wish to use IDEA as their primary development environment. Yes, there are philistines out there who prefer different development environments, and many of us have to work with them. If I told the Eclipse or CodeGuide (or emacs!) users on my team that they would have to install IDEA to be able to build and test, they would be justifiably outraged. The third problem is that it makes it impossible to use the EAP in day-to-day work, since the results of flaky builds (and something like 20% of EAP builds are flaky) are no longer limited to the developer's desktop. I'm a big fan of the EAP process, but I'm certainly not going to use an EAP build as a component of a production build environment. That's just not going to happen. Unless you're very careful about your translator, this means that I couldn't use an EAP on my development environment, and expect to get the same results. That's entirely too much risk, so if I were to use your GUI-builder I would have to drop out of EAP, and I wouldn't be the only one.
On a more technical note, if Swing components are created in obfuscated class files, what are the odds that those class files will be instrumented so as to work cleanly with automated test tools. A previous company I worked for used the java.awt.Robot class extensively to write automated tests which exercised Swing functionality. These worked great, assuming that you are able to name or otherwise reference the individual components. If that isn't possible with your generated GUI classes, we would not have been able to test.
If this is what IntelliJ is planning for it's GUI generator, I would be forced to recommend against using this technology on any critical or important work project. Any tool which places extra burdens on the build or testing process is simply unacceptable for production use, if alternatives are available. Similar arguments apply to your proposed AspectJ support.
I love you guys, and do believe you've made the best IDE that's ever been. A lot of that has been because IDEA specifically didn't try to control the entire development process. Going down the road you seem to be planning risks that, and could easily backfire.
(Did I just cost myself my chance at an Aurora "thank you" license?)
The first problem with installing IDEA on the build machine is simply the license fee. The second problem is that it's not just the build machine, it's also the development machines of every developer who doesn't wish to use IDEA as their primary development environment. Yes, there are philistines out there who prefer different development environments, and many of us have to work with them. If I told the Eclipse or CodeGuide (or emacs!) users on my team that they would have to install IDEA to be able to build and test, they would be justifiably outraged. The third problem is that it makes it impossible to use the EAP in day-to-day work, since the results of flaky builds (and something like 20% of EAP builds are flaky) are no longer limited to the developer's desktop. I'm a big fan of the EAP process, but I'm certainly not going to use an EAP build as a component of a production build environment. That's just not going to happen. Unless you're very careful about your translator, this means that I couldn't use an EAP on my development environment, and expect to get the same results. That's entirely too much risk, so if I were to use your GUI-builder I would have to drop out of EAP, and I wouldn't be the only one.
On a more technical note, if Swing components are created in obfuscated class files, what are the odds that those class files will be instrumented so as to work cleanly with automated test tools. A previous company I worked for used the java.awt.Robot class extensively to write automated tests which exercised Swing functionality. These worked great, assuming that you are able to name or otherwise reference the individual components. If that isn't possible with your generated GUI classes, we would not have been able to test.
If this is what IntelliJ is planning for it's GUI generator, I would be forced to recommend against using this technology on any critical or important work project. Any tool which places extra burdens on the build or testing process is simply unacceptable for production use, if alternatives are available. Similar arguments apply to your proposed AspectJ support.
I love you guys, and do believe you've made the best IDE that's ever been. A lot of that has been because IDEA specifically didn't try to control the entire development process. Going down the road you seem to be planning risks that, and could easily backfire.
(Did I just cost myself my chance at an Aurora "thank you" license?)
I wonder if I were forced to create Win32 GUI application, how would I unit-test my GUI created by Window Resource Editor? Would I need it? I guess not. Simple because it doesn't make much sense. What definitely I'd like to test is the code that manipulates these GUI components. If that is possible with your GUI builder, I'll be happy to use it.
The first problem with installing IDEA on the build machine is simply the license fee. The second problem is that it's not just the build machine, it's also the development machines of every developer who doesn't wish to use IDEA as their primary development environment. Yes, there are philistines out there who prefer different development environments, and many of us have to work with them. If I told the Eclipse or CodeGuide (or emacs!) users on my team that they would have to install IDEA to be able to build and test, they would be justifiably outraged. The third problem is that it makes it impossible to use the EAP in day-to-day work, since the results of flaky builds (and something like 20% of EAP builds are flaky) are no longer limited to the developer's desktop. I'm a big fan of the EAP process, but I'm certainly not going to use an EAP build as a component of a production build environment. That's just not going to happen. Unless you're very careful about your translator, this means that I couldn't use an EAP on my development environment, and expect to get the same results. That's entirely too much risk, so if I were to use your GUI-builder I would have to drop out of EAP, and I wouldn't be the only one.
On a more technical note, if Swing components are created in obfuscated class files, what are the odds that those class files will be instrumented so as to work cleanly with automated test tools. A previous company I worked for used the java.awt.Robot class extensively to write automated tests which exercised Swing functionality. These worked great, assuming that you are able to name or otherwise reference the individual components. If that isn't possible with your generated GUI classes, we would not have been able to test.
If this is what IntelliJ is planning for it's GUI generator, I would be forced to recommend against using this technology on any critical or important work project. Any tool which places extra burdens on the build or testing process is simply unacceptable for production use, if alternatives are available. Similar arguments apply to your proposed AspectJ support.
I love you guys, and do believe you've made the best IDE that's ever been. A lot of that has been because IDEA specifically didn't try to control the entire development process. Going down the road you seem to be planning risks that, and could easily backfire.
(Did I just cost myself my chance at an Aurora "thank you" license?)
If this is what IntelliJ is planning for it's GUI generator, I would be forced to recommend against using this technology on any critical or important work project. Any tool which places extra burdens on the build or testing process is simply unacceptable for production use, if alternatives are available. Similar arguments apply to your proposed AspectJ support.
I love you guys, and do believe you've made the best IDE that's ever been. A lot of that has been because IDEA specifically didn't try to control the entire development process. Going down the road you seem to be planning risks that, and could easily backfire.
I subscribe to this opinion. I like IDEA because lets me code faster and keep using ant, junit, tomcat etc.
IDEA so far had no lock-ins attempt, but if it mutates in becoming a critical, proprietary, component of the build process - then I will not use those features and I predict many users will run away from it.
Totally agreed with everything Dave posted. Just replied so my vote could be counted ;) On another note, what about translets and XSLT? Techology similar to translets probably can be used. If UI "image" is stored as XML, it is tempting to process it with XSLT to update for different needs. Not exactly sure which needs, but might come handy sometime. So, XSL stylesheet can be compiled to "compiling" translet, which can be used to process XML form and compile it into java class file. Each time XSL is updated, translet is recompiled. Each time XML is updated, resulting class file is recompiled. Isn't this cool?
Or, maybe GUI stuff should not be compiled into class files at all? Create some kind of resource definitions, like Windows had for ages (only for dialog windows, but whatever, it can be extended to support other windows), and supply the java library that supports these resources.
I agree too, that UI compiler should come separately from EAP builds, and be heavily tested.
1. We may allow the compiler to run without any license key. We may even provide a separate installation for the compiler.
2. I understand your problems with using EAP builds but that's EAP.
3. I'm not sure that I correctly understood you point with automatic testing but it seems to me that the problem is related to obfuscating. Please note that IDEA does not do any obfuscation on any classes, obfuscating is your own choice. We just decided to generate .class files instead of loading xml files at the runtime because you MIGHT want to obfuscate you program (and then you are probably using an obfuscator which obfuscates the class files but cannot handle xml's).
4. We may provide an alternative way with dynamic loading of XML files. Then you won't need any special compiler to compile your program (just our framework jar in the classpath).
5. We do not try to control the entire development process (at least if you don't want it). GUI builder differs from other IDEA features because we not only provide a development tool but also a framework to be used. If you find using any frameworks unacceptable for you by any reason then you probably won't use our GUI builder.
The first problem with installing IDEA on the build machine is simply the license fee. The second problem is that it's not just the build machine, it's also the development machines of every developer who doesn't wish to use IDEA as their primary development environment. Yes, there are philistines out there who prefer different development environments, and many of us have to work with them. If I told the Eclipse or CodeGuide (or emacs!) users on my team that they would have to install IDEA to be able to build and test, they would be justifiably outraged. The third problem is that it makes it impossible to use the EAP in day-to-day work, since the results of flaky builds (and something like 20% of EAP builds are flaky) are no longer limited to the developer's desktop. I'm a big fan of the EAP process, but I'm certainly not going to use an EAP build as a component of a production build environment. That's just not going to happen. Unless you're very careful about your translator, this means that I couldn't use an EAP on my development environment, and expect to get the same results. That's entirely too much risk, so if I were to use your GUI-builder I would have to drop out of EAP, and I wouldn't be the only one.
On a more technical note, if Swing components are created in obfuscated class files, what are the odds that those class files will be instrumented so as to work cleanly with automated test tools. A previous company I worked for used the java.awt.Robot class extensively to write automated tests which exercised Swing functionality. These worked great, assuming that you are able to name or otherwise reference the individual components. If that isn't possible with your generated GUI classes, we would not have been able to test.
If this is what IntelliJ is planning for it's GUI generator, I would be forced to recommend against using this technology on any critical or important work project. Any tool which places extra burdens on the build or testing process is simply unacceptable for production use, if alternatives are available. Similar arguments apply to your proposed AspectJ support.
I love you guys, and do believe you've made the best IDE that's ever been. A lot of that has been because IDEA specifically didn't try to control the entire development process. Going down the road you seem to be planning risks that, and could easily backfire.
(Did I just cost myself my chance at an Aurora "thank you" license?)
I 100% agree. Generation of source code and then class files seems to be pure waste of resources and could be a real pain for dynamic GUI. There are more smart ways to solve the obfuscation problems. I would rather make the GUI generator itself open source to allow debugging (and further development also!). In other words in must be a plug-in.
Would you please provide us with any example of your XML GUI descriptor? So far I have no clue of what we're talking about.
I am also curious if you were able to address any issues I mentioned in
3) Got it. I had misunderstood a previous comment. The problem isn't just obfuscation. The problem is that to hook into our test framework, it was handy to be able to set non-visible properties of component (usually the names but occasionally others). If we could do that, we could then get handles to UI components in our test code, and manipulate them as desired. This is the sort of thing that often gets overlooked by people trying to create "seamless" tools, and if you were only creating obfuscated class files it would be an insurmountable one.
4) I would strongly encourage this as an optional path. The market is ripe for such an XML-based GUI engine, if it were full-featured, robust, and performant (as previous attempts simply haven't been). It's an enormous challenge, but I absolutely trust JetBrains to create such a thing.
5) Ideally, I should be able to think of the IntelliJ GUI stuff as just another framework to use, that just happens to have kick-ass IDEA integration, much like JUnit or Ant. If you can make that happen, you'll have won me over.
As an aside, the best way I can think of to validate the suitability of your GUI builder is to "eat your own dog food". If you can eventually build the IDEA UI using your GUI framework, and have it still be as responsive, featureful and robust, I will be a very happy license purchase indeed.
As an aside, the best way I can think of to validate the suitability of
your GUI builder is to "eat your own dog food". If you can eventually build the IDEA UI using your GUI framework, and have it still be as responsive, featureful and robust, I will be a very happy license purchase indeed.
As I already stated we are already using it. In fact, we rarely implement any features that we don't use ourselves.
3) Got it. I had misunderstood a previous comment. The problem isn't
just obfuscation. The problem is that to hook into our test framework, it was handy to be able to set non-visible properties of component (usually the names but occasionally others). If we could do that, we could then get handles to UI components in our test code, and manipulate them as desired. This is the sort of thing that often gets overlooked by people trying to create "seamless" tools, and if you were only creating obfuscated class files it would be an insurmountable one. >
4) I would strongly encourage this as an optional path. The market is
ripe for such an XML-based GUI engine, if it were full-featured, robust, and performant (as previous attempts simply haven't been). It's an enormous challenge, but I absolutely trust JetBrains to create such a thing. >
5) Ideally, I should be able to think of the IntelliJ GUI stuff as just
another framework to use, that just happens to have kick-ass IDEA integration, much like JUnit or Ant.
If you can make that happen, you'll have won me over.
>
As an aside, the best way I can think of to validate the suitability of
your GUI builder is to "eat your own dog food". If you can eventually build the IDEA UI using your GUI framework, and have it still be as responsive, featureful and robust, I will be a very happy license purchase indeed. > >
The need of a .class isn't strictly necessary. My framework reads the directly the xml file and creates the gui at runtime.
We were considering this approach but had decided to generate .class files because of obfuscating issues.
Take it for what you paid for it, but I prefer storing the raw xml in the jar, and using a translator to turn it into a gui at runtime.
(This is very close to what Apple's Interface Builder does with a nib file, and it works at reasonable speed.)
If you want encryption, build a simple encryptor for the xml into the stream, add a password, and you should be set.
As far as the overall design, I would suggest strongly that you have a freely distributable jar for ant use, as I KNOW that our team would not accept anything in the build path that they cannot deploy freely. After all, some of our code is open source, while other parts are compiled by clients.
This does not mean giving away the gui builder, just the part needed to turn an xml file into class files. The solution we are planning on using with Intercalate (www.intercalate.com) is to give away the core engine, but to license the gui tools. This is needed to build the code at metagraph.org, and thus we had to do something like it.
Cool. That should encourage a bunch of doubters (including myself). It also explains why you thought obfuscation was important. Out in the custom code mines where most of the world actually works, obfuscation is essentially useless.
On Thu, 20 Mar 2003 13:22:15 +0300, Valentin Kipiatkov wrote:
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).
Cool, is there an Ant task to handle this compilation as well?
A pluggable reader could maybe solve this problem? The obfuscation
process
could encrypt the xml file and the reader would decrypt the files.
>
Then we should provider an encriptor for the build? Is it better then a compiler?
If the final product is a class file (and I say again that having the .java file is mandatory), there's no need. If necessary, obfuscating the class file is enough.
If the xml is deployed with a runtime interpreter, a pluggable reader would be very good. This allows for much greater liberty in deploying an app.
I don't think that you need to provide an encryptor. The advantage of a pluggable reader would be customization.
We are in the process of adding client customization to our framework. One of the proposals is:
form.xml -> filter -> gui interpreter.
The filter should be able to: - show/hide components - change the text on labels - change textfield display size and/or number of accepted chars - specify JFormattedTextField masks - initialization values for components - pluggable actions: content validation of component values, component helpers (possible values for the current component), component actions (popup menu entries with specific actions available on the component). ...
On Thu, 20 Mar 2003 10:42:47 +0000, 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!!!
Erk - being someone who'se just setup Anthill for an automated build process - this doesn't bode well, and would certainly be something to cause one to not used the GUI editor.
We made our own layout managers, as the standard swing layouts are brain dead (only useful for simple forms) and/or over complicated.
Don't anyone come gridbaglayout'ing me. I've seen the code necessary to make it work and puked.
2. Customized components with minor changes.
Most of the swing components we use are customized:
Table with auto-sorting, auto-column sizing, customized renderers (for numbers), etc Tree with a transparent renderer. Combobox with specialized code so that it only fetches the list content when drop down is called. etc, etc,
These are minor changes: jus't replace the name of the generated component, as "design" behaviour hasn't changed.
3. Customized components with major changes and designed components.
ScrollPane with row footers and column footers. List with checkbox renderers. etc
This is more complex as the behaviour of the components has changed or the components themselves are new.
I have used both Borland's and the Forte/Netbeans GUI builders, and would like to share two issues which have kept me from using GUI builders (at work) in the past. You guys have probably already solved these issues, but since I haven't seen mention of them yet, I'll offer them up:
- Deployment: I would like to avoid dependence on any proprietary class/lib that I must ship with my product in order to make things work (borland's itools). This just makes the deployment process more difficult (even if it is freely licensed, the internal approval process is nightmarish).
- Refactoring: The biggest missing piece from all GUI builders (caveat: that I am familiar with). Refactoring, for me, in this context involves being able to select a sub-component (like a JPanel, which may have its own sub-components, buttons, sliders, etc) and creating a bean from that. IDEA's Refactor:"Extract Method" provides the conceptual model for this. So it would be something like: 1. Select a component from the form you are designing 2. Right mouse click "Refactor: Extract Bean".
? This is primarily an issue for those tools which produce one massive, monolithic class file from which all the swing calls are made. If you are generating XML to persist the form, then this may either be 1) not an issue; 2) a much larger issue since multiple "beans" would need to parse a monolithic XML file for their own data.
- Customization: No GUI builder can do it all. At some point one may (I have) had to go into the generated code and "tweak" it to make it look or do like I need it to. At this point, my customized code can not longer be read back into the builder environment for further editing by the GUI builder (or, the changes I made are simply "ignored" and I have to add them back after I am finished editing).
I may have not explained myself very well here, and these may be issues that only I have faced. If the first is true, then I would be happy to elaborate. If the second is true, then I apologize for the waste of bandwidth.
But needless to say, I am very excited at the prospect of JetBrains tackling the merger between GUI Builders and Refactoring. I for one have been waiting a long time for this!
Will you be providing a standalone JAR which you can copy and put in your classpath, or will you have to have IDEA installed on your build machine?
And what about people who don't use Ant in their build process, but want to access the functionality?
:o(
But before I start flaming, I'd like to ask a few questions about it:
1) What sort of XML is it? Is it a proprietary XML format or some sort of a standard? I know there are some project that are using XML to describe GUI in one way or another... the idea in itself is fine IMHO but there doesn't seem to be any sort of standard. Is this XML format "human friendly"? In other words, will I be able to read through the XML files and get a grasp on what will be displayed without actually needing the GUI builder to show me?
It seems that IntelliJ will introduce some sort of a proprietary XML format here... Will this format be opened up to the community (I could even think of starting a community to define an industry standard!)?
2) As has been said already, Ant tasks are an absolute must and the "compiler" must be loosly coupled with IDEA in order to set up a build box without having to install IDEA on that machine.
Kind regards, Stefan Freyr.
Calum MacLean wrote:
I believe Mike already told me in an earlier thread that they will
provide the "compiler" as a standalone downloadable product (I'm hoping
it will just require a valid IDEA license file). He said you won't have
to install IDEA on your build machine.
It would be nice if IntelliJ could provide a command-line interface to
the compiler in addition to the Ant task.
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
So would you need a separate license for your build machine, or else make sure you're not running IDEA at the time with the same license?
Maybe it doesn't do the check for "Is IDEA already running with this license?".
Regarding command line, it might also be useful to have a Java API into the compiler, as well as command-line and an Ant task.
be
It's clear that allthough idea is feature full, most things aren't gui
intensive. This is clearly visible for example in the very basic handling of
events/gui constructs in IDE Options, Project options, etc.
Note that I think this is as it should be:
IDE Options and/or Project Options are used only once in a while, so a very
polished interface isn't necessary.
On the other side, writing code is done constantly, so very polished/precise
refactorings, intentions, etc is a must.
But, when writing an app gui intensive, there are many problems that can
only be resolved by debugging the gui framework. I recently recompiled the
jdk sources with the debug switch, only so that I could debug LookAndFeel
actions, renderers, swing events, etc.
I also think that a sourcepath for the generated gui files is a must.
>
The need of a .class isn't strictly necessary. My framework reads the
directly the xml file and creates the gui at runtime.
For simple forms, there's no apparent delay (to the user) while
reading/creating the form.
Complex forms (300+ gui elements) have a slower creation time. The problem
isn't so great, as for these kind of forms, the time spent getting the data
from the backend is so high that the creation time (in the background) of
the form isn't significant.
1) It's a propietrary XML format. You might edit it manually if you want but
it's not a preferrable way of doing development :-).
2) What's the problem with installing IDEA on the build machine?
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Stefan Freyr Stefansson" <stefan_freyr_stefansson@hotmail.com> wrote in
message news:7838975.1048174090757.JavaMail.jrun@is.intellij.net...
>
>
a standard? I know there are some project that are using XML to describe GUI
in one way or another... the idea in itself is fine IMHO but there doesn't
seem to be any sort of standard. Is this XML format "human friendly"? In
other words, will I be able to read through the XML files and get a grasp on
what will be displayed without actually needing the GUI builder to show me?
format here... Will this format be opened up to the community (I could even
think of starting a community to define an industry standard!)?
>
"compiler" must be loosly coupled with IDEA in order to set up a build box
without having to install IDEA on that machine.
>
We were considering this approach but had decided to generate .class files
because of obfuscating issues.
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Carlos Costa e Silva" <carlos@keysoft.pt> wrote in message
news:b5crg8$tbu$1@is.intellij.net...
>
>
>
data
>
>
format here... Will this format be opened up to the community (I could even
think of starting a community to define an industry standard!)?
JSR-57: http://www.jcp.org/en/jsr/detail?id=57
Implementation - Axualize: http://axualize.sourceforge.net/
We haven't yet felt the need of source obfuscation.
A pluggable reader could maybe solve this problem? The obfuscation process
could encrypt the xml file and the reader would decrypt the files.
Then we should provider an encriptor for the build? Is it better then a
compiler?
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Carlos Costa e Silva" <carlos@keysoft.pt> wrote in message
news:b5cth8$2j2$1@is.intellij.net...
files
>
>
>
>
Unfortunately the mentioned JSR is far from our GUI builder needs.
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Carlos Costa e Silva" <carlos@keysoft.pt> wrote in message
news:b5csv9$18t$1@is.intellij.net...
even
>
>
>
>
Valentin Kipiatkov wrote:
It's cleaner and easier to convince bosses that a project should use
this GUI builder framework, if the framework is separate from the IDE.
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
The first problem with installing IDEA on the build machine is simply the license fee. The second problem is that it's not just the build machine, it's also the development machines of every developer who doesn't wish to use IDEA as their primary development environment. Yes, there are philistines out there who prefer different development environments, and many of us have to work with them. If I told the Eclipse or CodeGuide (or emacs!) users on my team that they would have to install IDEA to be able to build and test, they would be justifiably outraged. The third problem is that it makes it impossible to use the EAP in day-to-day work, since the results of flaky builds (and something like 20% of EAP builds are flaky) are no longer limited to the developer's desktop. I'm a big fan of the EAP process, but I'm certainly not going to use an EAP build as a component of a production build environment. That's just not going to happen. Unless you're very careful about your translator, this means that I couldn't use an EAP on my development environment, and expect to get the same results. That's entirely too much risk, so if I were to use your GUI-builder I would have to drop out of EAP, and I wouldn't be the only one.
On a more technical note, if Swing components are created in obfuscated class files, what are the odds that those class files will be instrumented so as to work cleanly with automated test tools. A previous company I worked for used the java.awt.Robot class extensively to write automated tests which exercised Swing functionality. These worked great, assuming that you are able to name or otherwise reference the individual components. If that isn't possible with your generated GUI classes, we would not have been able to test.
If this is what IntelliJ is planning for it's GUI generator, I would be forced to recommend against using this technology on any critical or important work project. Any tool which places extra burdens on the build or testing process is simply unacceptable for production use, if alternatives are available. Similar arguments apply to your proposed AspectJ support.
I love you guys, and do believe you've made the best IDE that's ever been. A lot of that has been because IDEA specifically didn't try to control the entire development process. Going down the road you seem to be planning risks that, and could easily backfire.
(Did I just cost myself my chance at an Aurora "thank you" license?)
"Dave Griffith" <dave.griffith@trilogy.com> wrote in message
news:31527325.1048182538402.JavaMail.jrun@is.intellij.net...
The first problem with installing IDEA on the build machine is simply the
license fee. The second problem is that it's not just the build machine,
it's also the development machines of every developer who doesn't wish to
use IDEA as their primary development environment. Yes, there are
philistines out there who prefer different development environments, and
many of us have to work with them. If I told the Eclipse or CodeGuide (or
emacs!) users on my team that they would have to install IDEA to be able to
build and test, they would be justifiably outraged. The third problem is
that it makes it impossible to use the EAP in day-to-day work, since the
results of flaky builds (and something like 20% of EAP builds are flaky) are
no longer limited to the developer's desktop. I'm a big fan of the EAP
process, but I'm certainly not going to use an EAP build as a component of a
production build environment. That's just not going to happen. Unless
you're very careful about your translator, this means that I couldn't use an
EAP on my development environment, and expect to get the same results.
That's entirely too much risk, so if I were to use your GUI-builder I would
have to drop out of EAP, and I wouldn't be the only one.
On a more technical note, if Swing components are created in obfuscated
class files, what are the odds that those class files will be instrumented
so as to work cleanly with automated test tools. A previous company I
worked for used the java.awt.Robot class extensively to write automated
tests which exercised Swing functionality. These worked great, assuming
that you are able to name or otherwise reference the individual components.
If that isn't possible with your generated GUI classes, we would not have
been able to test.
If this is what IntelliJ is planning for it's GUI generator, I would be
forced to recommend against using this technology on any critical or
important work project. Any tool which places extra burdens on the build or
testing process is simply unacceptable for production use, if alternatives
are available. Similar arguments apply to your proposed AspectJ support.
I love you guys, and do believe you've made the best IDE that's ever been.
A lot of that has been because IDEA specifically didn't try to
control the entire development process. Going down the road you seem to be
planning risks that, and could easily backfire.
(Did I just cost myself my chance at an Aurora "thank you" license?)
I wonder if I were forced to create Win32 GUI application, how would I
unit-test my GUI created by Window Resource Editor? Would I need it? I guess
not. Simple because it doesn't make much sense. What definitely I'd like to
test is the code that manipulates these GUI components. If that is possible
with your GUI builder, I'll be happy to use it.
/kesha
"Dave Griffith" <dave.griffith@trilogy.com> wrote in message
news:31527325.1048182538402.JavaMail.jrun@is.intellij.net...
The first problem with installing IDEA on the build machine is simply the
license fee. The second problem is that it's not just the build machine,
it's also the development machines of every developer who doesn't wish to
use IDEA as their primary development environment. Yes, there are
philistines out there who prefer different development environments, and
many of us have to work with them. If I told the Eclipse or CodeGuide (or
emacs!) users on my team that they would have to install IDEA to be able to
build and test, they would be justifiably outraged. The third problem is
that it makes it impossible to use the EAP in day-to-day work, since the
results of flaky builds (and something like 20% of EAP builds are flaky) are
no longer limited to the developer's desktop. I'm a big fan of the EAP
process, but I'm certainly not going to use an EAP build as a component of a
production build environment. That's just not going to happen. Unless
you're very careful about your translator, this means that I couldn't use an
EAP on my development environment, and expect to get the same results.
That's entirely too much risk, so if I were to use your GUI-builder I would
have to drop out of EAP, and I wouldn't be the only one.
On a more technical note, if Swing components are created in obfuscated
class files, what are the odds that those class files will be instrumented
so as to work cleanly with automated test tools. A previous company I
worked for used the java.awt.Robot class extensively to write automated
tests which exercised Swing functionality. These worked great, assuming
that you are able to name or otherwise reference the individual components.
If that isn't possible with your generated GUI classes, we would not have
been able to test.
If this is what IntelliJ is planning for it's GUI generator, I would be
forced to recommend against using this technology on any critical or
important work project. Any tool which places extra burdens on the build or
testing process is simply unacceptable for production use, if alternatives
are available. Similar arguments apply to your proposed AspectJ support.
I love you guys, and do believe you've made the best IDE that's ever been.
A lot of that has been because IDEA specifically didn't try to
control the entire development process. Going down the road you seem to be
planning risks that, and could easily backfire.
(Did I just cost myself my chance at an Aurora "thank you" license?)
Michael Jouravlev wrote:
I subscribe to this opinion.
I like IDEA because lets me code faster and keep using ant, junit,
tomcat etc.
IDEA so far had no lock-ins attempt, but if it mutates in becoming a
critical, proprietary, component of the build process - then I will not
use those features and I predict many users will run away from it.
Edo
"Dave Griffith" wrote in message news:31527325.1048182538402.JavaMail.jrun@is.intellij.net... ]]>
Totally agreed with everything Dave posted. Just replied so my vote could be
counted ;) On another note, what about translets and XSLT? Techology
similar to translets probably can be used. If UI "image" is stored as XML,
it is tempting to process it with XSLT to update for different needs. Not
exactly sure which needs, but might come handy sometime. So, XSL stylesheet
can be compiled to "compiling" translet, which can be used to process XML
form and compile it into java class file. Each time XSL is updated, translet
is recompiled. Each time XML is updated, resulting class file is recompiled.
Isn't this cool?
Or, maybe GUI stuff should not be compiled into class files at all? Create
some kind of resource definitions, like Windows had for ages (only for
dialog windows, but whatever, it can be extended to support other windows),
and supply the java library that supports these resources.
I agree too, that UI compiler should come separately from EAP builds, and be
heavily tested.
Michael J.
1. We may allow the compiler to run without any license key. We may even
provide a separate installation for the compiler.
2. I understand your problems with using EAP builds but that's EAP.
3. I'm not sure that I correctly understood you point with automatic testing
but it seems to me that the problem is related to obfuscating. Please note
that IDEA does not do any obfuscation on any classes, obfuscating is your
own choice.
We just decided to generate .class files instead of loading xml files at the
runtime because you MIGHT want to obfuscate you program (and then you are
probably using an obfuscator which obfuscates the class files but cannot
handle xml's).
4. We may provide an alternative way with dynamic loading of XML files. Then
you won't need any special compiler to compile your program (just our
framework jar in the classpath).
5. We do not try to control the entire development process (at least if you
don't want it). GUI builder differs from other IDEA features because we not
only provide a development tool but also a framework to be used. If you find
using any frameworks unacceptable for you by any reason then you probably
won't use our GUI builder.
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Dave Griffith" <dave.griffith@trilogy.com> wrote in message
news:31527325.1048182538402.JavaMail.jrun@is.intellij.net...
The first problem with installing IDEA on the build machine is simply the
license fee. The second problem is that it's not just the build machine,
it's also the development machines of every developer who doesn't wish to
use IDEA as their primary development environment. Yes, there are
philistines out there who prefer different development environments, and
many of us have to work with them. If I told the Eclipse or CodeGuide (or
emacs!) users on my team that they would have to install IDEA to be able to
build and test, they would be justifiably outraged. The third problem is
that it makes it impossible to use the EAP in day-to-day work, since the
results of flaky builds (and something like 20% of EAP builds are flaky) are
no longer limited to the developer's desktop. I'm a big fan of the EAP
process, but I'm certainly not going to use an EAP build as a component of a
production build environment. That's just not going to happen. Unless
you're very careful about your translator, this means that I couldn't use an
EAP on my development environment, and expect to get the same results.
That's entirely too much risk, so if I were to use your GUI-builder I would
have to drop out of EAP, and I wouldn't be the only one.
On a more technical note, if Swing components are created in obfuscated
class files, what are the odds that those class files will be instrumented
so as to work cleanly with automated test tools. A previous company I
worked for used the java.awt.Robot class extensively to write automated
tests which exercised Swing functionality. These worked great, assuming
that you are able to name or otherwise reference the individual components.
If that isn't possible with your generated GUI classes, we would not have
been able to test.
If this is what IntelliJ is planning for it's GUI generator, I would be
forced to recommend against using this technology on any critical or
important work project. Any tool which places extra burdens on the build or
testing process is simply unacceptable for production use, if alternatives
are available. Similar arguments apply to your proposed AspectJ support.
I love you guys, and do believe you've made the best IDE that's ever been.
A lot of that has been because IDEA specifically didn't try to
control the entire development process. Going down the road you seem to be
planning risks that, and could easily backfire.
(Did I just cost myself my chance at an Aurora "thank you" license?)
I 100% agree. Generation of source code and then class files seems to be pure waste of resources and could be a real pain for dynamic GUI. There are more smart ways to solve the obfuscation problems. I would rather make the GUI generator itself open source to allow debugging (and further development also!). In other words in must be a plug-in.
Would you please provide us with any example of your XML GUI descriptor? So far I have no clue of what we're talking about.
I am also curious if you were able to address any issues I mentioned in
http://www.intellij.net/tracker/idea/viewSCR?publicId=6533
espesially about reusable components.
1) Excellent.
2) Sad, but I don't see a way around it either.
3) Got it. I had misunderstood a previous comment. The problem isn't just obfuscation. The problem is that to hook into our test framework, it was handy to be able to set non-visible properties of component (usually the names but occasionally others). If we could do that, we could then get handles to UI components in our test code, and manipulate them as desired. This is the sort of thing that often gets overlooked by people trying to create "seamless" tools, and if you were only creating obfuscated class files it would be an insurmountable one.
4) I would strongly encourage this as an optional path. The market is ripe for such an XML-based GUI engine, if it were full-featured, robust, and performant (as previous attempts simply haven't been). It's an enormous challenge, but I absolutely trust JetBrains to create such a thing.
5) Ideally, I should be able to think of the IntelliJ GUI stuff as just another framework to use, that just happens to have kick-ass IDEA integration, much like JUnit or Ant.
If you can make that happen, you'll have won me over.
As an aside, the best way I can think of to validate the suitability of your GUI builder is to "eat your own dog food". If you can eventually build the IDEA UI using your GUI framework, and have it still be as responsive, featureful and robust, I will be a very happy license purchase indeed.
your GUI builder is to "eat your own dog food". If you can eventually build
the IDEA UI using your GUI framework, and have it still be as responsive,
featureful and robust, I will be a very happy license purchase indeed.
As I already stated we are already using it. In fact, we rarely implement
any features that we don't use ourselves.
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Dave Griffith" <dave.griffith@trilogy.com> wrote in message
news:22221064.1048187768813.JavaMail.jrun@is.intellij.net...
>
>
just obfuscation. The problem is that to hook into our test framework, it
was handy to be able to set non-visible properties of component (usually the
names but occasionally others). If we could do that, we could then get
handles to UI components in our test code, and manipulate them as desired.
This is the sort of thing that often gets overlooked by people trying to
create "seamless" tools, and if you were only creating obfuscated class
files it would be an insurmountable one.
>
ripe for such an XML-based GUI engine, if it were full-featured, robust, and
performant (as previous attempts simply haven't been). It's an enormous
challenge, but I absolutely trust JetBrains to create such a thing.
>
another framework to use, that just happens to have kick-ass IDEA
integration, much like JUnit or Ant.
>
your GUI builder is to "eat your own dog food". If you can eventually build
the IDEA UI using your GUI framework, and have it still be as responsive,
featureful and robust, I will be a very happy license purchase indeed.
>
>
In article <b5csmj$lh$1@is.intellij.net>,
"Valentin Kipiatkov" <valentin@intellij.com> wrote:
Take it for what you paid for it, but I prefer storing the raw xml in
the jar, and using a translator to turn it into a gui at runtime.
(This is very close to what Apple's Interface Builder does with a nib
file, and it works at reasonable speed.)
If you want encryption, build a simple encryptor for the xml into the
stream, add a password, and you should be set.
As far as the overall design, I would suggest strongly that you have a
freely distributable jar for ant use, as I KNOW that our team would not
accept anything in the build path that they cannot deploy freely. After
all, some of our code is open source, while other parts are compiled by
clients.
This does not mean giving away the gui builder, just the part needed to
turn an xml file into class files. The solution we are planning on
using with Intercalate (www.intercalate.com) is to give away the core
engine, but to license the gui tools. This is needed to build the code
at metagraph.org, and thus we had to do something like it.
Scott
Cool. That should encourage a bunch of doubters (including myself). It also explains why you thought obfuscation was important. Out in the custom code mines where most of the world actually works, obfuscation is essentially useless.
I look forward to trying it out.
--Dave
On Thu, 20 Mar 2003 13:22:15 +0300, Valentin Kipiatkov wrote:
Cool, is there an Ant task to handle this compilation as well?
"Valentin Kipiatkov" <valentin@intellij.com> wrote in message
news:b5cto0$30v$1@is.intellij.net...
process
>
If the final product is a class file (and I say again that having the .java
file is mandatory), there's no need. If necessary, obfuscating the class
file is enough.
If the xml is deployed with a runtime interpreter, a pluggable reader would
be very good. This allows for much greater liberty in deploying an app.
I don't think that you need to provide an encryptor. The advantage of a
pluggable reader would be customization.
We are in the process of adding client customization to our framework. One
of the proposals is:
form.xml -> filter -> gui interpreter.
The filter should be able to:
- show/hide components
- change the text on labels
- change textfield display size and/or number of accepted chars
- specify JFormattedTextField masks
- initialization values for components
- pluggable actions: content validation of component values, component
helpers (possible values for the current component), component actions
(popup menu entries with specific actions available on the component).
...
On Thu, 20 Mar 2003 10:42:47 +0000, Michael Seele wrote:
Erk - being someone who'se just setup Anthill for an automated build
process - this doesn't bode well, and would certainly be something to
cause one to not used the GUI editor.
Some other important points:
1. Customized LayoutManagers.
We made our own layout managers, as the standard swing layouts are brain
dead (only useful for simple forms) and/or over complicated.
Don't anyone come gridbaglayout'ing me. I've seen the code necessary to make
it work and puked.
2. Customized components with minor changes.
Most of the swing components we use are customized:
Table with auto-sorting, auto-column sizing, customized renderers (for
numbers), etc
Tree with a transparent renderer.
Combobox with specialized code so that it only fetches the list content when
drop down is called.
etc, etc,
These are minor changes: jus't replace the name of the generated component,
as "design" behaviour hasn't changed.
3. Customized components with major changes and designed components.
ScrollPane with row footers and column footers.
List with checkbox renderers.
etc
This is more complex as the behaviour of the components has changed or the
components themselves are new.
I have used both Borland's and the Forte/Netbeans GUI builders, and
would like to share two issues which have kept me from using GUI
builders (at work) in the past. You guys have probably already solved
these issues, but since I haven't seen mention of them yet, I'll offer
them up:
- Deployment: I would like to avoid dependence on any proprietary
class/lib that I must ship with my product in order to make things
work (borland's itools). This just makes the deployment process more
difficult (even if it is freely licensed, the internal approval
process is nightmarish).
- Refactoring: The biggest missing piece from all GUI builders
(caveat: that I am familiar with). Refactoring, for me, in this
context involves being able to select a sub-component (like a
JPanel, which may have its own sub-components, buttons, sliders,
etc) and creating a bean from that. IDEA's Refactor:"Extract Method"
provides the conceptual model for this. So it would be something
like:
1. Select a component from the form you are designing
2. Right mouse click "Refactor: Extract Bean".
? This is primarily an issue for those tools which produce one
massive, monolithic class file from which all the swing calls are
made. If you are generating XML to persist the form, then this may
either be 1) not an issue; 2) a much larger issue since multiple
"beans" would need to parse a monolithic XML file for their own
data.
- Customization: No GUI builder can do it all. At some point one may
(I have) had to go into the generated code and "tweak" it to make it
look or do like I need it to. At this point, my customized code can
not longer be read back into the builder environment for further
editing by the GUI builder (or, the changes I made are simply
"ignored" and I have to add them back after I am finished editing).
I may have not explained myself very well here, and these may be
issues that only I have faced. If the first is true, then I would be
happy to elaborate. If the second is true, then I apologize for the
waste of bandwidth.
But needless to say, I am very excited at the prospect of JetBrains
tackling the merger between GUI Builders and Refactoring. I for one
have been waiting a long time for this!
thanks,
:) bobse
Hello!
It think there should be no problems with UI builder if your project is
configured to use JDK 1.3.
--
Best regards,
Anton Katilin
-
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
"Jens Peter Grosen" <jiveadmin@jetbrains.com> wrote in message
news:20032473.1048169431816.JavaMail.jrun@is.intellij.net...
>
it behaves (slightly) different in different JDK/Swing releases (1.3/1.4).
>
>