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

IMHO there should be one or two minor releases concentrating on those issues
that foster the "pleasure" in developing.
For me Idea has lost somewhat of its magic due to its clumsiness in many details
(of course other IDE often are outright stupid, but that shouldn't be the yardstick).
These are a miriad of small thing were Idea could be a little more clever, like
- automatically name a run configuration after the main class (if it was yet untitled)
- automatically enable a module's CVS support if it contains CVS folder (same for svn)
- in move refactoring across source roots: automatically suggest a sensible a target
src root depending on the package
- ...

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

Just don't use'em.

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

level 1.3)

No. Actually nowadays it is a very common scenario to develop with JDK 1.5,
but have language level 1.4 (as a first step in migration to Java 5).

  • * 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)

> * File templates must be on project level (as code style)
That conflicts a little with the current concept of having profiles.
But, yes much more settings need to be adaptable on project level.

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

Why?
Netbeans cannot deal with our complex ant files, so in fact if I set up our
project in NetBeans I have two separate set of ant files.
Please there is no such convenient things like run/debug configurations in
NetBeans.

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

I hate those.

0
Comment actions Permalink

Hello Stephen,

>> Features not used at all (for me, sure):
SK> Just don't use'em.

I did (actualy did not) :) But i also want to remove those as plugins.


>> * Language level must depends on JDK (very strange use JDK 1.5 with
>> level 1.3)
>>
SK> No. Actually nowadays it is a very common scenario to develop with
SK> JDK 1.5, but have language level 1.4 (as a first step in migration
SK> to Java 5).

Hmm. "Just don't use'em" :)) Why level is needed?

>> * ANT must be used as compiler (inline ANT, not just a tool)
SK> Why?

Becouse, i like to use "one way" compiler. I need to say IDEA "Compile Project"
by using ANT. And IDEA must understand that this is compilation actualy and
use output.
Then i compile by IDEA, but make build to stage server suddenly ANT will
not work. But IDEA compile project fine. I want to know problem in ANT script.

--
Alexey Efimov, Java Developer
Tops BI


0
Comment actions Permalink

Alexey Efimov wrote:

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

  • TODO


That seems crazy to me! What do you do if you have a piece of code in a
large project that you want to come back to later?

0
Comment actions Permalink

  • * Commander


+0. I've never used the commander, but just having the (closed) tool window on the right doesn't bother me.

  • * Local History


-1. Local history is one of IDEA's most useful features, in my opinion. You may not need it all the time, but it's lovely to know it's there when you need it. LVCS has saved my butt more than once.

  • * Path Variables


+1, at least in it's current form.

  • * TODO


-1, TODO are unobtrusive, and relatively useful. I like to leave TODO notes before I leave for home. The next day, when I get to work, I just have to look at the TODO tab to remember what I was doing.

  • Language level must depends on JDK (very strange

ge use JDK 1.5 with level
1.3)


+0. It does make sense, but I wouldn't push it too hard. There may be unforeseen situations[/url] where one must be forced to use a compiler that doesn't match the desired language level.

Features that designed not correct (by my opinion)

  • Key maps must be on project level (as code

de style)


-1. Keymaps are a user preference, and it makes no sense to make this configurable at project level. You don't want to use different shortcuts in every project you develop.

  • File types must be on project level (as code

de style)


Code style can already be configured on a project level. And while I can see different file types configuration per project being somewhat useful, it's not one of those "oooh aaah" things. What would be REALLY useful, however, is an option to treat every unknown file as text.

  • Inspections/Intensions schemas must be on

on project level (as code style)


+1.

  • External Resources must point to project level

el files and store settings
on project level.


+1. A "Project Resources" configuration would be very useful for some projects.

  • * GUI Designer must use standard layouts


-1. IDEA's GUI designer is explicitely about using smarter layouts. Sticking to GridBagLayout and friends is pointless.

  • * ANT must have debugger


+1. My build files are short and straight enough so I don't need to debug then. However, I'm sure lots of people would benefit from something like this.

  • ANT must be used as compiler (inline ANT, not

ot just a tool)


