GUI builder

Hello,

It wasn't clear in a last thread on this subject is JetBrains going to start
work on this or
not? And if not does anybody think of doing this?

Could somebody clarify this please?

Thank you,
Peter


0

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...

Hello,

>

It wasn't clear in a last thread on this subject is JetBrains going to

start

work on this or
not? And if not does anybody think of doing this?

>

Could somebody clarify this please?

>

Thank you,
Peter

>
>


0

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.


"Peter Litvak" <plitvak@attbi.com> wrote in message
news:aquh6b$nog$1@is.intellij.net...

Hello,

>

It wasn't clear in a last thread on this subject is JetBrains going to

start

work on this or
not? And if not does anybody think of doing this?

>

Could somebody clarify this please?

>

Thank you,
Peter

>
>


0

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

0

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:

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


0

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...

Hello,

>

It wasn't clear in a last thread on this subject is JetBrains going to

start

work on this or
not? And if not does anybody think of doing this?

>

Could somebody clarify this please?

>

Thank you,
Peter

>
>


0

Thomas Singer wrote:

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"

0

On Thu, 14 Nov 2002 11:47:23 +0000, Thomas Singer wrote:

I've found this:
http://www.borland.com/news/press_releases/2001/05_01_01_patent.html
Tom


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

0

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

0

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

0

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:

Thomas Singer wrote:

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"


0

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

0

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...

Hello,

>

It wasn't clear in a last thread on this subject is JetBrains going to

start

work on this or
not? And if not does anybody think of doing this?

>

Could somebody clarify this please?

>

Thank you,
Peter

>
>


0

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"

0

Why do ever need the code from GUI builder?

--
Best regards,
Mike Aizatsky.
-


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


0

Because the classes need to be maintained.

Tom


On Fri, 15 Nov 2002 19:55:07 +0300, "Mike Aizatsky"
<mike@intellij.com> 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!"


0

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!"


0

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:

Why do ever need the code from GUI builder?

--
Best regards,
Mike Aizatsky.
------------------------------
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


0

Thomas,

We have no specific plans yet.

--
Best regards,
Mike Aizatsky.
-


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


0

"Mike Aizatsky" <mike@intellij.com> wrote in message
news:ar3cpv$23v$1@is.intellij.net...

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...


0

we are in progress :)

Best regards,
Vladimir Kondratyev
_____________________
JetBrains

Thomas Singer wrote:

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:

>>Why do ever need the code from GUI builder?
>>
>>--
>>Best regards,
>>Mike Aizatsky.
>>----


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



0

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




0

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!"



--
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

0

No serialization!!! Keep in mind, that the application must be
obfuscateable!

Tom

0

This is an old-time approach for OO codegeneration (not necessarily UI
only) and I like it very much.


Yep, the same here :)

Eugene


"Edoardo Comar" <ecomar@NOSPAM.capeclear.com> wrote in message
news:ar567u$dgo$1@is.intellij.net...

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!"

>
>

>
>

--
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

>


0

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.




0

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

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/

Disclaimer

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.


0

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.

0

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...

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.


0

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.



0

Peter Litvak wrote:

It wasn't clear in a last thread on this subject is JetBrains going to
start work on this or



What's wrong with some LiveTemplates to generate GridBagConstraints? :)

Simon

0

请先登录再写评论。