Post Ariadna Features

Vinay Moharil wrote:

1. Emacs style multiple editors open and viewable simultaneously

+50 - this would make like so much easier (especially when you're using
multiple monitors!

I'd also love to see api access to the parse tree so that I can add my
own code transformations and generators.

By increasing the size of the application

If you can download an entire JRE, you can also download a GUI builder. It doesn't have to be more than 1MB, so I don't see the problem. I can understand the fuss if it's a feature that no one is interested in, but this is clearly a useful addition for many.

requiring more memory resources, and slower startup
times.

Classes only get loaded when they are used. So you won't see slower startup times or a bigger memory use if you don't press that GUI builder button.

The classic failure mode of
programming environments is to attempt to become all
things to all people, and in the process become
bloated and slow. GUI builders in particular have
been notorious for this, which is why anti-GUI
builder sentiment is so strong.

I think that the big issue is that we've all seen GUI builder's from hell, creating awful spaghetti code. I don't think that there is a good reason to object to a good GUI builder. At least no more than any other kind of wizard.

My opinion is that such a beast is possible. I don't know whether IntelliJ is up to the task, it might not be their forte.

There's also a second-order effect.
IntelliJ/JetBrains has a limited amount of
development resources, and anything spent building a
GUI builder won't be spent doing integrated
metrics/profiling/UML
generation/whatever-your-favorite-extension is, and
also won't be spent tuning, optimizing, testing, and
debugging the core application.

Of course. But some people don't want IntelliJ to be working on X/Y/Z, but on a GUI builder. So this is a pretty silly argument to make.

Ideally, IDEA would be so modular that one could pick
and choose which pieces you want (yes to Ant
integration, no to any J2EE features), but we're a
long way from an ideal world.

Isn't that what the OpenAPI is for? Perhaps IntelliJ could start using it themselves so that some functionality is optional. This would make a lot of sense for things like a GUI builder.

By increasing the size of the application

If you can download an entire JRE, you can also
download a GUI builder. It doesn't have to be more
than 1MB, so I don't see the problem.

You must be joking. Even a minimally functional GUI builder is going to be far bigger than 1MB, probably at least 10x bigger than that.

requiring more memory resources, and slower

startup

times.

Classes only get loaded when they are used. So you
won't see slower startup times or a bigger memory use
if you don't press that GUI builder button.

This is neither gauranteed in theory (the spec allows JVMs to load classes pretty much whenever they want), or true in practice.

The classic failure mode of
programming environments is to attempt to become

all

things to all people, and in the process become
bloated and slow. GUI builders in particular have
been notorious for this, which is why anti-GUI
builder sentiment is so strong.

I think that the big issue is that we've all seen GUI
builder's from hell, creating awful spaghetti code. I
don't think that there is a good reason to object to
a good GUI builder. At least no more than any other
kind of wizard.

Personally, I would venture that code generation is the wrong way to go. Generating UI's as data files and having driver methods that understand those files and can link them to code has been a better bet, historically. Sadly, Swing itself just ain't there, yet.

There's also a second-order effect.
IntelliJ/JetBrains has a limited amount of
development resources, and anything spent building

a

GUI builder won't be spent doing integrated
metrics/profiling/UML
generation/whatever-your-favorite-extension is,

and

also won't be spent tuning, optimizing, testing,

and

debugging the core application.

Of course. But some people don't want IntelliJ to be
working on X/Y/Z, but on a GUI builder. So this is a
pretty silly argument to make.

In theory, I agree. In practice, the scope of a GUI builder is far larger than pretty much any other proposed feature I've seen, probably bigger than all of them combined. It's certainly would be a bigger effort than everything that got added in Ariadna to create a GUI builder with the level of quality and completeness that we have come to inspect from IntelliJ. That means that if a GUI builder goes into the next release, pretty much everything else has to go out, or at least be drastically curtailed, unless IntelliJ/Jetbrains are planning to increase their dev effort accordingly. Quantity, as they say, has a quality all it's own.

Ideally, IDEA would be so modular that one could

pick

and choose which pieces you want (yes to Ant
integration, no to any J2EE features), but we're a
long way from an ideal world.

Isn't that what the OpenAPI is for? Perhaps IntelliJ
could start using it themselves so that some
functionality is optional. This would make a lot of
sense for things like a GUI builder.

This, I agree, would be lovely (especially if they add a GUI for managing plugins).

I do agree that the optimal solution would be to have an open source, IDE-independent GUI builder, based on a description instead of code (readable XML-files probably). Preferably this would be included in IDEA, JEdit and other editors through fairly thin plug-ins.

These projects seem to have the right idea, although they are at version 0.0001 and GPL'ed:

http://jgb.sourceforge.net/
http://jui.sourceforge.net/

This one is a bit more serious:

http://gart.sourceforge.net/index.shtml

An alternative is that IntelliJ buys and integrates a commercial GUI builder like the one at:

http://www.jeasy.de/index.htm

It would seem to me that a GUI Builder would be a fine addition to IDEA...Perhaps as a separate product. I mean..How much can we expect our IntelliJ friends to throw into this thing for 400 dollars.

It would seem to me that New Products based on the IDEA OpenAPI would start development.

- GUI Builder
- Profiler

Are the two I've seen mentioned most often.

Clearly there is demand for a GUI Builder, and clearly there is strong resistance from a core part of the IDEA customer base to making it "standard equipment". I liken it to the Automatic vs. Manual transmission arguement in automotive circles.

As for a Profiler, it is my belief, based on what I have seen from other commercial profilers, that our intelliJ friends could write one of these in 2 consecutive weekends in their garage.

Mike

Guys,

Maybe you should consider filing enhancements in the
tracker
(http://www.intellij.net/tracker/idea/browse)

In the end, yes, that is exactly what should be done. But this is a good discussion where people are exploring the different "themes" they want for a release.

When you post your "feature" through the tracker, it doesn't get much opportunity for discussion or review by the community. The forums are much better for that. In fact, I am not sure I want to file ANY SCR's until after our IntelliJ friends announce the theme of the next releasse. What is the point of me putting together a set of SCR's for a GUI builder if that isn't even in the picture.

Mike

You said:
-

You must be joking. Even a minimally functional GUI builder is going to be far bigger than 1MB, probably at least 10x bigger than that.

=> You're wrong, NetBeans form editor is only 2 MB, and it's the best I've seen so far. No fancy special component integration features here (like Tekadance Magik), just a professional GUI builder.


You said:
-

Personally, I would venture that code generation is the wrong way to go. Generating UI's as data files and having driver methods that understand those files and can link them to code has been a better bet, historically. Sadly, Swing itself just ain't there, yet.

=> NetBeans form editor just does that. It uses an XML file to store the GUI definition, and generates the corresponding Swing code when requested/required.

Example:
-

Ability to ctrl+n to inner classes and package level multiple classes defined one file

public class A {
private class B {
}
}

or

public class A { // defined in A.java
}

class B {
}

Need to be able to ctrl+n to B, not just A.

Hello,

A GUI builder sound like a good idea. Maybe it would be possible to use the one form NetBeans (as it is open source). Idea could leverage from other IDE's.

The same principal could be applied to other features / plugins.

It should be possible to build an adapter around the GUI builder.

Any ideas, thoughts..

Cheers
Gavin

+10000 for aspectj sup
-infinity for GUI buider/designer(it can be a plugin, and i will never use it)

-infinity for GUI buider/designer(it can be a plugin,
and i will never use it)

+Infinity for a GUI designer.
Hmmm, we've ended up with a NaN ;)

A GUI builder sound like a good idea. Maybe it would
be possible to use the one form NetBeans (as it is
open source).

Although there doesn't seem to be a license problem, a developer said on a Netbeans mailing list that the GUI builder is strongly integrated with the rest of the IDE. It cannot easily be used as a seperate product (only after a big rewrite).

As already mentioned before, the preferrable way for submitting features is
the Tracker. You may either submit new features or vote for already
submitted ones. This way you requests will be processed. Posts to the
newsgroups even if read by the developers might not be processed.

--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"

"Pietro Polsinelli" <itnadmin@jetbrains.com> wrote in message
news:3276944.1035807154915.JavaMail.jrun@is.intellij.net...

+1 for swing

On Mon, 28 Oct 2002 12:12:34 +0000, Dave Griffith wrote:

*Spell checker (for comments), ideally linked in with inspections

And string literals.

---GUI Builder

+++More JPDA Functionality
1) multiple debugging sessions
2) Class Hot Swapping

In the tracker there is a request to support JDK 1.4 code hot-swap during debugging, but is not assigned to any version.

IMHO, this is one of the critical features for large J2EE projects when re-deployment takes too long time (e.g. with WebLogic).

Originally being mostly IntelliJ users, more and more of our team members migrate to Eclipse where hot-swap supported as of spring (AFAIK).

Sergey