IDEA 4.0???
"IDEA 4.0 Comming soon" is getting kinda stupid. It's been there for months.
WHEN will 4.0 get released? We bought 3.0 in the belief that 4.0 would come soon with GUI support.
No such luck :(
Please sign in to leave a comment.
Release Candidate I is already announced, hope the final release comes
really soon :)
--
Ann Oreshnikova
Customer Support Manager
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"tim" <tim242@hotmail.com> wrote in message
news:30919551.1075110685361.JavaMail.itn@is.intellij.net...
months.
>
come soon with GUI support.
>
We looked into UI Designer in 4.0 using the early access program version.
The feature, I'm afraid, isn't very good and I would urge you to look into a different product for GUI development.
The JetBrains guys seem to have completely missed the point about rapid UI development. The UI designer is very limited and counter-intuitive and is going to leave quite a few people baffled! Although I hate tools like JBuilder and VisualAge, their UI support is miles ahead.
For instance, in order to emulate xy mode, you need to first organize your controls outside the panel and then tell it to lay things out approximately in a grid. That grid (actually a JPanel) must then be moved inside the main panel. Then you need to adjust things as the default fill is "both" :(
Also, the concept of "binding" is useless... certainly not productive. The idea is to decouple design and code, but this is certainly not the way to do it. They should rather generate mediators... To make things worse, when you put a class name in the bind field, nothing happends. So you click the light-bulb and get a new emtpy class... And there's no way you can quickly generate handlers. A lot of extra coding.
Also, the usage of "form" files is proprietary, though you can choose to generate source (which is really ugly)
All in all, the UI designer is a HUGE disappointment.
The rest of IDEA is quite good as before, but I certainly do not recommend 4.0 over 3.0 (more bloat, little news except for the badly designed UI designer)
>The feature, I'm afraid, isn't very good and I would urge
>you to look into a different product for GUI development.
If you wanted to use IDEA as your IDE, what tool would you use for GUI layout?
Probably going to use JBuilder 9 Personal, which is free and has fairly good GUI support.
I wonder how this is going to affect IntelliJ's popularity. My suggestion is that JetBrain should drop GUI support in 4.0. It's going to spawn a lot of "IntelliJ is awful" messages, when they are really talking about the UI Designer.
To be quite honest as primarily a J2EE developer I will probably never even use the GUI support in 4.0, however I was just wondering about your take on things because "remove it and save the IDE" is a pretty bold statement and I was wondering what in particular is so bad about it that in your opinion it's better removed entirely??
I'm not disagreeing with you, nor agreeing with you, as I have little experience either way with GUI support in IDEs, just curious as to what (in your opinion) is so wrong with the 4.0 one and how you would prefer to see it implemented.
RangerBob,
GUI developers have certain expectations when it comes to a UI designer. As I've noted before (rephrasing), the problems include:
1) Doesn't save the programmer from creating boilerplate code. All IDE's handling GUI development allows designers to create event handlers, for instance. Not so in IDEA 4.0.
2) Cannot synchronize Swing code manually written; must rather update the form XML or use the designer. Pretty useless in cases where some of the GUI code comes from elsewhere (i.e. cut'n' paste from existing projects, or when generating parts of the Swing code.)
3) The layout approach no good, to say the least. XY support is emulated through as strange "Lay out in a Grid" function.
4) The UI Designer in general is very, very confusing. Creating a basic Swing application mean generating and augmenting empty classes (which is created by clicking a light-bulb!), and it means writing tons of code manually.
5) The "form" format is highly proprietary and we cannot possibly distribute it in open source projects where most people use NetBeans or Eclipse. The alternative, which is to generate code, produces extremely bad code.
6) Several Swing widgets are not available in the toolbox. This may be fixed in the release version(?)
I think they should stick with the current goal (in which they have succeeeded): creating the best coding tool on the planet.
When they have a great UI Designer, then I may reconsider my position.
At any rate, I wish JetBrain the best of luck with the 4.0 release!
" and how you would prefer to see it implemented. "
That's an interesting question, since it is notoriously difficult to create a UI Designer supporting the academic and little pragmatic Swing design.
I'm sad to say that IDEA 4.0 RC1 is one of the worst approaches I've seen (for reasons explained in my other post)
Going from, say, the Visual Studio .NET GUI designer or Delphi, to ANY Java GUI designer is a terrible experience. It's like all creative abilities poors out of my brain.
There's currently not a single good GUI designer available that supports Swing. Yes, I've tried them all!
Yet, there are a lot of talented people around. This leads me to believe there is something fundamentally wrong with Swing (don't get me started on AWT)
Anyway... a good UI designer for Java must have these features:
1) Support XY layout. This is the only realistic layout model for complex GUI's.
2) Roundtrip Swing support. This means beeing able to cut Swing code from one IDE and paste it into IDEA. This is out of the question with the current design, due to the unfortunate "form" XML format.
3) It must support all Swing widgets and understand the model- and rendering behaviour associated with it.
4) It must be possible to (re)generate and navigate to event handler code.
5) It must allow separation of UI and application logic. The standard approach should be to use the mediator pattern and something similar.
6) It must support internationalization through resources.
7) It must support design-time editing of menus, toolbars (e.g. dropping other Swing controls onto it), bitmaps and other resources.
IDEA fails miserabely at most of these points.
In article <31796169.1075141013828.JavaMail.itn@is.intellij.net>,
Li24 <no_mail@jetbrains.com> wrote:
By "XY layout", I assume you mean placing UI elements at specific pixel
positions. I haven't done AWT/Swing stuff in a long time, but isn't the
entire point of AWT and Swing that you don't use specific pixel
positions?
Or was that their goal and it just doesn't work?
Is IDEA written that way, or does it use layout managers?
--
Erik Hanson
" but isn't the entire point of AWT and Swing that you don't use specific pixel positions?"
No, that's the point of certain layout managers. All production-quality GUI editors for Java have some kind of XY layout support (meaning, beeing able to place controls in absolute coordinates, which may or may not be pixels...)
In article <5716968.1075143380661.JavaMail.itn@is.intellij.net>,
no_mail@jetbrains.com wrote:
I'm assuming that you prefer to use absolute layout, at least some of
the time. Does this ever cause problems for you? I'm just curious; I
haven't done AWT/Swing in a long time...
If the coordinates aren't in pixels, what are they in?
No it isn't, XY is the worst layout model for complex guis. For
starters:
1. When the width/height of ONE component near the left/top of the
container is changed ALL the other components have to change their
position.
2. When some Look and feel property like Font Size is changed (because
the company decided it needed new Looks :) ALL the components have to
change their positions and widths/heights.
Round trip code analysis is always dificult, and I wouldn't really
expect it to import strange code in the first version.
I like xml specs for screen forms ;) And having the form specs outside
code leads to greater functionality when doing changes.
IMHO, Idea should have gone further and be capable of
interpreting/reading the xml files at run time: no need for
generating/compiling sources, allows for simple/fast customization on
customer sites and I haven't noticed any significant performance loss
when doing it.
For me this is the greatest advantage of interpreted forms: I implement
a change in the form reader/interpreter and it's instantly applied to
ALL the components in all the forms.
>
>
Looking at the release notes, Idea #998 announces support for I18N, but
I haven't looked at what it does.
The UI designer is a young product, so it has ways to go yet. Any
feature requests posted in the tracker are welcome :)
"No it isn't, XY is the worst layout model for complex guis. For starters:"
Well, we obviously have different experiences...
"I like xml specs for screen forms ;-)"
For me, it's not a matter of liking it or not. It's a matter of compliance, beeing able to exchange code with other people on other IDE's, beeing able to swap IDE in the future.
This thing is either a vendor lock-in strategy or an engineering mistake.
"The UI designer is a young product, so it has ways to go yet"
That's my point. JetBrain should wait until they have real UI support.
A high-quality product like IntelliJ deserves better. So do I, beeing a paying customer :)
it seems they have tried to emulate the QtDesigner concepts. it is VERY similar, but JetBrains implemented it in the wrong way.
what a disappointment. love intellij as a coding tool, but i will probably not use it for gui development
Carlos Costa e Silva wrote:
>>1) Support XY layout. This is the only realistic layout model for
>>complex GUI's.
Completely agree. Layout Managers are the way to go into future.
Absolute positioning is extremely inflexible and the major problem of
VB/VC++/Delphi GUIs.
Tom
PS: BTW, Li24 (aka no_mail@jetbrains.com), why you cannot use your real
name?
On Mon, 26 Jan 2004 12:59:44 +0000, Li24 wrote:
The last time I looked at JBuilder, the main thing that turned me off was
the code it injected into my classes, quite unsightly, from this approach,
I would have rather seen them generate code into an abstract superclass,
of which -my- code goes in the subclass.
Why do you say this? If I have a form with a heap of labels, images,
tabs, that don't have an action attached to them, I don't particularly
care about them, so having heaps of entries of button1, button2, button3,
label1, label2, label3 seem rather pointless, and just serve to clutter
the code.
And? The follows the whole intention paradigm that IDEA already has, it
alerts me to the fact theres a problem, and that I can get to it when -I-
want to.
In the project I'm just working on currently, alot of the handlers I'm
writing arnt on the visible components, there on say a table model, tree
selection model, things that arn't neccesary tied directly to the form.
Also, which method of handlers do you want? anonumous ActionListener?
Innerclass ActionLister, anonymous Action, inner Action, Actions from
another package, the options can be endless depending on the style of
development you do. Leaving it up to the developer IMHO is better.
Well, the forms compiler/generate is opensource ( at least, it was
mentioned it would be opensourced ), so its not exactly proprietary.
For you maybe, so far I'm liking it.
Mark
On Tue, 27 Jan 2004 04:41:19 +0000, Carlos Costa e Silva wrote:
Theres actually nothing to stop us from writing that functionality
ourselves. We don't need to byte-weave. Read the DOM tree at runtime,
create all the objects whilst walking the tree, if the field is bound,
bind it to the local variable. Shouldn't actually be that hard...
>> 6) It must support internationalization through resources.
Does this already. You can hardcode text, or select from a resource
bundle.
Mark
On Tue, 27 Jan 2004 08:32:23 +0000, no_mail wrote:
The fact they're open-sourcing the the compiler, with ant tasks for
building outside of IDEA suggests otherwise. Anyone is free to write
there own third party form designer, or write an XSLT transform to
convert to/from the Netbeans XML format, or Glade's format.
You dont HAVE to use it you know?
Yep I agree, XY == bad. XYLayout is only really useful for prototyping,
or for monkeys who just want to throw a load of components onto a form
and have them looking good quickly, but don't care about the quality,
portability, adaptability or flexibility of their work. (I guess that's
why so many are attracted to VB ;) )
I have been creating complex production-standard GUIs in java for over 5
years now and I have never once used an XY style layout (and I used to
be a Delphi programmer too). Mind you, I don't need or use GUI builders
anyway, and from what I understand nor do many developers who specialise
in UI. There are other more sophisticated ways of getting the ui built
without doing it by hand.
N.
Thomas Singer wrote:
>>> 1) Support XY layout. This is the only realistic layout model for
>>> complex GUI's.
>>
>>
>> No it isn't, XY is the worst layout model for complex guis.
JBuilder is certainly not perfect, but it is quite productive.
Err... you still need it, generated or not... The problem the original poster was talking about is the fact that the binding doesn't do much for you. A GUI builder is about letting you be more productive; write less code. IntelliJ's approach is dead wrong in that respect.
Well, you see, this is one place where IDEA's paradigm doesn't fit.
Not if it means writing tons of code and no gain. The proper approach is to let the GUI designer decide which handler approach to generate. As mentioned before, the mediator pattern was created to solve this exact problem and works really well.
"Open source" and "proprietary" are not opposites. The point is... you cannot possibly distribute project using IDEA forms because (at least in open source projects) end users expect to be able to use the project in whatever IDE they have.
I think it sucks big time. I've never been so little productive as with the IDEA UI designer. Simple things like setting the forms title or adding a toolbar takes forever (you must code).
That's not true. Ever heard of anchoring?
Ever heard of anchoring?
So they should wait 'till they got it right. At this point, they have locked users into a useless "forms" file format which doesn't allow me to distribute source code to open source projects.
Well, I have a feature REMOVAL request... I like IntelliJ 3.0, but I don't think 4.0 is ever going to get installed at my shop. Why bloat it with such a badly designed feature?
if you like the 3.0 version so much, than stay on it,
no one said that you have to use the GuiDesigner
from the 4.0 version, if you can live with the 3.0
than use it, we can live without your comments,
so PISS OFF!
No fond of loosing technical argument, now are you?
;)
"I have been creating complex production-standard GUIs in java for over 5 "
Yeah, right.
XYLayout is only bad if the tools supports it badly.
The XYLayout is the only way to go in complex GUI's. The problems you refer to disapperars when you employ anchoring
That's the way the best IDE's work... even Visual Studio.NET supports it now!
NO!
So what?
You obvisouly haven't worked on open source projects... If the participants cannot open the project in they're favorite IDE (like emacs!) without fuzz, then they are not going to go on. An alien XML format for doing GUI doesn't exactly help.
I'm certainly not going to use it, but I must be allowed to critize a bad product. This is the point of a Community forum.
Perhaps the excellent JetBrain people are more willing to listen to this than people like you; highly biased evangelists...
Read up on anchoring.
I'm sorry, did you know something about my past that I don't? Oh yes,
you're right, I've just been stacking shelves since university. Silly me!
You're completely missing the point here. XY layout is bad, full
stop. In fact the JDK doesn't even have an XYLayout class, XY layout is
just no LayoutManager whatsoever.
From the fact that you're harping on about anchoring, the layout you
want to be using is SpringLayout. It still doesn't allow you to place
things at specific x,y positions (as once again, that's bad) it just
allows you to specify the gaps between component edges in pixels and it
works everything else out for you. Now if IDEA doesn't support this
layout in the UI editor (I don't know as I don't need to use it), that's
something you can criticise, instead of it's lack of support for bad,
bad practices.
Why didn't VS.NET support it from the beginning? Have you ever
considered that anchoring might be a retrofit patch over a bad initial
design?
It's clear you haven't really used Java for UI's too much yet, and maybe
you were just expecting to jump into Java UI development with IDEA and
do all the same stuff you've been able to do when developing for your
native environment.
What you don't seem to be understanding is that the constraints are
imposed not by the IDE, but by the JDK and it's rules. Even if IDEA
did support an XY style layout with anchoring by some (messy) overlaying
of rules at design time, this could only be imposed within IDEA, and as
soon as something changed outside that environment it would all fall
apart.
Granted, UI construction may take longer the Java way, but thats only
because it is more extensible and generic. If you have the ability you
can still do everything that you can in other languages and more, but
you end up with a much more robust end product.
Nathan, he will not get it, no matter how much we tell him about bad
designs. Let him run ... maybe in a few years he will know it better.
Tom
Seriously, YOU also had no arguments why XY positioning ("layout" would
be too much) is better than layout managing. And, you would be the first
person who believes that fixed positions are good.
Tom
On Tue, 27 Jan 2004 16:04:28 +0000, no_mail wrote:
looks at various open source projects work on, maybe. I've worked on
some that used Netbeans, the moment I altered some code to change the
layout of the forms, the netbeans XML isn't updated, and I had problems
with that when the main dev got out of sync.
If your open source app depends on interoperability, don't use it.
Personally I would have liked to have seen JetBrains use the XUL DTD's for
their XML format, then it would at least be an open/standard DTD.
I wouldn't say highly biased, coming from Delphi, and having used
JBuilder/Netbeans and seeing the vomit they spewed forth, I'm interested
in the novel direction JetBrains are taking, and so far, I'm liking it.
On Tue, 27 Jan 2004 15:59:21 +0000, no_mail wrote:
And putting Visual Stupid.NET and "best IDE" in the same sentence isn't
helping your case :)
I bet you're all against XAML as well? ( it would be really nice if all
these XML formats would be consistent thou ).