-100, someone must stop this "ant as IDE compiler" craziness.

  • File templates must be on project level (as code

de style)


+1. Smart templates at project level might be useful too.

  • Perspectives (like in Eclipse, for debug, for

or development etc)


-100.

0
Comment actions Permalink
  • Language level must depends on JDK (very strange

ge use JDK 1.5 with level
1.3)


This is quite useful to us. We have some common libraries that are integrated with applications using different jdks. So we write the lib at 1.4 level, but compile and run it with both 1.4 and 1.5 during eng test. It's nice to have the ide's completion and inspections all keyed to the 1.4 language level, even when using 1.5.

  • ANT must be used as compiler (inline ANT, not

ot just a tool)


I can't imagine a full blown ANT script being intelligently comprehended by an IDE. It's too flexible and extensible. The only times I really miss ant-like features in idea is a) when I'm syncing changes between the project file and the build file (again, I don't think this will ever be adequately solved), b) I would love ant's pattern matching filesets when defining module libs, and c) I occasionally would like to disable idea's Make altogether. In addition to "Before Compilation" and "After Compilation", it'd sometimes be convenient to have a "Intead of Compilation". But that's a pretty minor feature, since I can just assign a keyboard shortcut to the target.

0
Comment actions Permalink

Hello Keith,

>> Features not used at all (for me, sure):
>> * TODO
KL> That seems crazy to me! What do you do if you have a piece of code
KL> in a large project that you want to come back to later?

BugTracker and no more else. But it not means that TODO is not usefull for
others :)

--
Alexey Efimov, Java Developer
Tops BI


0
Comment actions Permalink

Hello Marcus,

>> * Commander
>>
MB> +0. I've never used the commander, but just having the (closed) tool
MB> window on the right doesn't bother me.

Me too. But it eat me memmory :)))

MB>
>> * Local History
>>
MB> -1. Local history is one of IDEA's most useful features, in my
MB> opinion. You may not need it all the time, but it's lovely to know
MB> it's there when you need it. LVCS has saved my butt more than once.

Sure not remove this one. But make it as usual VCS.

>> * TODO
>>
MB> -1, TODO are unobtrusive, and relatively useful. I like to leave
MB> TODO notes before I leave for home. The next day, when I get to
MB> work, I just have to look at the TODO tab to remember what I was
MB> doing.

I'm use tracker. And do not like to index my files for TODO. I'm just want
disable this feature to increase performace, for example.

>> * Key maps must be on project level (as code
>> de style)
MB> -1. Keymaps are a user preference, and it makes no sense to make
MB> this configurable at project level. You don't want to use different
MB> shortcuts in every project you develop.

You should feel it, then you will map ANT target to shortcuts for one project,
and get wrong keymap in other project.

>> * File types must be on project level (as code
>> de style)
MB> Code style can already be configured on a project level. And while I
MB> can see different file types configuration per project being
MB> somewhat useful, it's not one of those "oooh aaah" things. What
MB> would be REALLY useful, however, is an option to treat every unknown
MB> file as text.

I not say about "ooh and aaah" :)) I just say that i think :)

>> * GUI Designer must use standard layouts
>>
MB> -1. IDEA's GUI designer is explicitely about using smarter layouts.
MB> Sticking to GridBagLayout and friends is pointless.

Hmm... JBuilder does it :) successfully, and peoples choose it for GUI Designer.

>> * ANT must be used as compiler (inline ANT, not
>> ot just a tool)
MB> -100, someone must stop this "ant as IDE compiler" craziness.

Only bullet stop me :))

>> * Perspectives (like in Eclipse, for debug, for
>> or development etc)
MB> -100.

And why? Tired? :)


Thanks!
--
Alexey Efimov, Java Developer
Tops BI


0
Comment actions Permalink

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

