Community
Participate
Working Groups
This feature request does not address the ordering/grouping of the font/color preferences, although they are in great need of help too. Fonts: The two problems with fonts preferences are a. Too much button clicking to do what should be a simple task (the ui is unnatural) b. No way to easily see what the current setting is Request: Remove the "Use System Font" and "Change" buttons, replace with: (here's to hoping ascii art works... monospace font) (x) System Font (Current Font Face, Current Font Size) ( ) Custom Font: +--------------------+---+ +--------------------+---+ | Font Face Dropdown | v | | Font Size Dropdown | v | +--------------------+---+ +--------------------+---+ +-------+ | Reset | +-------+ This will allow a user to both see what the setting is, and to change it righ t on the preference page
It might be also nice to manually configure "inheritance", i.e. defining something like "use window/frame/whatever system color" or "use same as text editor". Currently this can only be defined at plug-in development time but not manually at runtime.
Susan is now responsible for watching the [Themes] category.
Created attachment 213426 [details] ugly huge font or huge gray gaps Looking at the current implementation in 4.2M6 (I20120315-1300) - The dialog lacks hints, that it's not the only place to define colors. As a start there should be links to General>Editors>TextEditors>Annotations and Java>Editor>SyntaxColoring. In the long run it might be worthwhile, to define all colors in this central place and let those other "color customers" reference this central. - A color pipette would be nice, to select any pixel in the main window and setting the selection to the appropriate color. As an easy implementation, you could read the color code of the screenbuffer at the clicked position (like so many other color pickers do) and traverse the tree top to bottom until you find a perfect match. If no color matched perfectly (possibly due to antialiasing and tranparency blending), choose the closest one. The ultimate solution would be support in every gui-component, to be queried which color-constant contributed to a certain pixel. Containers would recursively ask their members until one answers: Hey this is part of a glyph I painted in Color.SyntaxHighlight.Keyword. - The color-preview is nice. But it could be slightly more intelligent: Selecting a background color, there is no point showing me, how this color would look as a text color. This gives the false impression, I should make it darker, so a text in this color could be read on a gray background. This won't ever happen other than in the preview. Thinking about it, I guess, colors should be labeled as either a foreground or a background color. (I'd consider it poor design, if a color is used for both). Then you can build a graph which foreground-color may ever be placed on which background-color. The preview would simply traverse the neighbors in this graph and display an example text of the selected foreground on rectangles of all attached backgrounds. Likewise it would display a solid selected background and print example texts of all possible foregrounds on top. In addition a click on a foreground background combination could toggle the selection in the tree between the foreground and the background, easily allowing to navigate the graph. - Watch out for the minimum bounds of the color/font-selection-tree. While playing around with selecting items, dragging the dialog in size, filtering and folding the tree, I sometimes cannot shrink the preference page back to normal. Instead scrollbars around the whole thing kick in and move the Apply button out of view. Sadly I havn't found a sequence to reproduce this. After cancel and reopen, the dialog is back to normal. - There is a textual description field for the current selection in the tree above. But it lacks a scrollbar, should the text exceed the three lines given. - You never know whether apply will be sufficient, or if you have to restart Eclipse to see the changes everywhere. It seems to be a long standing bug 19346 comment 23. - The "Part title font" is defunct or badly interferes with General>Appearance>Theme. This will either create ugly huge letters, or huge noticeable gray gaps over the tabs (see composed screenshot). In addition, the preview inside the dialog doesn't know about the theme. Keep up the good work
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
