Created attachment 130446 [details]
Interface icon in Projects view mockup

Just to make sure I understand right what this issue is about - does the attached mockup show the interface icon in Projects view as you ask for ?

Created attachment 130448 [details]
Interface icon for Projects view

Tomas, in case you find this useful I am attaching the new icon as ready-to-use file.

(In reply to comment #1)
> Just to make sure I understand right what this issue is about - does the
> attached mockup show the interface icon in Projects view as you ask for ?

That is perfect! And I like the new icon. :)

*** Bug 225455 has been marked as a duplicate of this bug. ***

Just remarking that Issue #99854 and #225455 that are effectively duplicates of this one altogether proposed to distinguish not just interfaces from classes, but all of the following: different icons for class, abstract class, enum, interface.
I'll supply the other icons as well..

It could be useful to distinguish annotations too. In fact the best would be to have a different icon for every recognized file type but I would definitely give the priority to java stuff of course.

Created attachment 130883 [details]
new icons denoting various java file types in Projects view - mockup

I am attaching a mockup with all the new icons as suggested, to distinguish: class, abstract class, interface, enum, annotation. I am going to attach the ready-to-use individual icons zipped together.

(In reply to comment #7)
> I am attaching a mockup with all the new icons as suggested, to distinguish:
> class, abstract class, interface, enum, annotation. I am going to attach the
> ready-to-use individual icons zipped together.

Brilliant! :D

Created attachment 130884 [details]
new individual file icons (abstract class, interface, enum, annotation) zipped

I like the mockup icons (a lot) but they are too close to be visually helping. I mean: most of the time I browse there very quickly and if I need time to distinguish between them closely there is much less value in it. In particular enum is too close to class. It may be because I use a 1950x1080 17" display of course. Could it be possible to add some (maybe background) color to better differentiate between them?

(In reply to comment #10)
> I like the mockup icons (a lot) but they are too close to be visually helping.
> I mean: most of the time I browse there very quickly and if I need time to
> distinguish between them closely there is much less value in it. In particular
> enum is too close to class. It may be because I use a 1950x1080 17" display of
> course. Could it be possible to add some (maybe background) color to better
> differentiate between them?

I understand well what you mean but I have good reason why I do not make them radically different among each other - that is the styling rule, that we must first of all keep these visually close enough so as to: 1) suggest they have close meaning, 2) distinguish them as a group clearly from the other icons in Project view, more distant in meaning, like packages, project types etc. This is all quite difficult to fine-tune, but generally we need to avoid having too many icons differing too much from each other, as they would paradoxically require more concentration to recognize what they are about.

That said, I do not abandon this question entirely, but I let the rest of NB UI team to review this as well.

Created attachment 130886 [details]
file icons on Eclipse

I hate to bring this up ;) but as you can see Eclipse does a very good job at differentiating the icons and I think this adds a lot! I understand the style problem but as a programmer I would never trade beauty over practicality on my tools! And of course the two could combine.

I go so far as to suggest the use of the same (background) color pattern as eclipse to help people that have to work with both (or maybe want to move from one the the other).

I think that having papersheet-like border around each (Java) icon isn't helping anything. If we drop it there will be more room to make the icons more distinguishable.

Agreed with Stanislav.  These need to be very visually distinctive to have value.

Rich

