My Missed Features of IDEA

Hello,

Here my wish list for next EAP :)

Features not used at all (for me, sure):

  • Commander

  • Local History

  • Path Variables

  • TODO

  • Language level must depends on JDK (very strange use JDK 1.5 with level

1.3)

Features that designed not correct (by my opinion)

  • Key maps must be on project level (as code style)

  • File types must be on project level (as code style)

  • Inspections/Intensions schemas must be on project level (as code style)

  • External Resources must point to project level files and store settings

on project level.

  • GUI Designer must use standard layouts

  • GUI Designer must not collect bean and form into expandable tree node

(option)

  • ANT must have debugger

  • ANT must be used as compiler (inline ANT, not just a tool)

  • File templates must be on project level (as code style)

  • Any toolwindow must be closable


Features i expect for a long time:

  • Perspectives (like in Eclipse, for debug, for development etc)


Thanks!
--
Alexey Efimov, Java Developer
Tops BI


41 comments
Comment actions Permalink


Imagine, press Debug (Shift+F9) - and IDEA
automaticaly layout toolwindows
for Debug perspective. Finishing debug, and IDEA
restore Toolwindows.



Funny, my "Debug Perspective" for IDEA would be exactly what it does now...leave the tool windows I had open, open and then just open the Debug Tool Window. I had the other windows open for a reason, all I'm doing is adding the fact I want to debug now.

Rarely do I have a tool window open that I'm not using at that moment.

Eclipse perspectives have always bothered me because the UI, in the default setup for each one, so dramatically changes and I have to keep searching for what I was using before, or have to keep switching back and forth between perspectives. Sure, I can add things to each perspective that I want, but at some point, I would end up making them all look the same and then what would be the point?

One of the nice things about the tool windows is each one does a job and does it in a fairly compact way all on one screen.

I recognize that some people work better with the whole perspectives thing, but for me, I love the way IDEA works today. It's one of the many reasons I choose it over Eclipse. For those that like this sort of changing layout, I would say make it configuration for those people, but the default should be the way things are now.

Patrick

0
Comment actions Permalink

Alexey Efimov wrote:

Hello Tim,

Imagine, press Debug (Shift+F9) - and IDEA automaticaly layout
toolwindows for Debug perspective. Finishing debug, and IDEA restore
Toolwindows.


Alexey,

I don't have to imagine. I have used Eclipse but I didn't like it. The drastic changing of
the interface as I switched in and out of different perspectives really bothered me. If I
recall correctly, MS developer studio did the same when you started a debug session. I
didn't like that either.

I understand that some people like it. That is why I suggested that someone write plugin.
It should do exactly what you, and I, described.

Tim

0
Comment actions Permalink

Yeah, there's that. Typically, I develop with a 1.4 jdk, and only do small bug fixing while testingwith 1.5, and I'm careful not to use 1.5 APIs. And I think there's a inspection (arrived or coming soon) for detecting usages of the 1.5 apis.

0
Comment actions Permalink

Ralph Saunders <no_mail@jetbrains.com> wrote:

I have found a lot of resistance to useing the Idea layout manager, even
though it is open source and, IMO, is better than the standard ones.
Would JetBrains be willing to "donate" this layout manager to Java?
Since it is open source I would think that it wouldn't be a problem for
JetBrains and if it were a part of Java that would remove the only
argument that I have heard against it, naely that it is no a standard
Java layout manager.


I don't think that the Jetbrains layout manager should be added to the
JDK. Code that is added to the JDK stays forever (or has anybody ever
seen a deprected method that was actually removed?).

This also is the reason why Karsten didn't want his FormLayout to be
added to the JDK.


Best,

Dirk Dittert

0
Comment actions Permalink

Hello,

Here my wish list for next EAP :)

Features not used at all (for me, sure):

  • Commander

  • Local History

  • Path Variables

  • TODO

  • Language level must depends on JDK (very strange

ge use JDK 1.5 with level
1.3)


Funny, I use all these features. Local History has saved me a ton of time when I haven't checked in for a while and need to undo some major changes. The language level thing is useful when you are including 3rd party code in your project that was written against an earlier JDK (if just to avoid all the annoying warnings everywhere in your editor).

0
Comment actions Permalink

Oh, one more thing... I use IDEA in Linux with multiple monitors, and one thing I would love to be able to do is split off an editor window into a separate frame so that I can drag it to one screen for reference while I code in the other screen.


