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

177 comments
Comment actions Permalink

4) multiple debuggers per project - useful only if we have 3)
http://www.intellij.net/tracker/idea/viewSCR?publicId=7266
http://www.intellij.net/tracker/idea/viewSCR?publicId=5088
http://www.intellij.net/tracker/idea/viewSCR?publicId=3766
(intellij, you need to close some as duplicates)


Done. Thanks Edo!

--

Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"


0
Comment actions Permalink

Example: If I want to change the distance between components (in all
dialogs of an application!) from 2 to 4 pixels, I need to change one
line in our GUI framework. Try to do this with a GUI builder: you need
to take each dialog and change the settings of hundreds of components.


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


0
Comment actions Permalink


"Guillaume Laforge" <glaforge@reflexe.fr> wrote in message
news:askq8b$ej5$1@is.intellij.net...

Example: If I want to change the distance between components (in all
dialogs of an application!) from 2 to 4 pixels, I need to change one
line in our GUI framework. Try to do this with a GUI builder: you need
to take each dialog and change the settings of hundreds of components.

>

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


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

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 !


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.


0
Comment actions Permalink

"Thomas Singer" <idea@regnis.de> wrote in message
news:3dedd8fe.7000115@news.intellij.net...

"Vilya Harvey" <vilya.harvey@digitalsteps.com> wrote:

Imagine a GUI builder that supported refactoring...

>

"Encapsulate controls in custom component"
"Promote ActionListener to Action"

>

This is one key-problem of the known tools. Good UI design makes
extensive use of Actions (or more powerful subclasses), but in my
knowledge of GUI builders, only Delphi-like ActionListeners are
supported.


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.

"Convert Layout to GridBagLayout"

>

Imagine a GUI builder that supports:
- custom components (e.g. subclasses of JPanel, JTable, JTree; maybe
with no default constructor)
- component factories (e.g. JButton createButton(MyAction); JMenuItem
createMenuItemWithIcon(MyAction); JMenuItem
createMenuItemWithoutIcon(MyAction);)
- global distance settings (between components)
- powerful layout (e.g. OK and Cancel buttons have the same size and
are always right aligned in a ButtonPanel)
...


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

As more I think over the GUI builder's requirements the more I
believe, it will be impossible, because the most flexibility is only
available with a good GUI framework, that makes more high-level use of
the Swing components.


It's not impossible, just very very difficult.

Example: If I want to change the distance between components (in all
dialogs of an application!) from 2 to 4 pixels, I need to change one
line in our GUI framework. Try to do this with a GUI builder: you need
to take each dialog and change the settings of hundreds of components.


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.

What about obfuscation (a "must-have" for desktop applications), when
-- as some people suggested -- the whole GUI design is made with the
help of XML-files?


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.


0
Comment actions Permalink

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

0
Comment actions Permalink

On Wed, 4 Dec 2002 14:55:26 -0000, "Vilya Harvey"
<vilya.harvey@digitalsteps.com> wrote:

What about obfuscation (a "must-have" for desktop applications), when
-- as some people suggested -- the whole GUI design is made with the
help of XML-files?


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


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

0
Comment actions Permalink

"Charlie Evett" <evett@marketsoft.com> wrote in message
news:asl6ab$8fi$1@is.intellij.net...

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


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.


0
Comment actions Permalink

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:

"Charlie Evett" <evett@marketsoft.com> wrote in message
news:asl6ab$8fi$1@is.intellij.net...

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


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.


0
Comment actions Permalink

"Thomas Singer" <idea@regnis.de> wrote in message
news:3dedd8fe.7000115@news.intellij.net...

Example: If I want to change the distance between components (in all
dialogs of an application!) from 2 to 4 pixels, I need to change one
line in our GUI framework. Try to do this with a GUI builder: you need
to take each dialog and change the settings of hundreds of components.


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.


0
Comment actions Permalink

"Charlie Evett" <evett@marketsoft.com> wrote in message
news:asll3i$22u$1@is.intellij.net...

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.


It's quite possible that a GUI builder won't "bloat" the application even if
it's built-in and not a plugin.

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.


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.




0
Comment actions Permalink

"Charlie Evett" <evett@marketsoft.com> wrote in message
news:asll3i$22u$1@is.intellij.net...

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.


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

Vilya Harvey wrote:

"Charlie Evett" <evett@marketsoft.com> wrote in message
news:asl6ab$8fi$1@is.intellij.net...

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

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.

>
>

>


0
Comment actions Permalink

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

0
Comment actions Permalink

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

0
Comment actions Permalink

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


0
Comment actions Permalink

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

0
Comment actions Permalink

On Tue, 03 Dec 2002 07:20:38 +0000, Amnon I. Govrin wrote:

If Ant startup is a problem, one of the following could possibly be done:
1. Run Ant in a more eficient way, i.e. not launch a new JVM for it, but
run it internally.
2. If 1 is not currently possible, work with the Jakarta project
developers to enable it.


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

0
Comment actions Permalink

On Mon, 02 Dec 2002 18:14:01 +0000, Josh Knowles wrote:

Highlight methods which don't have tests, show report of test coverage
similar to that of Clover.


Sounds like a clover plugin would be better.

0
Comment actions Permalink

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

0
Comment actions Permalink

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.


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

0
Comment actions Permalink

"Rob Harwood" <rharwood@ptc.com> wrote in message
news:5216609.1039131891421.JavaMail.jrun@is.intellij.net...

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.


It will also require support for Smalltalk and Ruby :)


0
Comment actions Permalink

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

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

>


0
Comment actions Permalink

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

On Mon, 02 Dec 2002 18:14:01 +0000, Josh Knowles wrote:

>

Highlight methods which don't have tests, show report of test coverage
similar to that of Clover.

>

Sounds like a clover plugin would be better.



0
Comment actions Permalink

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? ;)

0
Comment actions Permalink

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


0
Comment actions Permalink

Ales Pour wrote:

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.


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

0
Comment actions Permalink

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.

0
Comment actions Permalink

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

0
Comment actions Permalink

  • * Format Code __before__ checking out from cvs


why would you do it?

;)

0
Comment actions Permalink

1 Code Formatting enhancement:

  • Format Code before checking in to cvs

  • Format Code before checking out from cvs

  • Format Code while saving (optional)


Just yesterday we discussed with colleagues that such things would be extremely cool to have. Have you already filed SCRs for them?

0
Comment actions Permalink

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)


Just yesterday we discussed with colleagues that such things would be extremely cool to have. Have you already filed SCRs for them?


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

0

Please sign in to leave a comment.