Community
Participate
Working Groups
Currently if you open a class that is visible via a JAR on the classpath, along with its source, Eclipse will show you the source in the editor. The editor even allows your to place the insertion-pointer in the text, but prevents you from editing the code. The only clue you have that the editor is open on a .class file (before trying to edit the code) is that the .class extention in the editor's tab. I'd like to see a more verbose visual-clue that the class open in the editor is read- only. For example, changing the editor's background color.
The editor tab also shows the "binary" icon instead of the "Java" one, and there is a status item informing you that the file is "Read Only".
Agreed, the icon does change, but it's not exactly obvious to the casual observer. I don't see the status item (but I'm running 2.0.2 at the moment, sorry). I would like to see something as verbose as changing the background color of the editor, so there's absolutely no mistaking it as read-only. The reason I hit this case is that when I search the workspace, hits are found in .class files. In my workspace I have a rather special case where I have the source in one project, and the .class files on the class path for another project (and I want it that way). So of course I get double the hits, half of which are in the .class files, which I end up trying to edit!
Hi, the read-only message displayed in 3.0-M4 is very annoying. If you simply type one more key (or ctrl+space, see bug 27959) you completly loose the editor. To restore it you have to close and reopen. I think a "beep" could be enough or maybe change the editor titlebar color.
I must agree, the binary icon doesn't cry out that the file isn't editable. Perhaps a decorator on the icon denoting that it is locked is a step in the right direction?
What's mentioned in comment #3 has been fixed (was bug 42230).
*** This bug has been marked as a duplicate of 10464 ***
I have to re-open this one because I've just spent a good couple of hours trying to debug a problem that was caused by a binary version of a resource being used instead of a local resource. I really think that files that are opened in the workspace, but are based on a binary read-only file should be visually obvious. And I mean really obvious, such as having a different color background. Of course this is not just a JDT problem; in fact the problem I was having today was related to a feature.xml.
Looks to me like your problem is different because it really is of no relevance in your case (unless you manually set the binary files to read-only) whether the files are read-only. Note that files in binary projects - like the feature.xml that caused you trouble - are not marked as read-only by PDE i.e. in the normal setup even with the best read-only indication in the world you would have not realized it ;-) I would reather like to understand why you spent 2 hours to figure this out and why a feature.xml caused this. Pleae provide more details.
The problem was not figuring out that the file was read-only, but rather that a read-only file was being selected as part of my PDE build, and being used instead of my local copy. I'll admit that my case was a rather obscure one, but that's the sort of problem you need good visual clues. It's when you make assumptions that you fall into a trap. The problem manifested itself in a build failure, the source files of which, on visual inspection, seemed to be fine. The only clue I had that my root feature was referring to a binary dependent feature.xml in my target was the fact that when I opened it I could not synch with the Package Explorer, which was curious since I knew I had that feature.xml locally. The point here is that when I open a file in Eclipse it would help to know that it's coming from my local workspace rather than from somewhere on the classpath or runtime target. Today the clues are there but you have to look carefully. For example, when opening a binary feature.xml or a class file (with source attached), you can give the text editor focus, but it's only when you start trying to type (and find that you can't) is it obvious that the file is not local. My goal here is to leave this issue open for considering, so RESOLVED/REMIND is fine for now.
So, maybe also use the binary project decorator on files that come from a binary plug-in?
Get rid of deprecated state.
.