>> * ANT must be used as compiler (inline ANT, not
>> ot just a tool)
RE> I can't imagine a full blown ANT script being intelligently
RE> comprehended by an IDE. It's too flexible and extensible. The only
RE> times I really miss ant-like features in idea is a) when I'm syncing
RE> changes between the project file and the build file (again, I don't
RE> think this will ever be adequately solved), b) I would love ant's
RE> pattern matching filesets when defining module libs, and c) I
RE> occasionally would like to disable idea's Make altogether. In
RE> addition to "Before Compilation" and "After Compilation", it'd
RE> sometimes be convenient to have a "Intead of Compilation". But
RE> that's a pretty minor feature, since I can just assign a keyboard
RE> shortcut to the target.

Again, until Marcus prepare shotgun, i try to explain this very bad idea.

If you Swing developer - this feature is not for you :)
If you Web developer, then let's imagine your development.
1. You coding, debuging with IDEA compilation
2. You fix something, and need to deploy it on stage server.
3. You call to admin and ask him execute ANT script from project to buil
system and deploy it to server.
...
4. After 3 hour, admin ask you and show you ANT script trouble - it do not
make native2ascii.

I'm always for my web projects make build by ANT. Always! Never by IDEA,
becouse if ANT script going wrong, i need know that.
On swing project, i'm using IDEA and do not using ANT, if it exists.

I'm just want to make compilation equals for Swing and for Web.

Thanks!
--
Alexey Efimov, Java Developer
Tops BI




0
Comment actions Permalink

Alexey Efimov wrote:

Becouse, i like to use "one way" compiler. I need to say IDEA "Compile
Project" by using ANT. And IDEA must understand that this is compilation
actualy and use output.
Then i compile by IDEA, but make build to stage server suddenly ANT will
not work. But IDEA compile project fine. I want to know problem in ANT
script.


So just assign a keyboard shortcut to the compile target of your Ant
build script and don't use IDEA's Make command. That's what I do.

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://www.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001

0
Comment actions Permalink

Alexey Efimov wrote:

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


Retroweaver is a terrifying hack that I would never use in production code.

On swing project, i'm using IDEA and do not using ANT, if it exists.


Why not?

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://www.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001

0
Comment actions Permalink

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


As the following post mentions, we are not inclined to adopt Retroweaver at this time. Adding new third party tools to our deployment is a moderately arduous process that I'd rather avoid for now. Instead we develop it with jdk 1.4, and eng test it with both 1.4 and 1.5. It's nice to switch between the jdk's in the dev environment without changing the language level. I like have the language level set to 1.4, because the ide will prevent me from unconciously doing something 1.5-ish, like forgetting to box and unbox.

Again, until Marcus prepare shotgun, i try to explain
this very bad idea.

If you Swing developer - this feature is not for you
:)
If you Web developer, then let's imagine your
development.
1. You coding, debuging with IDEA compilation
2. You fix something, and need to deploy it on stage
server.
3. You call to admin and ask him execute ANT script
from project to buil
system and deploy it to server.
...
4. After 3 hour, admin ask you and show you ANT
script trouble - it do not
make native2ascii.


When I say I like have 1.4 lang-level with 1.5 jdk, you say that's a convenience of limited value, as I could just remember not use the 1.5 lang features. Well, couldn't you just remember to run the appropriate ant target instead of running make? You can assign the target a shortcut, you can configure idea to run the target before a run/debug configuration...the only thing that's missing is the ability to make the Make button only run an ant target. That seems to be a convenience of limited value.

The only thing that would be really sweet is to integrate idea's module libraries with your ant script's classpaths. But that doesn't seem feasible to me, for the reason's stated elsewhere (e.g. ant scripts are too complex to programmatically comprehend).

0
Comment actions Permalink

Gordon Tyler wrote:

Alexey Efimov wrote:

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


Retroweaver is a terrifying hack that I would never use in production code.


I'm pretty sure Irida is RetroWeaved. It can't be so bad.

0
Comment actions Permalink

Indeed Irida is RetroWeaved. We had to patch it though due to bug with class
literal instruction weaving in precense of multiple classloaders.

-


Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"

Gordon Tyler wrote:

