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.
NB: 200807300201 OS: Ubuntu 8.04 JDK: 1.6.0_10 I run NetBeans on Ubuntu with default GTK look and feel... 1. Start NB with a fresh userdir 2. Go to Tools>Options>Editor 3. Go through tabs from Formating to Tasklist Language settings are as follows: -> Formatting - Language: All Languages, language combobox is gray -> Code Templates - Language: Java, language combobox is white (!!!) -> Hints - Language: PHP, language combobox is gray -> remaining tabs - Language: Java, language combobox is gray Tab Hints always contains "PHP" now - even when I was editing a Ruby file. I also think it would be nice to unify appearance - why is the combobox in Code Templates tab different? Maybe I will have just a small question, that might be valid for some future release (NB10) - why the language combobox is not global in the editors settings? I assume it is because individual languages can "register" to separate "tabs"(?)... But then this can be done much better: if you think "upside down" then you are avoiding a lot of troubles (this does not hold in general, indeed). For example: I am editing a Ruby file. If I go to Mark Occurences, Java is selected in Language combobox as Ruby is not there - and as I am new to netbeans, I am confused... I have also seen some bug with plain PHP distro and the empty combobox... Now, what do I mean by "upside down": 1. There would be global language combobox in the top of the dialog, so that it is nicely visible (now the combobox is not very visible). 2. When user chooses some language, only those tabs the language is registered to will be shown. (For example I would not see tab "Mark Occurrences" when Ruby is selected in the language combobox)
Created attachment 66035 [details] NetBeans 10 options dialog?
Ondro, what do you think? Marking as ENHANCEMENT for now.
Sounds good to me, definitely better than what we have now.
Not an easy problem. The language combo is not above the tabs for the reason that for quite many of our users, it lacks any relevance and kind of breaks the flow. If someone is editing Ruby file and goes to Editor/Formatting, s/he certainly wants to edit these for Ruby, not for Java. I would say the main problem is default behavior. If you wouldn't have to change it, you wouldn't mind missing this combobox ;). By thinking "upside down" as you suggest, we would think of upside down in terms of implementation, but we would still expose backend and break users's flow .. I imagine it something like: "geez .. how does this formatting look .. wait .. i need to change this .. where's that .. <menu tools> .. <options> .. it's gonna be editor, right .. wait .. language? I'm coding ruby .. why's java here? I see .. i need to select Ruby here .. so .. where was I, why did I come here .. i see .. i wanted to change indentation, so it's probably gonna be this formatting tab... " Sure, the combo is there, so the flow is broken anyway, just somewhat later, at the moment user found the particular tab s/he was looking for. Let alone users who are using Ruby/PHP distro .. they would find a very prominent combo offering only one choice .. their language. Sure, it would be probably easy to hide in those specific distributions. My question here also is .. if the language combo was above the tabs, wouldn't it be more difficult to maintain consistency among formatting settings for different languages? I'm not saying either approach is good or bad, I just think we should first fix the default behavior and see if the problem persists. I personally think it won't ...
I understand this, but lets talk about this a little. > .. wait .. language? I'm coding ruby .. why's java here? No, the item in the language combobox would be selected correctly using exactly the same mechanisms as it is using now - language of the opened and active file would be selected. It is difficult to capture it in the screenshot;)... I imagine it like this (admitting I am not an expert): "geez .. how does this formatting look .. wait .. i need to change this .. where's that .. <menu tools> .. <options> .. it's gonna be editor, right .. "Selected language" is Ruby .. Yeah - that is correct, I am editing ruby, NetBeans is pretty smart and guessed it right .. Cool... The way better than Eclipse..." If the combobox does not have much importance, you can easily place it somewhere in the bottom or - as you said - hide it if only one language is present (you need it anyway if you have 2 or more languages, you might want to change some settings for Java even if you are editing ruby...). It shouldn't be so difficult to find how many items are in the combobox to determine if it should be displayed or not... :) My personal opinion: I always felt the importance of this combobox is rather high. User should at least see that he/she is editing the right settings, so I believe that it should be present even if there is only one language (I suppose that user is intelligent and knows that he/she can extend IDE to support more languages)... > I'm not saying either approach is good or bad, I just think we should first fix the default behavior and see if the > problem persists. I personally think it won't ... Currently, one of the problems is that if you edit ruby, you see i.e. the "mark occurrences" tab with options that are useless to you (...which you need to find out first: "OK, there are some settings, but as I use a plain Ruby distro, they are not for me... they are for noone... Pity..."). You can say that it is possible to can hide this tab in that case - and here we are - then the only difference to what I suggested above is that you need to handle more comboboxes (each present panel = language combobox) instead of one... > My question here also is .. if the language combo was above the tabs, wouldn't it be more difficult to maintain > consistency among formatting settings for different languages? I have to admit that I am still a way-too-junior/lame/actually-quite-bad programmer, but I don't see how that could be a big problem. You would write "globalCombobox" instead of "inPanelCombobox" when asking for the language (??? or not???)... I also believe that a usecase bellow is quite rare ==> you do not need to have Language combobox in each tab: User sets some settings ("Formating") for one language and some totally different settings ("Code Templates") for another language
> Currently, one of the problems is that if you edit ruby, you see i.e. the "mark occurrences" tab with options that are > useless to you (...which you need to find out first: "OK, there are some settings, but as I use a plain Ruby distro, > they are not for me... they are for noone... Pity..."). That's a problem, for sure. But .. again, location of the combo will not fix this (unless we just omit the tab if settings are not available for the particular language, but that brings highly dynamic UI as each language would have different tabs underneath it). That's the consistency issue I was talking about. It would also bring in some issues .. What would happen if you have Java selected, choose "Mark Occurrences" and then switch to Ruby? (there is no mark occurrences setting in ruby). Also, since in Templates, all MIME-types are present as languages, there would be huge number of languages in the common combo-box, making it more difficult to find each language. In short, both approaches have their pros & cons. The proper solution would probably guess the language user wants to edit settings for and if no settings are available, display the panel for that language with only language combo box and error message saying "These settings do not apply to the language you are editing. Please choose a different language.". Again, things are different for single-language distros .. i tend to say that for Ruby distro, all non-ruby related panels should be hidden, but I'm not sure about how demanding it would be to implement. Since the change you're suggesting is probably too big to be done for 6.5, let's fix the behavior for 6.5 and see if there is a need to move the combo above with the next release. Following parts of this issue can IMO be considered DEFECT: 1) If I'm editing in one language and go to options/editor and switch tabs, I browse through settings for different languages. 2) Different appearance of the language combos.
1) If I'm editing in one language and go to options/editor and switch tabs, I browse through settings for different languages. - fixed in trunk: c809ca5d3a6c 2) Different appearance of the language combos. - is caused by L&F not fixable on our side.
> 2) Different appearance of the language combos. > - is caused by L&F not fixable on our side. I don't really understand this - you cannot make this to display the same combobox???? But... OK... I am reopening this issue as an ENHANCEMENT for the global language combobox. (See issue activity for details.)