- Andy

0
Comment actions Permalink

Ok, I thought of something else. :) I've always wanted to have live word-wrapping for JavaDoc. As I'm typing JavaDoc, if I hit the right margin, wrap me to a new JavaDoc line. If I go up a few lines and insert new text, automatically wrap all the following JavaDoc. Just an option - not for everyone, but I would certainly use it.

0
Comment actions Permalink

Ok, I thought of something else. :) I've always
wanted to have live word-wrapping for JavaDoc. As
I'm typing JavaDoc, if I hit the right margin, wrap
me to a new JavaDoc line. If I go up a few lines and
insert new text, automatically wrap all the following
JavaDoc. Just an option - not for everyone, but I
would certainly use it.


That would be handy. However if you're entering some sample code you may not want it wrapping so a quick way to turn off this feature would be useful.

0
Comment actions Permalink

>> * File types must be on project level (as code style)
>> * Inspections/Intensions schemas must be on project level (as code style)

This will be too verbose. Maybe all this settings on IDE level that has support for schemas (Colors, Formatting, File Types, Inspections/Intentions, even maybe keybindings...) can have the option for schema to be choosen for every project.

Having 500+ Inspections/Intentions configured for each project is an overkill for sure.

Maybe even the last choosen schema (Colors, Fomatting, Intentions/Inspections) could be remembered for each project, thus freeing the user to have to configure them.

0
Comment actions Permalink

In article <2cac73a56478c755f3fe1a7633@news.intellij.net>,
Alexey Efimov <aefimov.box@gmail.com> wrote:

Hello Russell,

>> * Language level must depends on JDK (very strange
>> ge use JDK 1.5 with level
>> 1.3)
RE> This is quite useful to us. We have some common libraries that are
RE> integrated with applications using different jdks. So we write the
RE> lib at 1.4 level, but compile and run it with both 1.4 and 1.5
RE> during eng test. It's nice to have the ide's completion and
RE> inspections all keyed to the 1.4 language level, even when using
RE> 1.5.

I can't understand this. If you use JDK 1.5, why you do not use full JDK 1.5?
To get 1.4 compatible - Retroweaver etc. But how level can help, i can't
catch...


One of my clients has libraries that must work with 1.4, and so are
written and compiled against 1.4.

I am developing code against 1.5, and want 1.5 language support.
Because I can and do modify the library source as well as my new
project's source, I do not want the 1.5 language support, intentions,
etc. to apply to anything other than the code in my new project.

Scott

--
Scott Ellsworth
scott@alodar.nospam.com
Java and database consulting for the life sciences

0
Comment actions Permalink

Because you have 20 some-odd servers and sometimes you have to move
programs between servers. Unfortunately, it's going to take 3-6 months
to get downtime to get all of the servers and all the programs on the
servers cleared for 1.5 use. In that period your main machine may be
1.5, but you might have to move it to another machine.

I am in the same situation. We have all servers except 4 upgraded, but
I can't use any of the features for another month - maybe 2.

Scott Ellsworth wrote:

>In article <2cac73a56478c755f3fe1a7633@news.intellij.net>,

Alexey Efimov <aefimov.box@gmail.com> wrote:

>

>
>>Hello Russell,
>>
>>
>>
>>>>* Language level must depends on JDK (very strange
>>>>ge use JDK 1.5 with level
>>>>1.3)
>>>>
>>>>
>>RE> This is quite useful to us. We have some common libraries that are
>>RE> integrated with applications using different jdks. So we write the
>>RE> lib at 1.4 level, but compile and run it with both 1.4 and 1.5
>>RE> during eng test. It's nice to have the ide's completion and
>>RE> inspections all keyed to the 1.4 language level, even when using
>>RE> 1.5.
>>
>>I can't understand this. If you use JDK 1.5, why you do not use full JDK 1.5?
>>To get 1.4 compatible - Retroweaver etc. But how level can help, i can't
>>catch...
>>
>>
>
>One of my clients has libraries that must work with 1.4, and so are
>written and compiled against 1.4.
>
>I am developing code against 1.5, and want 1.5 language support.
>Because I can and do modify the library source as well as my new
>project's source, I do not want the 1.5 language support, intentions,
>etc. to apply to anything other than the code in my new project.
>
>Scott
>

>

0

Please sign in to leave a comment.