>> Alexey Efimov wrote:
>>
>>> 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...
>> Retroweaver is a terrifying hack that I would never use in production
>> code.
>>

I'm pretty sure Irida is RetroWeaved. It can't be so bad.



0
Comment actions Permalink

Indeed Irida is RetroWeaved. We had to patch it though due to bug with class
literal instruction weaving in precense of multiple classloaders.


So does this mean there is a chance we can expect a non retroweaved
version for download when all is said and done? So users would have a
JDK 1.4 version and 5.0 choice. About the only folks who would use the
1.4 only version are folks on OSX Panther.

R

0
Comment actions Permalink

IMHO there should be one or two minor releases
concentrating on those issues
that foster the "pleasure" in developing.
For me Idea has lost somewhat of its magic due to its
clumsiness in many details
(of course other IDE often are outright stupid, but
that shouldn't be the yardstick).
These are a miriad of small thing were Idea could be
a little more clever, like
- automatically name a run configuration after the
main class (if it was yet untitled)
- automatically enable a module's CVS support if it
contains CVS folder (same for svn)
- in move refactoring across source roots:
automatically suggest a sensible a target
src root depending on the package
- ...


I love it when IDEA surprises you with smart little touches like those mentioned above. With that in mind, I would really love to see IDEA automatically discover, and add, any jars it may find in a folder called lib (if it exists) under a newly defined projects directory structure.

0
Comment actions Permalink

I love it when IDEA surprises you with smart little touches like those
mentioned above. With that in mind, I would really love to see IDEA
automatically discover, and add, any jars it may find in a folder called lib
(if it exists) under a newly defined projects directory structure.


It already does this in irida if you're setting up a new project. Filed
it a while back and they implemented it. They add jars as module
libraries.

R

0
Comment actions Permalink

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


I can understand this. We currently have one team member on OS X Panther...but all of us on Windows are using JDK 1.5 and have occasionally caused the OS X user pain when we accidently used a JDK 1.5 specific thing. Moving the language target to 1.4 saves us from that. Once we get that machine up to Tiger and JDK 1.5 for OS X, then we'll be able to start really taking advantage of the features of JDK 1.5 and language level won't matter. But if your local machine has JDK 1.5 and you actually need to target 1.3, it's nice to be able to tell the IDE to point out when you use features not intended for that level.

Patrick

0
Comment actions Permalink

Me too. But it eat me memmory :)))


and ...

I'm just want
disable this feature to increase performace, for
example.


Looks like you're performance-paranoid. I bet the commander and TODO scanning affect IDEA performance much less than you'd imagine.

You should feel it, then you will map ANT target to
shortcuts for one project,
and get wrong keymap in other project.


Oh, you're right -- it's just that I've never mapped shortcuts to ant targets -- and maybe this is exactly why I've never done it.

Hmm... JBuilder does it :) successfully, and peoples
choose it for GUI Designer.


Hmm, JBuilder is definitely not a good example. I think JetBrains took the right decision about implementing a smarter GUI editor, one that's not bound to an existing layout manager.

If we're to talk about competition, just look at Matisse, the yet-to-come NetBeans GUI builder. It uses a custom layout manager, and it definitely looks nice.

MB> -100.

And why? Tired? :)


For the same reason I'd oppose the GUI builder supporting standard layout managers: this is just one of those "competition has it" items that don't add any real value.

Now, I'm all for improvements in IDEA's window management, but perspectives are not the right way to go, IMHO. I'd like to organize my tool windows in a more flexible way, but once I'm done with it, I don't need it to change for every different use case.

0
Comment actions Permalink

So does this mean there is a chance we can expect a
non retroweaved
version for download when all is said and done? So
users would have a
JDK 1.4 version and 5.0 choice. About the only folks
who would use the
1.4 only version are folks on OSX Panther.


This is pointless -- retroweaved code doesn't suffer in performance in any significative way. The only advantage of ditching retroweaver once and for all would be freedom to take advantage of all the new shining API's in 1.5 -- but that would break compatibility with 1.4 for good.