(In reply to comment #14)
> I think that having papersheet-like border around each (Java) icon isn't
> helping anything. If we drop it there will be more room to make the icons more
> distinguishable.

OK I'll try to come up with alternative, more shouting designs, yet I would be cautious regarding abandoning the paper sheet altogether. Of course we might do that, but we must then give a thought to the overall conventions over the whole NB. As far as I understand it now, in all types of projects the paper sheet is the unifying icon style, marking generally a (any) document. It is not used in 100% of cases (see e.g. css files) but for practically all key project files there is a paper sheet style icon (at least in Java, C++, PHP).

The use of images in icons follows also one more convention (though again not always) - note that the symbol for class as seen in Navigator for Java projects, is exactly the one in java file icon (drawn over the paper sheet). My first proposal followed all these conventions - to keep the sheet symbol for document, and to keep particular symbols for particular entities on their file icons.

I am going to provide an alternative file icons proposal that would try to shift the trade-off between convention preservation and distinctivness towards the latter ASAP..

Just brainstorming here - but what about file-like badge instead of file-like frame?

I would really not care too much about the file-frame. The positioning in the project tree is good enough to visually understand the difference between projects, folders and file-leaves. To be able to recognize a file type at a glance is the real objective here IMO.

(In reply to comment #16)
> OK I'll try to come up with alternative, more shouting designs, yet I would be
> cautious regarding abandoning the paper sheet altogether. Of course we might do
> that, but we must then give a thought to the overall conventions over the whole
> NB. As far as I understand it now, in all types of projects the paper sheet is
> the unifying icon style, marking generally a (any) document. It is not used in
> 100% of cases (see e.g. css files) but for practically all key project files
> there is a paper sheet style icon (at least in Java, C++, PHP).

I agree with Petr, even rarely used file types follow this the paper sheet
convention so it would mean huge IDE-wide redesign and I don't think we would
like to change that.

About the Petr's proposal, I can see only one problem - Class vs Enum. These
two icons can be hard to distinguish. But the others seems fine to me. So it
would be better to redesign sign for Enum files. 

About the Eclipse - if you take a look on it you will find out that these
different icons are used only in "New" wizard. In the the project view every
java file has the same icon (at least in version I've tried).

And as my last note - I'm not sure if this is technically easy to do (or even
doable - all these files are .java). I think it would be good to ask someone
from Java team before we will put a greater effort into it.

I've tried Eclipse and the project view has just a file with J. There are no different icons for Class, Interface under the package, they are under the file and collapsed. There are performance reason why it's so, finding out if a file contains class or interface needs either parsing or class index query which may become performance problem for big packages.

It's questionable what to display for compilation unit like this:

package foo;

class FooC {

}

interface FooI {
	
}

Created attachment 131011 [details]
eclipse Juno java icons

In Eclipse Juno the icons are not shown in the first file node but can be viewed if it is expanded (which I don't like). This way you can solve the problem about having defined other objects in the same file. It's reasonable of course but I would notice that this is in fact a very rare case (at least to my knowledge) and this kind of visualization (sub-trees) it's not visually useful as it implies the action of expanding the node which void the usefulness as a first-glance identification.

My proposal is to use a double standard:
If there is only one object than use the appropriate icon;
If there are many use an expanding node (or a neutral icon, or the icon relative to the same-name object which seems more natural)

As a rule I would optimize towards the most used and useful cases leaving corner cases to a more convoluted/ suboptimal solution.

The reason why the Eclipse does not show the icons directly is a performance. The user needs to click the "J" node to expand it to see the class or interface icon. For large packages with hundreds or thousands files there is no special overhead when the package is expanded.

I thought that much but class type is something that doesn't change that much during development (so cache maybe?) and NB has to parse the classes anyway for methods linking (I guess).

And here is the bomb: what about having a grey icon (or something) for non public objects? That way it would be really EASY to discover the public interface of a package (API) by reading public interfaces / classes! That would be GREAT!

No question about performances of course. This is just a suggestion (ideas are what move us after all). Do what can you do and thanks for making that great IDE!

The change of class <->interface is not a big problem. The IDE already has an index holding this information, however even the query may cause slow IO operation (when the index is used first time or was freed from LRU) but it's not a big problem (loading single index is quite fast). The problem is that the information is not available when the project is opened for the first time until the project is scanned (indexed), to solve this problem some additional icon displayed in this time is needed ("unknown"). Instead of the special icon simple class icon can be used but it may be problematic for an user to find it out that the class icon has two different reasons.

Well having to wait some time at the first opening doesn't seem too bad to me, and the two icons approach is not that bad either (on the contrary). People are used to that when opening a folder full of images while the thumbnails are calculated. Opening the JDK as a project (src) takes some minutes anyway. And this is only for the first time. For me the advantages are enormous: I would not have to search for public interfaces (between tens anonymous files) or forced to use naming conventions like IBrowsable or EColor anymore. That's huge!

At any rate it's true that nobody likes slow IDEs. My machine is equipped very well (8G RAM and fast CPU) and I definitely would not care to wait some time for opening a big project, but you can always put the most time consuming features as an activable options or maybe detect if some operation is taking too much time and ask for it to continue (as some browsers do with js).

OK so to recap - in addition to icons for class, abstract class, interface, enum and annotation we also need an icon for "unspecified java" and "mixed java entities". And, for each of the above it would be good to have a "public" version and a "non-public" version..

The "mixed java entities" is probably not needed. As fillumina has written the one type of the file can be used. Similar thing I am doing in Show Members (Hierarchy) if more types are in a compilation unit I am using the one having the same name as the file, if there is no such a type I am using the first one.

Created attachment 133880 [details]
Shows the mismatch of icons - for example interface

When you fix this issue, please don't forget to update the icons for the "New File..."-wizard. The icon usage should be consistent. Currently there is already a mismatch (see screenshot), which could be solved in one go.

*** Bug 145156 has been marked as a duplicate of this bug. ***

I was just perusing my list of bugs and enhancements, and I came across this one again. :) So I am just curious... Any idea whether this will be implemented at some point?

I was kind of hoping it would be part of 7.4 release. I also hate comparing to other IDEs, but the IntelliJ IDEA has really good looking and crisp tree icons which makes distinguishability between different types of java files even easier. Personally I will need to squint a bit if the suggested icons are used as attached.

Created attachment 145636 [details]
Eclipse file icons

@Jan Peska: Eclipse really does have different icons (technically, icon overlays) for them on the file. Screenshot from my version of Eclipse, and it used to be this way for as long as I can remember (that's at least from Eclipse 3.1.1 till Eclipse Ganymede)

I really want this functionality too, but in 7.3.x, because we can't use 7.4 (the company PCs can't have Java 7 installed for unrelated reasons)

Fixed jet-main ca45fce27bce.
Fixed with icons attached in this issue by Petr S. However I personally think that the icons are not very descriptive. Unfortunately the A11Y and I18N limitations disallow simple colour and letter difference.

Integrated into 'main-silver', will be available in build *201407170001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/ca45fce27bce
User: Tomas Zezula <tzezula@netbeans.org>
Log: #225049:Different icons for classes and interfaces (and possibly abstract classes, enums and annotations)

See the follow-up issue https://netbeans.org/bugzilla/show_bug.cgi?id=245824