file tabs suggestion

Nice idea, I would like. But it shouldn't take too much extra space.

Florian Hehlen wrote:

I would like to be able to see more info in the tab icons:

-interface vs abstract vs class
-scope of the class


Any body like this or have other things they would like to see in the tabs?

Sure, I've always wanted to be able to see whether the associated class
file is up-to-date. I filed issue #4892 last October. See--
http://www.intellij.net/tracker/idea/viewSCR?publicId=4892

Jon

Nice idea, I would like. But it shouldn't take too much extra space.

Perhaps a different font face/style/color could be used for the filename, or
the filename could be preceded with a small icon, so very little, if any,
extra real estate would be used.

I don't think that any more real-estate needs to be taken up. Here are suggestions on how to mark differences:

-use the Project tree icons in the tabs,instead of the "J" icon.
-use different tab-background colors
-use different fonts/ font-styles (as already suggested)

This makes me think that sometimes it would be really nice to be able to close all editors that are not interfaces! I do not like having much more than a few files open but when some debugging or refacctoring has taken me through dozens of files it would be nice to just clear the slate but keep some key files open.... maybe this could be done if I could lock editors....


Florian

You forgot one:
- final class

Tom

Florian Hehlen wrote:

I don't think that any more real-estate needs to be taken up. Here are suggestions on how to mark differences:

-use the Project tree icons in the tabs,instead of the "J" icon.
-use different tab-background colors
-use different fonts/ font-styles (as already suggested)

This makes me think that sometimes it would be really nice to be able to close all editors that are not interfaces! I do not like having much more than a few files open but when some debugging or refacctoring has taken me through dozens of files it would be nice to just clear the slate but keep some key files open.... maybe this could be done if I could lock editors....

But you assume that one file = one class which is not true.
E.g. you can have public abstract top-level class containing final inner classes and
concrete utility class all in the same file.

However, I like the idea, just pointing the problems I see with the proposed implementation.

Regards,
Dimiter

But you assume that one file = one class which is not
true.
E.g. you can have public abstract top-level class
containing final inner classes and
concrete utility class all in the same file.

Yes you are right... I try to avoid inner classes except when they are supposed to be invisble to all but the top-level class in that file. And ince I seperate design from implementation I never do this kind of thing.

So yes you are right I wasn't thinking of such a situation... but maybe the tabs could also reveal that info somehow. Either in a tooltip ormat or in an expanded format show the the inner classes that are in each file.

I know it's a big religious debate as to whether inner clases are truely OO and if they are just plain good design. I know that when I started codeing Java I used to think that inner and anonymous classes should be avoided at all cost... now I find myself using them strategically but still worried every time I use them. I digress!

Florian

I would like to see the compilation status/code errors/code warnings on all class, interface and package icons, throughout the editor. Eclipse does this and it makes it nice and clear where compile errors are occuring without having to compile. One change that I would suggest from the way Eclipse does this is that the status should change on-the-fly rather than waiting for the user to a) refresh the project and b) save the file.

Thanks,

Justin

Justin Hopper wrote:

I would like to see the compilation status/code errors/code warnings on all class

So do I, but I don't think it's possible in the near future. Search the tracker, there is
a feature request for "mark errors in project tree / file tabs". You can add some votes to
it :).

Eclipse does this and it makes it nice and clear where compile errors are occuring without having to compile.

Eclipse does compile every time you save. Indeed it compiles incrementally, so this is not
much of an issue, but it DOES a full compile.

On the other hand IDEA just parses the files and tries to figure out the errors (like
CodeGuide does), but since it's not calling the java compiler, you can never be sure that
all errors are detected this way.

I'm not sure, but think that the parsing occurs int this cases:
a/ before refactoring IDEA parses all modified files
b/ on file open IDEA parses only the current file

An option would be to run the parser in a background thread with low priority (like in
Code Guide), but since it's trivial to implement, I guess that the JB guys have tried it
and have a good reason not to add it..