Oh, since we're talking about retroweaver, I have the obligation to promote my plugin, check it out from the Plugin Manager. It even includes the same patch Maxim mentioned above ;)

(O.T: heh, I'd love to know how my plugin would fare if it was used in IDEA development itself)

0
Comment actions Permalink

I like have the language level set to 1.4,
because the ide will prevent me from unconciously
doing something 1.5-ish, like forgetting to box and
unbox.


I'm sure that you know that, but just to be safe: Even if the language level is set to 1.4, if you're using a 1.5 JDK, IDEA won't prevent you from using new API's. Such code would compile fine with -target 1.4, but wouldn't run against a 1.4 JDK due to missing classes/methods.

0
Comment actions Permalink

It's nice to be able to tell the IDE to point
out when you use features not intended for that
level.


Again, this doesn't cover new classes/methods. Setting the language level to 1.4 won't prevent you from inadventently using StringBuilder instead of StringBuffer, for example.

In this aspect, if you retroweave your project, and verify the retroweaved classes agains a 1.4 JDK (shameless plug: Retroweaver Plugin does that automatically), you'll be safer than if you just set the language level to 1.4

0
Comment actions Permalink

Russell Egan wrote:



I like have the language level set to 1.4, because the ide will prevent

me from unconciously doing something 1.5-ish, like forgetting to box and
unbox.


If auto(un)boxing is the only 5.0 feature that you are worried about (as
it is in my case), then IMO this is a bit overkill as you won't be able
to use all the "good" language features in 5.0 like annotations,
for-each-loop, enums and generics.
Instead, I prefer to have the "auto-boxing" inspection set to "error"
which also prevents me from using that evil feature but does allow all
the other 5.0 enhancements.

Regards,
Jens

0
Comment actions Permalink

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


Please, never ever. ANT doesn't check any dependencies (or it's fixed)?, as the build-in compiler does. Sometime you have to recompile the complete project with ant. Idea solves this problem

0
Comment actions Permalink

Marcus Brito wrote:
>> It's nice to be able to tell the IDE to point out when you use
>> features not intended for that level.


Again, this doesn't cover new classes/methods. Setting the language
level to 1.4 won't prevent you from inadventently using StringBuilder
instead of StringBuffer, for example.


Well, there's the very useful "Usages of API documented as @since 1.5"
now, which would mark such things.

Bas

0
Comment actions Permalink

I agree with most of Marcus's comments, but want to comment on a couple of points.

  • Language level must depends on JDK (very strange

ge use JDK 1.5 with level
1.3)


+0. It does make sense, but I wouldn't push it too hard. There may be
unforeseen situations where one must be forced to use a compiler that
doesn't match the desired language level.


I run into this a lot with customers who, for one reason or another, do not want to rn on the latest VM. Being able to run the IDE uner a newer VM let's me take advantage of the newer VM while still building code that will run under the older one.

  • GUI Designer must use standard layouts


-1. IDEA's GUI designer is explicitely about using smarter layouts.
Sticking to GridBagLayout and friends is pointless.


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.

  • ANT must be used as compiler (inline ANT, not

ot just a tool)

>

-100, someone must stop this "ant as IDE compiler" craziness.


I am fine with ant as a tool, but I think the crazyness is to not use a structured build process like ant (except when one wants to compile one or two files). Using ant means that I can compile the soutrce on any platform that has a JDK and ant, If the build rules are built into a propriatary IDE build process, I'll need that IDE (assuming the source code contains the IDE's "build files") or I'll have to try and figure out how to set up my IDE so it can build that code. Ant also allows you to provide more functionality than just "compile the code", like build distribution files, install application, etc.

  • Perspectives (like in Eclipse, for debug, for

or development etc)

>

-100.


-1000000000000000000000000000000000000000000000

When I found out that I was going to have to pay full price to upgrade from 3.x to 4.0 I looked into switching to Eclipse. Perspectives are what kept me from switching because I had to learh how the IDE wanted me to work instead of having the IDE work the way I do, like Idea does.

