My Missed Features of IDEA

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

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

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.

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

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

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

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.

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.

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

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

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
>

>