Bugzilla – Full Text Bug Listing
| Summary: | [Decorators] CVS and other label decorators Font and Color | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Gary Gregory <ggregory> |
| Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | boris, erich_gamma, Tod_Creasey |
| Version: | 2.0 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Gary Gregory
This may be a dupe (I seem to recall another bug report on the same subject). This should be moved to UI since this is a general decorator issue (we cannot control label color), and the request concerns both CVS and JDT decorators. But before its moved: From the VCM perspective, there is a real issue here that its difficult to spot 'new' files, etc. However, I'm not sure that customized decorators would be the best solution, even if the widgets were to support it, which presently SWT doesn't. For VCM, another solution may be to support filters or queries. Queries could for example be more accessible. One problem with just relying on decorators is that it requires a manual/visual search that doesn't scale for large/numerous projects. Perhaps the reporter can comment on whether they are reporting on the general problem of spotting these items (thus opening the door to other solutions), or whether they really just want to be able to customize the label colors etc. as written. I would like to link this topic with http://bugs.eclipse.org/bugs/show_bug.cgi? id=22921 About: 'new' files I am sorry for not being more precise: I was only considering "new" files in the version control management sense, that is, a file that is not in the repository (yet). In the types pane, a new type is any type that was created in a package since the last "get" of that package. This case is handled right now with a "?" icon decorator and a ">" customizable string prefix. So eclipse currently knows about new files in this sense, I am requesting a feature that lets me customize the display further then having and icon and ">" or no icon and a different string than ">". Further more, if I could set the color and font, I would NOT need the string prefix (unless I was color blind) which I think looks, well, funky. I just think colors works better for my brain for stuff like that. About: Perhaps the reporter can comment... I am interested in my view on the code I am writing giving me better feedback. For example: I do not want to search for all classes that have compile errors (same example for warnings); I already have the very cool Tasks view for that. What I would like is better visual feedback for those errors. If the class names show up in RED, that really says, "hey look at me. Over here!" This is nice when you make a mistake in a class hierarchy and you can see in the Hierarchy tree where what broke and what it could be that you did needs work. For example, I add a method to an abstract superclass (or an interface) and BOOM, all dependent types are "broken". This is a different kind of view than a task list: an unordered laundry list of compile errors to fix (or warnings) in the /whole/ project. In a Types or Hierarchy view, I am focusing on a package, not the whole project. I hope that understood your request for comment properly, if not please let me know. Other random thought: I know that SWT is not Swing, but just to give an example: many Swing widgets allow you to pass in an HTML string as the text content, and sure enough the text is displayed accordingly, which lets you do really nice color and font changes. Thanks you. Thanks Gary. I understood what you meant by "new file" but the added info about your expectations and issues is good. For the other comments, I wanted to distinguish between: 1) you are remarking that its a problem noticing the things of importance and have simply expressed it terms of a particular solution vs. 2) you thought it was important for the user to be able to configure it. I take it from your answer that it was #1. Perhaps the solution is for us to improve the icons, or use queries, or some other thing not yet thought of. If I've misinterpreted your answer, please correct. We may be able to find a solution for #1 without having to have owner-draw trees/lists from SWT. some further discussion on how to support colored items can be found in: http://bugs.eclipse.org/bugs/show_bug.cgi?id=11116. (Kevin, sorry this is a long one, I think it is worth the read of course!) Ah, ok, now I understand your initial query. I think that for the long list of things I would like to be able to do in the long run, overloading icons is not going to work, you can only say so much in 16x16 pixels. Furthermore, I would prefer not to be forced to perform some kind of additional action like a query to get to this information. This would be distracting to me, I may not end up doing it to avoid breaking up my work/flow/thinking process. To me, this info should just "be there", in the view, and this certainly comes from having worked in an IDE that provided this facility. So this is why I have been pushing for fonts and color (or what may end up being SWT user-drawn list and tree node contents, I do not know much about SWT). First from http://bugs.eclipse.org/bugs/show_bug.cgi?id=22921 [Bear with me please :-)] (1) Be able to toggle how "deep" any Types view can be (Especially the Hierarchy view and the Types view). The current 2.0 eclipse is "View types in sub-packages" OFF but the toggle would let you view types in all "sub" packages. [Yes, I know, there is no such things as sub-packages, packages are namespaces, but most folks use packages as a hierarchical organization tools, "Ed"]. So If I have classes in com.me, com.me.a and com.me.b, selecting com.me, displays all the types in com.me.a and com.me.b. (Folks create packages of very different sizes in their apps. This features is very nice not so large packages. If all the packages you are used to work with are giants you may not see the benefit of this. Imagine wanting to see ALL of the "TRAX" classes, you could just click on javax.xml (also imagine that you could do that because you cannot right now!) instead of clicking on each sub-package one at a time and being forced to remember what was in each package.) (2) *Then*, the kicker is that when classes are displayed in a types-kind of view, the types from the selected package are (for example) in bold and others are in the normal font. So if I have "View types in sub-packages" turned ON and I select com.me, I see all types in com.me in bold, com.me.a in normal font and com.me.b in normal font. The bold vs. normal is an example and would be configurable. Now it makes to me sense that I recalled certain bold vs. ~bold view elements. When you are using fonts and colors in clever ways, it then becomes much more feasible to navigate large hierarchies (Java 1.4 has 11,000 classes I've read). Then you can start thinking about using font and colors to distinguish between types in the context where the package or type is selected vs. the other types based on what classpath entry or Jar/Zip file each type comes from... woa. First things first though. (3) Another if... , in a Hierarchy view's members pane I have this great feature "Show All Inherited Members". I would like to emphasize which methods belong to the class I have selected by having these methods in bold. I am looking at one class, in my head (don't go there) I lump the methods into two groups: the methods in the class I am working on and all of the methods that are inherited. But... I have to go a read every single method in the list to see what belongs where. If the methods from my current class context where bold, I could just "see" which methods are "mine". I am sorry this is a long rambler! I could go on and on to talk about trying to make eclipse more like systems I have worked on (Smalltalk/V, Team/V, VisualWorks, PARTS for Java, all products that you may never have heard of perhaps) but I really like eclipse and would like to see it go to the next level. I hope that all of this is a constructive and good argument for have color and font configuration support. From this thread (just to recapitulate in one place with slight changes): (1) Make dirty files blue and bold. (2) Let non-dirty file keep the platform default. (3) Make new files not in the repository yet green and bold. The following does not apply to CVS but to development in general: (4) Make files with compile errors red and bold. (5) Make files with compile warnings dark orange (or a really dark yellow). Let me try to make an analogy and I hope you will be able to relate from past experience. When you think about working in a class hierarchy, you "see" things very differently depending what tools you use. Think about working on code in Notepad, in SlickEdit, in Eclipse and in Smalltalk. Looking at flat files is very different than working with object hierarchies. Programming with Notepad... Talk about not seeing the forest for the trees! Files and directories everywhere, you get the point I am sure. I would like to make the same point the feature possibilities listed above: to allow the programmer to grok more about his code, his team's application's code, the framework code the application lives in, the (Java) platform everything lives in. There is so much! Eclipse already does a great job with the Java Browsing Perspective. I am hoping this will help make eclipse a better IDE. Thank you again, Gary *** Bug 11523 has been marked as a duplicate of this bug. *** There are currently no plans to work on this feature |