0
Comment actions Permalink

Hello Marcus,

MB> Looks like you're performance-paranoid. I bet the commander and TODO
MB> scanning affect IDEA performance much less than you'd imagine.

Maybe. Ok forget it :)

MB> Now, I'm all for improvements in IDEA's window management, but
MB> perspectives are not the right way to go, IMHO. I'd like to organize
MB> my tool windows in a more flexible way, but once I'm done with it, I
MB> don't need it to change for every different use case.

I usefull really. Becouse:

  • Then you coding - you look into ProjectView and Editor

  • Then you debug - you no need ProjectView


Now you switch it manualy :) Don't say that you don't do hide/show toolwindows
for coding/debug switches :)

Thanks!
--
Alexey Efimov, Java Developer
Tops BI


0
Comment actions Permalink

True, I forgot about that one. You're right, with this inspection turned on you should be safe.

0
Comment actions Permalink

Alexey Efimov wrote:

Hello Marcus,

MB> Looks like you're performance-paranoid. I bet the commander and TODO
MB> scanning affect IDEA performance much less than you'd imagine.

Maybe. Ok forget it :)

MB> Now, I'm all for improvements in IDEA's window management, but
MB> perspectives are not the right way to go, IMHO. I'd like to organize
MB> my tool windows in a more flexible way, but once I'm done with it, I
MB> don't need it to change for every different use case.

I usefull really. Becouse:

  • Then you coding - you look into ProjectView and Editor

  • Then you debug - you no need ProjectView


Now you switch it manualy :) Don't say that you don't do hide/show
toolwindows for coding/debug switches :)


I don't. :)I only keep Project View open while coding, and the only
change for debugging is that I open the debug toolwindow.

0
Comment actions Permalink

Alexey Efimov wrote:

Hello Marcus,

MB> Looks like you're performance-paranoid. I bet the commander and TODO
MB> scanning affect IDEA performance much less than you'd imagine.

Maybe. Ok forget it :)

MB> Now, I'm all for improvements in IDEA's window management, but
MB> perspectives are not the right way to go, IMHO. I'd like to organize
MB> my tool windows in a more flexible way, but once I'm done with it, I
MB> don't need it to change for every different use case.

I usefull really. Becouse:

  • Then you coding - you look into ProjectView and Editor

  • Then you debug - you no need ProjectView


Now you switch it manualy :) Don't say that you don't do hide/show
toolwindows for coding/debug switches :)

Thanks!
--
Alexey Efimov, Java Developer
Tops BI

How is switching perspectives any better than explicitly hiding/showing toolwindows?
I like the fact that I can always get to a toolwindow by clicking on the button or using a
keystroke or two. Perspectives just make it more difficult for me to find the things that I
want to see because certain things are hidden from view even though their use is not
detrimental in any way.

A compromise might be to support "remembering" different configurations of the toolwindows
and allowing users to name them and specify different actions, like starting a debug
session, that will automatically cause a specified configuration to be used. This should be
entirely optional, and enabled toolwindow buttons should never be hidden. This might be a
good candidate for a plugin, written by/for those who like Eclipse perspectives.

Tim

0
Comment actions Permalink

Hello Tim,

TH> How is switching perspectives any better than explicitly
TH> hiding/showing toolwindows?
TH> I like the fact that I can always get to a toolwindow by clicking
TH> on the button or using a
TH> keystroke or two. Perspectives just make it more difficult for me
TH> to find the things that I
TH> want to see because certain things are hidden from view even though
TH> their use is not
TH> detrimental in any way.
TH> A compromise might be to support "remembering" different
TH> configurations of the toolwindows and allowing users to name them
TH> and specify different actions, like starting a debug session, that
TH> will automatically cause a specified configuration to be used. This
TH> should be entirely optional, and enabled toolwindow buttons should
TH> never be hidden. This might be a good candidate for a plugin,
TH> written by/for those who like Eclipse perspectives.

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

Thanks!
--
Alexey Efimov, Java Developer
Tops BI


0

Please sign in to leave a comment.