OK, although I'm sure, GUI code should be better coded by hand, I think it's time to discuss, how to implement it best.
We know, there are some more or less different approaches. At the one hand I know Borland's patented two-way approach and at the other hand Netbeans' (XML-file-based?) version. Since Borland has protected the two-way-coding by patent law, this first version will not be possible.
But let's listen first, what the JetBrains already have thought of this often-requested feature.
Cheers, Tom
On Wed, 13 Nov 2002 15:35:28 -0800, "Josh Knowles" <josh@wwp.com> wrote:
Someone from JetBrains said that it would be in the next major release of Intellij.
On Thu, 14 Nov 2002 08:32:33 +0000, Thomas Singer wrote:
We know, there are some more or less different approaches. At the one hand I know Borland's patented two-way approach and at the other hand Netbeans' (XML-file-based?) version. Since Borland has protected the two-way-coding by patent law, this first version will not be possible.
blink Borland has??? Anyone got a URL for the patent?
--
-- \m/ -- "...if I seem super human I have been misunderstood." (c) Dream Theater mark@talios.com - ICQ: 1934853 JID: talios@myjabber.net
On Thu, 14 Nov 2002 22:07:12 +1300, "Mark Derricutt" <mark@talios.com> wrote:
On Thu, 14 Nov 2002 08:32:33 +0000, Thomas Singer wrote:
We know, there are some more or less different approaches. At the one hand I know Borland's patented two-way approach and at the other hand Netbeans' (XML-file-based?) version. Since Borland has protected the two-way-coding by patent law, this first version will not be possible.
blink Borland has??? Anyone got a URL for the patent?
--
-- \m/ -- "...if I seem super human I have been misunderstood." (c) Dream Theater mark@talios.com - ICQ: 1934853 JID: talios@myjabber.net
Download the free personal version from jbuilder. When your open both jbuilder and idea and change code in idea the gui builder is updated instantly When you change something in jbuilders gui builder and press ctrl+s the code in IDEA is changed instantly. Adding event handlers in IDEA is almost as easy as in jbuilder using intentions and smart complete. You only have to start jbuilder for a big change in the user interface.
OK, although I'm sure, GUI code should be better coded by hand, I think it's time to discuss, how to implement it best.
We know, there are some more or less different approaches. At the one hand I know Borland's patented two-way approach and at the other hand Netbeans' (XML-file-based?) version. Since Borland has protected the two-way-coding by patent law, this first version will not be possible.
I think that the only way non-hand-coded GUIs can work well is by using a standard framework that loads GUI description files and constructs them on the fly from that description. That's the way MacOS does it in Cocoa; you create a nib file in Interface Builder and then you write the "business logic" classes in Project Builder to load the nib file that display the GUI. Done properly I think it could work quite nicely. However, this implies quite a bit of framework code to handle the GUI description files which people may not want.
Ciao, Gordon
-- Gordon Tyler Software Developer, R&D Sitraka (now part of Quest Software) "Performance is Mission Critical"
I was thinking about the GUI Builder - if anyone here is a good plugin author, how about making a wrapper for Radical? ( http://radical.sourceforge.net ) - GUI building (somewhat simplistic but functional) that also has a JEdit plugin.
--
-- \m/ -- "...if I seem super human I have been misunderstood." (c) Dream Theater mark@talios.com - ICQ: 1934853 JID: talios@myjabber.net
On Thu, 14 Nov 2002 13:01:00 +0000, Gordon Tyler wrote:
I think that the only way non-hand-coded GUIs can work well is by using a standard framework that loads GUI description files and constructs them on the fly from that description. That's the way MacOS does it in Cocoa; you create a nib file in Interface Builder and then you write the "business logic" classes in Project Builder to load the nib file that display the GUI. Done properly I think it could work quite nicely. However, this implies quite a bit of framework code to handle the GUI description files which people may not want.
Looked at swang.sourceforge.net ? Does just that, given an XML file it'll load up and create your GUI for you. I've only looked at it briefly thou, but even works remotely (pulling the XML file accross the net via http/soap and build your gui :)
--
-- \m/ -- "...if I seem super human I have been misunderstood." (c) Dream Theater mark@talios.com - ICQ: 1934853 JID: talios@myjabber.net
OK, although I'm sure, GUI code should be better coded by hand, I think it's time to discuss, how to implement it best.
We know, there are some more or less different approaches. At the one hand I know Borland's patented two-way approach and at the other hand Netbeans' (XML-file-based?) version. Since Borland has protected the two-way-coding by patent law, this first version will not be possible.
I think that the only way non-hand-coded GUIs can work well is by using a standard framework that loads GUI description files and constructs them on the fly from that description. That's the way MacOS does it in Cocoa; you create a nib file in Interface Builder and then you write the "business logic" classes in Project Builder to load the nib file that display the GUI. Done properly I think it could work quite nicely. However, this implies quite a bit of framework code to handle the GUI description files which people may not want.
Ciao, Gordon
-- Gordon Tyler Software Developer, R&D Sitraka (now part of Quest Software) "Performance is Mission Critical"
I tried Radical for 15 minutes now and must say, it's a awful work.
But I must repeat, that I'm much faster when coding by hand -- because I have good helper panels making my live significantly easier with GridBagLayout and HIGLayout.
Although... I wonder if, with IDEA's PSI, the generated code wouldn't be so bad? It would require some hefty logic on the part of the GUI builder to deal with arbitrary user code though.
Thomas Singer wrote:
I have the feeling, you are right.
Looking at autogenerated code in Netbeans makes my hair stand on end.
-- Gordon Tyler Software Developer, R&D Sitraka (now part of Quest Software) "Performance is Mission Critical"
Yes, you should maintain the business logic. But why do you need to see
the
code for layout?
If the GUI builder creates code that doesn't do quite what I want it to, then I'll need to either change the generated code (yuck) or have some other way of modifying the code such as using my own components at design-time, or replacing components with my own components at run-time.
I'm sure that's obvious to everyone, but I remember a GUI builder from a few years ago that would generate code that the user was expected to modify in order to have it do something useful.
And if the code isn't designed to be seen, perhaps the GUI builder should produce .class files instead of .java files...
for quite a while I was wondering why all the GUI builders create code for just a composition of serializable objects. In my opinion composite GUI elements should be just dragged together in a GUI builder and then serialized for later use. The interaction between the GUI elements and the code should be based on some lookup scheme (e.g. the basic elements are assigned names which can then be referred to in the code handling the GUI issues). This would not only ease GUI builder development but also would cleanly separate GUI code from application code. Currently in all approaches the GUI construction code and the event handling code are forced to be in the same app. This is one of the biggest "ugglifiers" when I look at code generated by current GUI builders.
I know that Serialization is currently not very usable for long term persistence but I already read about XML serialization for Swing components somewhere at SUN website .
I hope that any code produced by the GUI builder will be heavily templatized - in the sense of the 'template method' refactoring.
The users' code - logic and/or ui tweaks should go in subclasses fo the builder-generated classes.
This is an old-time approach for OO codegeneration (not necessarily UI only) and I like it very much. It frees the builder from worrying about merging its own well understood code and foreign (for it, i.e. the users') code.
modyfiyng the builder code is only a last-resort.
Edo
Mike Aizatsky wrote:
Why do ever need the code from GUI builder?
-- Best regards, Mike Aizatsky. ------------------------------ JetBrains, Inc / IntelliJ Software http://www.intellij.com "Develop with pleasure!"
I hope that any code produced by the GUI builder will be heavily templatized - in the sense of the 'template method' refactoring.
>
The users' code - logic and/or ui tweaks should go in subclasses fo the builder-generated classes.
>
This is an old-time approach for OO codegeneration (not necessarily UI only) and I like it very much. It frees the builder from worrying about merging its own well understood code and foreign (for it, i.e. the users') code.
>
modyfiyng the builder code is only a last-resort.
>
Edo
>
Mike Aizatsky wrote:
Why do ever need the code from GUI builder?
>
-- Best regards, Mike Aizatsky. ------------------------------ JetBrains, Inc / IntelliJ Software http://www.intellij.com "Develop with pleasure!"
We have come up with an approach of how to use a third-party GUI Builder tool whan developing with IDEA. I believe that someone has already mentioned that you can create UI in JBuilder and in parallel observe all the chnages in IDEA. What I think scares most people about GUI builders is the fact that they generate an awfull, unmaintainable and hugely incomprehensible in allot of cases code.
We chose to do the following, where it made sence. You develop your UI in JBuilder, NetBeans, ... Then instead of considering that your UI, you specialize the classes with also Presentation classes, which are not saturated with GUIBuilder's mambo-jambo.
Ex. UserAuthenticationForm - build by JBuilder - jText1 (meant to contain user name) - jPasswrd1 (meant to contain user's password) - jbInit() (huge mess)
UserAuthenticationView extends UserAuthenticationForm - built by you - userNameField (alias for jText1, assigned in constructor of UserAuthenticationView - userPasswordField (alias for jPasswrd1, assigned in constructor of UserAuthenticationView - ..
In this approach, you leave the code created by GUI builder untouchable, which in my opinion it should be (the stench emanating from that code can not be tolerated ;)
You create aliases for all the fields that mean something to you and you need to process, you implement event handlers, where they could be easier implemneted.
I can just say that for a more or less complex screen generated by JBuilder with 600 lines of code a subclass had approximately 100 lines of code that was clear and easily read by the most novice developers.
My main point is that IntelliJ guys are already done so much for us, their work is so appreciated and so good that I personnaly don't really think that GUI Builder is of the highest priority.
Lets rather vote for HotSwap support in future versions.
This is not really relevant to IDEA, but the rotten variable names that JBuilder, NetBeans et al generate are easily changed from within the GUI builder itself. It's just a matter of knowing how to use the tool (and not being too lazy...). :) If you do that, then your subclass (which is a nice idea, BTW) will be even simpler.
Ex. UserAuthenticationForm - build by JBuilder - jText1 (meant to contain user name) - jPasswrd1 (meant to contain user's password) - jbInit() (huge mess)
>
UserAuthenticationView extends UserAuthenticationForm - built by you - userNameField (alias for jText1, assigned in constructor of
UserAuthenticationView
- userPasswordField (alias for jPasswrd1, assigned in constructor of
This e-mail and any attachments may be confidential and/or legally privileged. If you have received this email and you are not a named addressee, please inform the sender at Digital Steps Ltd by phone on +44 (0)1483 469 480 or by reply email and then delete the email from your system. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this email. Although Digital Steps Ltd routinely screens for viruses, addressees should check this email and any attachments for viruses. Digital Steps Ltd makes no representation or warranty as to the absence of viruses in this email or any attachments.
My only request would be that we have a way of disabling or not loading the gui builder. If you look at JBuilder, there are so many extras, like gui builder, jdbc pilot etc that the entire app is very slow.
If I recall correctly, JBuilder did not initialize the GUI builder code unless you clicked on the 'Design' tab. Funnily enough, there was even a plugin written to remove the 'Design' tab for people who didn't use the GUI builder and didn't want the annoyance of a long pause if they accidentally clicked on the 'Design' tab :)
N.
charles decroes wrote:
My only request would be that we have a way of disabling or not loading the gui builder. If you look at JBuilder, there are so many extras, like gui builder, jdbc pilot etc that the entire app is very slow.
Someone from JetBrains said that it would be in the next major release of
Intellij.
"Peter Litvak" <plitvak@attbi.com> wrote in message
news:aquh6b$nog$1@is.intellij.net...
>
start
>
>
>
>
OK, although I'm sure, GUI code should be better coded by hand, I
think it's time to discuss, how to implement it best.
We know, there are some more or less different approaches. At the one
hand I know Borland's patented two-way approach and at the other hand
Netbeans' (XML-file-based?) version. Since Borland has protected the
two-way-coding by patent law, this first version will not be possible.
But let's listen first, what the JetBrains already have thought of
this often-requested feature.
Cheers,
Tom
On Wed, 13 Nov 2002 15:35:28 -0800, "Josh Knowles" <josh@wwp.com>
wrote:
On Thu, 14 Nov 2002 08:32:33 +0000, Thomas Singer wrote:
blink Borland has??? Anyone got a URL for the patent?
--
-- \m/ --
"...if I seem super human I have been misunderstood." (c) Dream Theater
mark@talios.com - ICQ: 1934853 JID: talios@myjabber.net
I've found this:
http://www.borland.com/news/press_releases/2001/05_01_01_patent.html
Tom
On Thu, 14 Nov 2002 22:07:12 +1300, "Mark Derricutt" <mark@talios.com>
wrote:
Download the free personal version from jbuilder.
When your open both jbuilder and idea and change code in idea the gui
builder is updated instantly
When you change something in jbuilders gui builder and press ctrl+s the code
in IDEA is changed instantly.
Adding event handlers in IDEA is almost as easy as in jbuilder using
intentions and smart complete. You only have to start jbuilder for a big
change in the user interface.
"Peter Litvak" <plitvak@attbi.com> wrote in message
news:aquh6b$nog$1@is.intellij.net...
>
start
>
>
>
>
Thomas Singer wrote:
I think that the only way non-hand-coded GUIs can work well is by using
a standard framework that loads GUI description files and constructs
them on the fly from that description. That's the way MacOS does it in
Cocoa; you create a nib file in Interface Builder and then you write the
"business logic" classes in Project Builder to load the nib file that
display the GUI. Done properly I think it could work quite nicely.
However, this implies quite a bit of framework code to handle the GUI
description files which people may not want.
Ciao,
Gordon
--
Gordon Tyler
Software Developer, R&D
Sitraka (now part of Quest Software)
"Performance is Mission Critical"
On Thu, 14 Nov 2002 11:47:23 +0000, Thomas Singer wrote:
Thanks, I had a look last night but for the life of me couldn't find it.
--
-- \m/ --
"...if I seem super human I have been misunderstood." (c) Dream Theater
mark@talios.com - ICQ: 1934853 JID: talios@myjabber.net
I was thinking about the GUI Builder - if anyone here is a good plugin author,
how about making a wrapper for Radical? ( http://radical.sourceforge.net ) -
GUI building (somewhat simplistic but functional) that also has a JEdit
plugin.
--
-- \m/ --
"...if I seem super human I have been misunderstood." (c) Dream Theater
mark@talios.com - ICQ: 1934853 JID: talios@myjabber.net
On Thu, 14 Nov 2002 13:01:00 +0000, Gordon Tyler wrote:
Looked at swang.sourceforge.net ? Does just that, given an XML file it'll
load up and create your GUI for you. I've only looked at it briefly thou, but
even works remotely (pulling the XML file accross the net via http/soap and
build your gui :)
--
-- \m/ --
"...if I seem super human I have been misunderstood." (c) Dream Theater
mark@talios.com - ICQ: 1934853 JID: talios@myjabber.net
I have the feeling, you are right.
Looking at autogenerated code in Netbeans makes my hair stand on end.
Tom
On Thu, 14 Nov 2002 13:01:00 -0500, Gordon Tyler
<gordon.tyler@sitraka.com> wrote:
Hi,
I tried Radical for 15 minutes now and must say, it's a awful work.
But I must repeat, that I'm much faster when coding by hand --
because I have good helper panels making my live significantly easier
with GridBagLayout and HIGLayout.
Tom
Did you seen this:
http://jgb.sourceforge.net/
This project may generate java code from XML prepared by DTD with windows
component definition
--
Alexey Efimov, Software Engineer
Sputnik Labs,
http://www.spklabs.com
"Peter Litvak" <plitvak@attbi.com> wrote in message
news:aquh6b$nog$1@is.intellij.net...
>
start
>
>
>
>
Although... I wonder if, with IDEA's PSI, the generated code wouldn't be
so bad? It would require some hefty logic on the part of the GUI builder
to deal with arbitrary user code though.
Thomas Singer wrote:
--
Gordon Tyler
Software Developer, R&D
Sitraka (now part of Quest Software)
"Performance is Mission Critical"
Why do ever need the code from GUI builder?
--
Best regards,
Mike Aizatsky.
-
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
Because the classes need to be maintained.
Tom
On Fri, 15 Nov 2002 19:55:07 +0300, "Mike Aizatsky"
<mike@intellij.com> wrote:
Which classes?
Yes, you should maintain the business logic. But why do you need to see the
code for layout?
--
Best regards,
Mike Aizatsky.
-
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
Mike,
What are your plans for the Aurora's GUI builder? Do you can lift the
foulard a little bit?
Cheers,
Tom
On Fri, 15 Nov 2002 19:55:07 +0300, "Mike Aizatsky"
<mike@intellij.com> wrote:
Thomas,
We have no specific plans yet.
--
Best regards,
Mike Aizatsky.
-
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
"Mike Aizatsky" <mike@intellij.com> wrote in message
news:ar3cpv$23v$1@is.intellij.net...
the
If the GUI builder creates code that doesn't do quite what I want it to,
then I'll need to either change the generated code (yuck) or have some other
way of modifying the code such as using my own components at design-time, or
replacing components with my own components at run-time.
I'm sure that's obvious to everyone, but I remember a GUI builder from a few
years ago that would generate code that the user was expected to modify in
order to have it do something useful.
And if the code isn't designed to be seen, perhaps the GUI builder should
produce .class files instead of .java files...
we are in progress :)
Best regards,
Vladimir Kondratyev
_____________________
JetBrains
Thomas Singer wrote:
>>Why do ever need the code from GUI builder?
>>
>>--
>>Best regards,
>>Mike Aizatsky.
>>----
>>JetBrains, Inc / IntelliJ Software
>>http://www.intellij.com
>>"Develop with pleasure!"
Hi...
for quite a while I was wondering why all the GUI builders create code for
just a composition of serializable objects. In my opinion composite GUI
elements should be just dragged together in a GUI builder and then
serialized for later use. The interaction between the GUI elements and the
code should be based on some lookup scheme (e.g. the basic elements are
assigned names which can then be referred to in the code handling the GUI
issues). This would not only ease GUI builder development but also would
cleanly separate GUI code from application code. Currently in all approaches
the GUI construction code and the event handling code are forced to be in
the same app. This is one of the biggest "ugglifiers" when I look at code
generated by current GUI builders.
I know that Serialization is currently not very usable for long term
persistence but I already read about XML serialization for Swing components
somewhere at SUN website .
An interesting article exemplifying this concept is MVP from former
Taligent:
ftp://www6.software.ibm.com/software/developer/library/mvp.pdf
BTW: I frequently use Dolphin Smalltalk for prototyping that uses the MVP
approach and I think it is really way cool!.
Ciao
...Jochen
I hope that any code produced by the GUI builder will be heavily
templatized - in the sense of the 'template method' refactoring.
The users' code - logic and/or ui tweaks should go in subclasses fo the
builder-generated classes.
This is an old-time approach for OO codegeneration (not necessarily UI
only) and I like it very much.
It frees the builder from worrying about merging its own well understood
code and foreign (for it, i.e. the users') code.
modyfiyng the builder code is only a last-resort.
Edo
Mike Aizatsky wrote:
--
Edoardo Comar
Cape Clear Software
http://www.capeclear.com
Download the New! Beta Release
http://www.capeclear.com/beta
Register for our Technical Webinars - Every Thursday via WebEx
See http://www.capeclear.com/news/webinars/ for details
No serialization!!! Keep in mind, that the application must be
obfuscateable!
Tom
Yep, the same here :)
Eugene
"Edoardo Comar" <ecomar@NOSPAM.capeclear.com> wrote in message
news:ar567u$dgo$1@is.intellij.net...
>
>
>
>
>
>
>
>
>
>
Guys,
We have come up with an approach of how to use a third-party GUI Builder tool whan developing with IDEA. I believe that someone has already mentioned that you can create UI in JBuilder and in parallel observe all the chnages in IDEA. What I think scares most people about GUI builders is the fact that they generate an awfull, unmaintainable and hugely incomprehensible in allot of cases code.
We chose to do the following, where it made sence.
You develop your UI in JBuilder, NetBeans, ...
Then instead of considering that your UI, you specialize
the classes with also Presentation classes, which are not saturated with GUIBuilder's mambo-jambo.
Ex.
UserAuthenticationForm
- build by JBuilder
- jText1 (meant to contain user name)
- jPasswrd1 (meant to contain user's password)
- jbInit() (huge mess)
UserAuthenticationView extends UserAuthenticationForm
- built by you
- userNameField (alias for jText1, assigned in constructor of UserAuthenticationView
- userPasswordField (alias for jPasswrd1, assigned in constructor of UserAuthenticationView
- ..
In this approach, you leave the code created by GUI builder untouchable, which in my opinion it should be (the stench emanating from that code can not be tolerated ;)
You create aliases for all the fields that mean something to you and you need to process, you implement event handlers, where they could be easier implemneted.
I can just say that for a more or less complex screen generated by JBuilder with 600 lines of code a subclass had approximately 100 lines of code that was clear and easily read by the most novice developers.
My main point is that IntelliJ guys are already done so much for us, their work is so appreciated and so good that I personnaly don't really think that GUI Builder is of the highest priority.
Lets rather vote for HotSwap support in future versions.
Regards, Mikhail Shnayderman.
This is not really relevant to IDEA, but the rotten variable names that
JBuilder, NetBeans et al generate are easily changed from within the GUI
builder itself. It's just a matter of knowing how to use the tool (and not
being too lazy...). :) If you do that, then your subclass (which is a nice
idea, BTW) will be even simpler.
>
UserAuthenticationView
UserAuthenticationView
Vil.
--
Vilya Harvey, Consultant
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/
DisclaimerThis e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.
My only request would be that we have a way of disabling or not loading the gui builder. If you look at JBuilder, there are so many extras, like gui builder, jdbc pilot etc that the entire app is very slow.
Why do you think JBuilder is slow because of GUI builder or jdbc pilot?
Eugene
"charles decroes" <itnadmin@jetbrains.com> wrote in message
news:4824503.1037849789121.JavaMail.jrun@is.intellij.net...
the gui builder. If you look at JBuilder, there are so many extras, like
gui builder, jdbc pilot etc that the entire app is very slow.
If I recall correctly, JBuilder did not initialize the GUI builder code
unless you clicked on the 'Design' tab. Funnily enough, there was even a
plugin written to remove the 'Design' tab for people who didn't use the
GUI builder and didn't want the annoyance of a long pause if they
accidentally clicked on the 'Design' tab :)
N.
charles decroes wrote:
Peter Litvak wrote:
What's wrong with some LiveTemplates to generate GridBagConstraints? :)
Simon