This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I am using netbeans to do C++ code. I have spent time setting up colors and fonts. On the first pass I probably got 90% of the settings the way I want them. At this point I will occasionally see a color I do not like while in my editor. Currently I have to spend a lot of time searching through the config menus to try to find that one setting and change it. Often it takes many attempts to find the right one to change. It would make my life a lot easier if I could just right click on the text I want to change and have a selection that says change color/font. If I right clicked on a member function, then it should show me the current member function font and color and let me change it right there. It would not show me any other font/color choices, just the one valid for where I clicked. This would save me a lot of time. This could really help to give a new user a more positive experience with Netbeans. New users typically are the ones messing with these settings early on. It would be good to make this easier for them.
Reassigning to editor.
This is a real problem - especially with highlights and such. I use a color scheme with a black background and there are many highlight colors I cannot find settings for despite the fact that I have been using NB for years :(. Especially problematic are Ant property expansions (not sure why - maybe a bug because it worked in 7.0.1 but has not since). I would be just as happy if the context menu item(s) would launch the Fonts and Colors dialog and select the proper thing. That way I would learn where to find it as well.
This is something on my todo list so I'll share what notes I have on it. It seems to me that this is a good use case for modes. The ability to tweak the appearance of what you see in the normal UI I nicknamed "immediate configuration mode". A mode, as you'll remember, is a special state that's entered into, typically with a key-combination, which results in a change in the functionality for otherwise familiar user interface mouse gestures, widgets or key presses. It's typically used to address the needs of some narrow vertical aspect of the user interface, which despite being a narrow vertical nevertheless makes significant demands in terms of the number of menus and options it requires. One way a mode might be realized for this problem is to have a key combination assigned to "color configuration mode". After that key-combination is pressed, and until it's pressed again to exit the mode, whatsoever user interface bit is moused over and then right clicked on, its color configuration options appear. Changing those options followed by hitting the "apply" button would result in a change in appearance to the item selected, without the options menu disappearing. Whatever ambiguous situations might come up (did you mean THIS or THAT or THAT?) can be addressed by presenting the end user with a chooser menu of options, each one representing a user interface aspect that the user might be asking to tweak given what they're "over". In this way, users would be able to experiment with various options on an ad hoc basis as they're working with code. A couple of drawbacks exist. First, some things are abstract and not selectable by right-clicking on them. In this specific case, given the actual things and options involved , I bet that is something which can be dealt with naturally enough. Secondly, the UI at any given time isn't just naturally going to have all possible tweakable user interface element present. If we can only tweak what we can point at with the mouse, then we're going to be chasing down things through all kinds of classes all over the place just so we can right click on them with and configure their colors. The solution is to have the "immediate UI mode" as an enhancement to what we already have under tools -> options. The issue with just adding it outright to the normal (modeless) right click menu is, that menu is already crowded and right click menus are prime UI real estate. It's hard to make a case that color configuration is more distinguished and deserving of a slot on that menu than many other UI options and we don't know what other, future things may be invented and be better placed there. It appears that people want this with some urgency and it's actually one of the to-do things I have on my (very long) list of tweaks I thought to make to NB UI. I would work on this with any other volunteers who have the time and appetite for a learning curve if I could get answers to questions as they came up from the owners / authors of the effected classes. HTH.
(In reply to comment #3) > This is something on my todo list so I'll share what notes I have on it. > > It seems to me that this is a good use case for modes. The ability to tweak the > appearance of what you see in the normal UI I nicknamed "immediate > configuration mode". > > A mode, as you'll remember, is a special state that's entered into, typically > with a key-combination, which results in a change in the functionality for > otherwise familiar user interface mouse gestures, widgets or key presses. It's > typically used to address the needs of some narrow vertical aspect of the user > interface, which despite being a narrow vertical nevertheless makes significant > demands in terms of the number of menus and options it requires. > > One way a mode might be realized for this problem is to have a key combination > assigned to "color configuration mode". After that key-combination is pressed, > and until it's pressed again to exit the mode, whatsoever user interface bit is > moused over and then right clicked on, its color configuration options appear. > > Changing those options followed by hitting the "apply" button would result in a > change in appearance to the item selected, without the options menu > disappearing. > > Whatever ambiguous situations might come up (did you mean THIS or THAT or > THAT?) can be addressed by presenting the end user with a chooser menu of > options, each one representing a user interface aspect that the user might be > asking to tweak given what they're "over". ... Thank you for your ideas. But this issue is more about changing the colors of syntax elements in the editor.
OK then. I am not sure how your comment relates to mine; I was talking about assigning colors to syntax (and other ) elements. Well anyways, best of luck with the feature add !
(In reply to comment #5) > OK then. I am not sure how your comment relates to mine; I was talking about > assigning colors to syntax (and other ) elements. Well anyways, best of luck > with the feature add ! OK, I misunderstood your comment. I thought you wanted something like a "themebuilder for GUI elements like buttons a.s.o.". That would have been out of scope of this RFE. We both mean the same, that is good.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss
Still valid in 8.2 dev Product Version: NetBeans IDE Dev (Build 201607100002)