Post Ariadna Features
I thought I would start a thread on what folks might want to see in a post-Ariadna world. (i.e. 4.0). Perhaps out of this discussion we could write a set of Change Requests to be considered (or perhaps all the good ideas, are already there, and I just need to be pointed to them :)
1) More effective use of free screen space. I seem to be continuously fighting with IDEA on how to lay out things. I find the psuedo tabbed model a little akward, in that I usually have a significant amount of wasted space in the "corners". I would love to be able to split the screen, and see (for example), debug frame and find usages on the left side. (top/bottom layout), with the code on the right. I've tried the "undocked" mode, and just don't like it.
2) More effective filtering models for the debugger. I want to be able to build custom "renderers", for data types, and when I encounter the datatype, just display those things that I am interested in. This would be most useful in the "Frame" display, where we browse the active variables.
I'm sure there are others, just can't think of them off the top of my head.
Anyone else?
Mike
Please sign in to leave a comment.
Vinay Moharil wrote:
+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.
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.
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.
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.
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.
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.
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.
This is neither gauranteed in theory (the spec allows JVMs to load classes pretty much whenever they want), or true in practice.
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.
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.
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
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:
-
...
Just check this out:
http://form.netbeans.org
and
http://www.netbeans.org
Cheers.
Dan/
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 a GUI designer.
Hmmm, we've ended up with a NaN ;)
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...
On Mon, 28 Oct 2002 12:12:34 +0000, Dave Griffith wrote:
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