One change that I would suggest from the way Eclipse does this is that the status should
change on-the-fly rather than waiting for the user to
a) refresh the project
b) save the file.

I think I answered this already :) Even Eclipse cannot afford to COMPILE in background.
(Eclipse has really fast GUI, but the Java part is pretty slow. E.g. try "search" in a
large project and measure how much time it would take compared to IDEA.)


regards,
Dimiter

dimiter wrote:

Eclipse does compile every time you save. Indeed it compiles
incrementally, so this is not much of an issue, but it DOES a full compile.

On the other hand IDEA just parses the files and tries to figure out the
errors (like CodeGuide does), but since it's not calling the java
compiler, you can never be sure that all errors are detected this way.

On the plus side, the IDEA parser finds many other subtle problems that
the java compilers don't. True that parsing might not detect some few
corner cases that the compiler does, but it's our job to report these
back to get the parser to full coverage.

Jon

Dimiter,

I'm not sure, but think that the parsing occurs int this cases:
a/ before refactoring IDEA parses all modified files
b/ on file open IDEA parses only the current file

An option would be to run the parser in a background thread with low
priority (like in Code Guide), but since it's trivial to implement, I
guess that the JB guys have tried it and have a good reason not to add it..

What do you think IDEA option "Autoreparse delay" is for?

--
Dmitry Skavish
-

Boston, MA, USA
tel. +1 781 370-6909
http://www.jzox.com
http://www.flashgap.com

"Florian Hehlen" <florian.hehlen@ubsw.com> wrote in message
news:3634008.1050987656941.JavaMail.jrun@is.intellij.net...

This makes me think that sometimes it would be really nice to
be able to close all editors that are not interfaces!

What if the "Editor List" window had columns for type (class, interface),
status (locked/not checked out, unlocked/checked out), last modification,
parser status, etc.? You could sort by column, select multiple files, and
click the "close" button.

It might be easier than trying to do the same thing with tabs...


Erik

What if the "Editor List" window had columns for type
(class, interface),
status (locked/not checked out, unlocked/checked
out), last modification,
parser status, etc.? You could sort by column, select
multiple files, and
click the "close" button.

hi Erik,

what do you mean by "editor list"? Do you mean the Project window?

Florian

"Florian Hehlen" <florian.hehlen@ubsw.com> wrote in message
news:28625282.1051021131268.JavaMail.jrun@is.intellij.net...

What if the "Editor List" window had columns for type
(class, interface),
status (locked/not checked out, unlocked/checked
out), last modification,
parser status, etc.? You could sort by column, select
multiple files, and
click the "close" button.

>

hi Erik,

>

what do you mean by "editor list"? Do you mean the Project window?

There's an "Editor List" menu item in the "View" menu about 3/4ths of the
way down.

I find that view so unfriendly that I never use it.... I remember looking at it a long time ago and just find the fully qualified name list unreadable.... So I guess a more readable version as you suggest would make this feature really good for me.

Florian

"Florian Hehlen" <florian.hehlen@ubsw.com> wrote in message
news:28494744.1051025522748.JavaMail.jrun@is.intellij.net...

I find that view so unfriendly that I never use it....
I remember looking at it a long time ago and just find
the fully qualified name list unreadable.... So I guess
a more readable version as you suggest would make this
feature really good for me.

And if I had a really big monitor, a docked editor list might be a good
replacement for the tabs (as an option of course).

Florian Hehlen wrote:

I know it's a big religious debate as to whether inner clases are truely OO and if they are just plain good design. I know that when I started codeing Java I used to think that inner and anonymous classes should be avoided at all cost... now I find myself using them strategically but still worried every time I use them. I digress!

Wait until you see how inner classes are actually implemented in the
bytecode... You will swear to never use inner classes again ;)

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://java.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: 416-643-4846 | Fax: 416-594-1919

>And if I had a really big monitor, a docked editor list might be a good
>replacement for the tabs (as an option of course).

Maybe smaller tabs would do it? Or a combobox as in CodeGuide?

Tom

Smaller tabs: yes (escpecially on OS X), combobox: no!