Your Five Favourites Features For 4.0
What would change your java programmer's life, and how can IDEA make it
happen?
With 1110 features requests currently open/submitted in the tracker, the
voting system won't do any good at hinting IDEA people about what we
wish/need.
What does your wish list look like. No, what are the 5 first items on
your wish list?
Don't think too much, don't search : what do you miss today?
(Keep the lists short : no need the replicate the features tracker!)
Alain Ravet
Please sign in to leave a comment.
Done. Thanks Edo!
--
Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
Well, for that specific example, what about using some variable that one
could define ?
There might be several property sheets with custom properties, such as
constants that you might use in all your components that may require it ?
A global property sheet for the whole Swing application, and a property
sheet for each dialog, each window, each panel, etc...
And when I think about XML representation of a Gui, I also think of the way
we can define variables in an XSL stylsheet.
It'd be easy to define a variable specifying the 2 to 4 pixels standard
distance !
Guillaume
"Guillaume Laforge" <glaforge@reflexe.fr> wrote in message
news:askq8b$ej5$1@is.intellij.net...
>
You're right, and the GUI builder could help you create that property sheet
by applying some refactorings to your code. Perhaps a "replace with property
sheet entry" refactoring...?
way
This leads nicely into something I've been thinking about lately. I think it
ought to be possible to write a GUI builder which lets you design a UI
visually, then applies a set of user-specified rules to that design to
generate the Java code for it. It would seem logical to store the graphical
design in an XML file and use XSL to transform it, although that wouldn't
necessarily be required. The transformation would probably need to be
bidirectional though, so that changes to the generated code could be picked
up back in the GUI code. I need to think this through a bit more, but on the
face of things it seems like an idea with some potential.
Vil.
"Thomas Singer" <idea@regnis.de> wrote in message
news:3dedd8fe.7000115@news.intellij.net...
>
Good point. This is something that has almost entirely kept me from using a
GUI builder for Swing so far. Well, that and the awful code that they all
seem to generate.
>
Another thing to add to the list:
- A GUI builder that doesn't require a specific structure in the source file
in order to edit it (e.g. JBuilder's requires a jbInit() method).
It's not impossible, just very very difficult.
Only with current GUI builders, not in our wonderful hypothetical
refactoring GUI builder! :) You would have been able to go through each of
these classes as you created them and do a "Replace with value from global
property sheet" refactoring, which would bring up a dialog listing all of
the properties available in that sheet and add a new one if necessary, then
select the appropriate property from the list and modify the code to use it.
Hmm. There's always this: http://www.w3.org/Encryption/2001/ But XML may not
be necessary. It may be easier to use a binary file format (instead of, or
as an equal alternative to, the XML format).
Vil.
Please count me among those that do NOT want to see a GUI builder added
to IDEA. We still need more work done to facilitate server-side
development, and a good GUI builder would be a major effort that I think
would "bloat" IDEA too much.
I would rather see:
1. Support for JavaScript in JSP code editors
2. Better, "turnkey" JSP debugging option with support for emerging standard
3. Integrated JUnit test runner
4. Hot-swap compilation during debugging
5. Support for Aspect-J programming
On Wed, 4 Dec 2002 14:55:26 -0000, "Vilya Harvey"
<vilya.harvey@digitalsteps.com> wrote:
No, I do not want to keep people from taking a look into the XML file.
But the XML file would reference the component's classes and these
will change their names during the obfuscation process, so the class
names in the XML file must be replaces with their obfuscated
counterparts. But this would limit the usability of this GUI builder
to obfuscators, that support such a replacing in text files.
BTW, I never would want to use binary files for such a information
storage.
Tom
"Charlie Evett" <evett@marketsoft.com> wrote in message
news:asl6ab$8fi$1@is.intellij.net...
>
>
standard
You seem to be assuming that users of IDEA are only doing server-side
development. I'm curious: what gives you this impression? I'm personally
using it for a mixture of JSP/Servlet and Swing development at the moment.
I also wonder why so many people like yourself seem to think that a GUI
builder would bloat IDEA. I think the OpenAPI is heading towards a level of
maturity where it would be sufficient for this, so it could be provided as a
plugin. I already run IDEA with the simpleUML plugin installed and I haven't
noticed it detracting from my development pleasure in any way - it even adds
to it sometimes; why should a GUI builder be any different to this? And if
it does cause a slow-down, or hog memory, or whatever, you could always
uninstall the plugin...
Vil.
Sorry, the "we" refered to the developers working here at my company, it
was not meant as a general opinion on what other users of IDEA are doing.
If the GUI builder could be done as a removeable plugin, that obviously
wouldn't have the bloating effect. However, I'm a little skeptical that
a revolutionary GUI builder as has been discussed could be done that
way, though perhaps.
For sure the developer resources from JetBrains required to create a GUI
Builder would mean significantly fewer resources available for other
features that my team would actually use.
Vilya Harvey wrote:
>>Please count me among those that do NOT want to see a GUI builder added
>>to IDEA. We still need more work done to facilitate server-side
>>development, and a good GUI builder would be a major effort that I think
>>would "bloat" IDEA too much.
>>
>>I would rather see:
>>
>>1. Support for JavaScript in JSP code editors
>>2. Better, "turnkey" JSP debugging option with support for emerging
>>3. Integrated JUnit test runner
>>4. Hot-swap compilation during debugging
>>5. Support for Aspect-J programming
"Thomas Singer" <idea@regnis.de> wrote in message
news:3dedd8fe.7000115@news.intellij.net...
For this particular example, the IntelliJ team would probably realize that
this would need to be a global setting and store it somewhere globally.
But for all settings, it might be useful to be able to specify a value, a
constant variable, a static method somewhere, or a method of the component
that can be overridden.
"Charlie Evett" <evett@marketsoft.com> wrote in message
news:asll3i$22u$1@is.intellij.net...
It's quite possible that a GUI builder won't "bloat" the application even if
it's built-in and not a plugin.
But a GUI builder might sell a lot more copies of IDEA, which means more
resources for the GUI builder and more resources for IDEA in general.
If I were IntelliJ, I'd spend all my resources on getting a GUI builder out
the door that is good enough so they can start selling more licenses. Then
they can use the additional revenue to hire a few more developers to work on
improving the GUI builder and improving the rest of the app as well.
"Charlie Evett" <evett@marketsoft.com> wrote in message
news:asll3i$22u$1@is.intellij.net...
>
>
This is a fair point. But surely the same could be said for AspectJ support
(for example)? It's not something I would be likely to use & it would be
taking resources away from the team developing that revolutionary GUI
builder... :) I guess one mans meat is another mans poison for something
like this, and the same will be true for any major feature. I just don't
like seeing this particular feature get badmouthed into oblivion on the
basis of some assumptions which may turn out to be false.
I definitely agree that Hot-Swap debugging would be good to have, and nicer
JUnit integration would be good too. The JavaScript support is an
interesting idea too...
Vil.
>
moment.
of
as a
haven't
adds
if
>
My five favorites are
1. Integration with Make, for us who don't use Ant.
2. i18n string completion. See tracker #3899
3. File exclusion with wildcards. See tracker #5504
4. GUI builder
5. UML tool with code generation and patterns support
Since I didn't use my fifth wish yet:
5. Pattern matching in path definitions (like the way ant it, or with regular expressions) (exclude paths, classpaths, etc).
I think I didn't use my 5th...
I'd love to see code completion anywhere, most notably it is missing for me
in the debugger when I add a new watch or inspect an expression.
Amnon
1. Debugger Hot Swap - JBuilder and Eclipse are ahead of the game on this one. For me, this feature is so compelling that it should top JetBrain's priority list. I think it should be part of a 3.1 release.
2. Debugging multiple targets at once
3. GUI Builder - A lot of people are against this but I really think the Intellij guys can do a good job. JBuilder's UI designer is so buggy and difficult to use that I don't think it would be too hard to beat. BTW, I do actually use JBuilder's designer once in a while. After you get used to its numerous quirks it is quicker than coding UI's by hand, primarly because of the quick visual feedback you get about your choice of layout constraints (the benefit of this might be negated somewhat if we had hot-swap :)).
On Tue, 03 Dec 2002 07:20:38 +0000, Amnon I. Govrin wrote:
JEdit's AntFarm task has an option to run Ant within the same VM, and
makes things REALLLLLLLY fast.
However, there used to be a problem somewhere that javac wasn't properly
releaseing memory or gc, so after awhile the heap memory was being used up
and things would crap out. ( well, afaik it was a problem with javac ).
mark
On Mon, 02 Dec 2002 18:14:01 +0000, Josh Knowles wrote:
Sounds like a clover plugin would be better.
My wishlist is weighted towards seeing JetBrains selling millions of copies of IDEA so they can continue to make great products:
1. Beat out Eclipse, Netbeans, and Forte with regards to plugin standardization. OpenAPI must become the standard, not whatever IBM is trying to push. Recruit some third-parties to make IDEA plugins and evolve the API until it's rock-solid. This will make doing a good GUI builder possible.
2. Beat out JBuilder with regards to the 'whole product'. The features of JBuilder may not be the best, but the people paying for JBuilder licenses don't look at feature quality as much as they look at perceived completeness of feature-set. To win over JBuilder customers (and their money), you must not give them any excuses NOT to buy IDEA (and they will try very hard to find excuses). This will require a GUI builder, whether hard-core fans like it or not. Fortunately, you can make it as a plugin that can be excluded (See item 1 above ;-). Also, it will require a profiler, a UML modeling tool, and more variety and completeness in J2EE integration. Most of these should be plugins, and they don't even need to be better than JBuilder's versions in order to start getting those big customers. Think of it, it could be half or even a quarter of JBuilder's GUI builder, but all you have to do is tell them it's 'from the team that makes the best Java IDE GUI'! They'll buy it.
3. Make IDEA even more accessible to new users and new programmers. This includes more thorough documentation, and some tutorials and quick start guides would be great. A short tutorial on refactoring would add a lot of value.
4. IDEA should always aim to be #1 at something, so JetBrains can persuade more and more people to switch over to it. I think an ideal niche market would be Extreme Programmers and Test-First Developers. Right now JUnit and Ant are the #1 XP tools; IDEA should be #1. I want to see Kent Beck and Ron Jeffries and all the people on WikiWiki (http://www.c2.com/cgi/wiki?WelcomeVisitors) shouting the praises of IDEA. This will require much much tighter JUnit integration, better and more refactorings and intentions. One particular refactoring that needs to be absolutely conquered is Move Method; it's far too limited right now. Better TODO features and maybe a task list (a la story cards) would help a lot too.
5. Hotswap - Okay, this is just something I'd personally like to have. :-D
I think, if JetBrains would use the OpenAPI themself to create some
new functionality as plug-ins, than this would be a perfect base to
make the OpenAPI more powerful, stable and round.
Tom
"Rob Harwood" <rharwood@ptc.com> wrote in message
news:5216609.1039131891421.JavaMail.jrun@is.intellij.net...
It will also require support for Smalltalk and Ruby :)
1) Fully customizable tool bars and buttons for every feature (like MSDev)
2) MRU editor navigation (like Ctrl-Tab/Ctrl-Shift-Tab in MSDev, or
Alt-Tab/Alt-Shift-Tab in Win2k's fast task switcher)
3) Full keyboard macro recording and editing and playback (ability to name a
sequence of commands and keystrokes and bind them to a key, as well as
simply record an anonymouse sequence of key strokes and play them back)
4) Ability to see the green/yellow/red status of a group of files at once
(in the editor tabs and/or in the project view)
5) Ability to 'float' editor windows like you can float tool windows,
allowing you to view two source files at once, and spread source files
across multiple monitors
"Alain Ravet" <alain.ravet.list@wanadoo.be> wrote in message
news:as5dj8$g84$1@is.intellij.net...
>
>
>
>
>
>
>
Clover is commercial so if Intellij can do it pretty easily then I would
rather give them the money.
"Mark Derricutt" <mark@talios.com> wrote in message
news:pan.2002.12.05.22.20.44.510495@talios.com...
>
>
1) Better emacs emulation (magic tabs)
2) Better emacs emulation (multiple kill buffers)
3) Better emacs emulation (ability to start selection)
4) Better emacs emulation (better keybinding support for emacs style binds)
5) Lower memory consumption
Can you tell I'm an emacs user? ;)
I would love IDEA to support C#.
No kidding.
I could live without those fancy features like advanced refactoring for some
time :), I would just appreciate the comfort IDEA provides.
Ales Pour
Ales Pour wrote:
Shhh, we don't want Microsoft buying IntelliJ/JetBrains. Future Java
development would end immediately once Microsoft took control despite
Microsoft's assurances to the owners of IntelliJ that they intend to
support Java forever. I do want to see the folks at IntelliJ richly
rewarded financially, but I hope it isn't a Microsoft purchase.
Jon
Okay, in order:
1) Progress indicator for any operation that is expected to take longer than about half a second. This should be a status message and an hourglass on the cursor. I have had far too many times when the UI wouldn't respond and I didn't know why. (NOT just gc)
http://www.intellij.net/tracker/idea/viewSCR?publicId=7786
2) Better Emacs emulation.
- control-s, control-s should repeat the last incremental search.
- hitting control-s again should find the next match in an incremental search
- tab should be bindable to something that always puts the current line where it should be, just like emacs does. "Auto-Indent lines" comes close to this, but doesn't put the cursor in the right place.
- emacs control-space start-selection. Keyboard combination to start selecting text, followed by moving the cursor to select.
3) Background synchronization. I run my code on solaris (unavoidable) and edit on windows and use samba (network drive) as my primary project directory. Synchronization takes several minutes. It would be very nice to be able to continue editing in this case.
4) Better documentation, better help. I still can't find anything to read about synchronization, help search doesn't seem very complete, is slow, is not printable, etc.
5) wildcards in exclusions
http://www.intellij.net/tracker/idea/viewSCR?publicId=7547
http://www.intellij.net/tracker/idea/viewSCR?publicId=7281
http://www.intellij.net/tracker/idea/viewSCR?publicId=5504
http://www.intellij.net/tracker/idea/viewSCR?publicId=3135
6) Support arbitrary command line programs with output parsing. I would like to use ant remotely via ssh, (much like some people use cvs) and my other editor can handle the output from that as a build, and go to the build errors as if it were a local build.
7) Dock windows with other layouts, kinda like Visual Studio. Specifically, I want the bottom windows to NOT go to the left edge of the screen, I.E. the left window is always top to bottom.
8) Really getting nitpicky: I'd love to be able to change the font for the project window independently from the rest of the application... I don't need my class names as big as the menus.
1 Code Formatting enhancement:
Format Code before checking in to cvs
Format Code before checking out from cvs
Format Code while saving (optional)
2 Code Formatter for HTML, JSP, Javascript and mixtures of it
3 Depther feature documentation
4 Pattern integration (GoF, Sun)
5 Simple Profiling Tool
why would you do it?
;)
Just yesterday we discussed with colleagues that such things would be extremely cool to have. Have you already filed SCRs for them?
Sergei S. Ivanov wrote:
>>1 Code Formatting enhancement:
>> * Format Code before checking in to cvs
>> * Format Code before checking out from cvs
>> * Format Code while saving (optional)
Here's an SCR that covers the first two options and it already has 110
votes at the moment. Feel free to pepper it with more votes. You might
want to add the 3rd option to the commentary in the SCR, but I'd be
interested to know the motivation.
http://www.intellij.net/tracker/idea/viewSCR?publicId=6389