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.
Those configuration options that have a checkbox in the properties dialog cannot be used in configuration files. No matter if you check or uncheck the checkbox, its value (checked = true, unchecked = false) overrides the value from the config file. There is no way to tell "use the value from the config file". This issue could be solved by creating two "sections". One that would contain the file input that the other one that would contain all the checkboxes. And there would be two radio buttons (something like "use configuration file" and "use custom options") that would enable the appropriate section and disable the other one. That means that it would be effectively impossible to combine a configuration file and custom options. We don't believe this would be an issue since an advanced user can (and probably will) have an own configuration file anyway and for a "beginner" who learns ApiGen the checkboxes will be perfect. There could also be a short notice below the checkboxes saying something like "for more options you can use a configuration file" and maybe a link to ApiGen.org where is a detailed explanation of all configuration options. If there is a configuration file in the source directory it should be pre-filled in the file input (that works already) and the appropriate radio button should be checked. When there is no config file found, the other radio button should be checked.
And if the user wants to use a configuration file, NetBeans should not ask for the target directory.
Confirmed. Another option could be another checkbox for every existing checkox saying "Enable"/"Disable" - but sounds a bit complicated. Or, if the checkbox could have 3 stages - checked, unchecked and "disabled" (it would mean to use the existing value, from config file). (In reply to comment #1) > And if the user wants to use a configuration file, NetBeans should not ask for > the target directory. So the target directory should be also "behind" radio button. What about the title? Should be always editable or "behind" the radio button as well? Thanks.
(In reply to comment #2) > So the target directory should be also "behind" radio button. What about the > title? Should be always editable or "behind" the radio button as well? And what about the Charsets field?
Please, just reopen this issue and provide requested information. Thanks.
We think that(In reply to comment #3) > (In reply to comment #2) > > So the target directory should be also "behind" radio button. What about the > > title? Should be always editable or "behind" the radio button as well? > > And what about the Charsets field? We think that all fields should be behind the radio button. If you use configuration file you probably set these options there.
One more idea - could you please attach a "full" config file (I mean file with all the options)? I think that we could create a "parser" for it and make then some checkboxes disabled. But it depends on the complexity of the config file (so far there is no Java library for parsing Neon file and is unlikely that any will appear soon). Also, it would be great if you could keep this config file (its format) as much stable as possible (the same applies for command line parameters, of course). What do you think? IMHO it would be the best solution. Thanks.
(In reply to comment #6) > One more idea - could you please attach a "full" config file (I mean file with > all the options)? I think that we could create a "parser" for it and make then > some checkboxes disabled. But it depends on the complexity of the config file > (so far there is no Java library for parsing Neon file and is unlikely that any > will appear soon). Also, it would be great if you could keep this config file > (its format) as much stable as possible (the same applies for command line > parameters, of course). > > What do you think? IMHO it would be the best solution. > > Thanks. Well, the stability of parameters is not an issue, but we are still rather against. As we wrote in the issue description, an experienced user will probably have a fine-tuned config file and an inexperienced one will use just the checkboxes. This is something in between and we would again have to deal with the situation when the checkbox value always overrides the value in the config file (at least there would have to be a "reset settings" button that would re-set the checkboxes to values from the config file). Quite frankly, this feature would look nice but its real added value will be much smaller than the work needed to make it work ;-)
(In reply to comment #7) > Well, the stability of parameters is not an issue Great to hear ;) > an experienced user will > probably have a fine-tuned config file and an inexperienced one will use just > the checkboxes. Nothing would change. > This is something in between and we would again have to deal > with the situation when the checkbox value always overrides the value in the > config file Not true. My idea was that the config file (if set) would have _always_ precedence. It means that the config file would be "merged" with the checkboxes before every run so if user manually adds some parameter to his/her config file, this one would "immediately" completely disable the relevant checkbox (this would be visible in the UI once it is opened). So it would work transparently and automatically and - what is the most important - how user would expect (at least this is my opinion). > (at least there would have to be a "reset settings" button that > would re-set the checkboxes to values from the config file). No, it would not, as explained above. Thanks.
I will do it as I wrote in comment #6. If you have any objections, feel free to provide them. Thanks.
We still believe that mixing config files and checkboxes will be confusing. OK, when you have a config file with some options, the relevant checkboxes get disabled. The problem is that when somebody wants to create their first config, that will probably take the example from ApiGen that is complete. That means that taking this example config disables all the checboxes making them useless for tuning such config file. Moreover the fact that you disable a checbox that has a correspondent option in the config file is an opposite way of how ApiGen works - individual (command line) config options have precedence over those in a config file.
OK, it seems that you have quite strong opinion :) I will do it as you have suggested. (In reply to comment #10) > We still believe that mixing config files and checkboxes will be confusing. OK, > when you have a config file with some options, the relevant checkboxes get > disabled. The problem is that when somebody wants to create their first config, > that will probably take the example from ApiGen that is complete. That means > that taking this example config disables all the checboxes making them useless > for tuning such config file. BTW I still don't see any problem with this. > Moreover the fact that you disable a checbox that > has a correspondent option in the config file is an opposite way of how ApiGen > works - individual (command line) config options have precedence over those in > a config file. Yes, but this will remain the same also with your solution - one selects a config file => _all_ the checkboxes get disabled (no matter what he/she has in your config files). Thanks.
Going to work on this. Please, have a look at my last comment and confirm that the radio buttons are better in your opinion. Thanks.
Fixed. Láďo, please verify. Thanks. http://hg.netbeans.org/web-main/rev/1a046d04f286
Integrated into 'main-golden', will be available in build *201204060400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/1a046d04f286 User: Tomas Mysik <tmysik@netbeans.org> Log: #207240 - Some configuration options get always overridden from the dialog
Functionality as such works, either config file or checkboxes are used. But I'm reopening it because of the Project Properties dialog size (check the screenshot). The dialog is too small (heigth) and because there is the warning msg not even small part of the rest is showed. It took me quite some time to find the invisible settings :)
Created attachment 117945 [details] screenshot this is how it looks with GTK on Ubuntu 11.10, fresh user dir
Properties dialog looks OK to me on XP
Ok, I'll try it on different pc with different version of ubuntu
Created attachment 117952 [details] screenshot metal l&f (In reply to comment #18) > Ok, I'll try it on different pc with different version of ubuntu Reproduced on Ubuntu 11.04 64b with screen resolution 1280*800 and with both L&F, GTK and Metal (slightly better but still "cropped")
I see; I will try to fix.
Fixed. http://hg.netbeans.org/web-main/rev/2a37818160e4
Integrated into 'main-golden', will be available in build *201204110400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/2a37818160e4 User: Tomas Mysik <tmysik@netbeans.org> Log: #207240 cont'd - Some configuration options get always overridden from the dialog
thanks, verified Product Version: NetBeans IDE Dev (Build 201204110400) Java: 1.6.0_31; Java HotSpot(TM) Client VM 20.6-b01 System: Linux version 3.0.0-17-generic-pae running on i386; UTF-8; en_US (nb)
Integrated into 'main-golden', will be available in build *201204120400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/2a37818160e4 User: Tomas Mysik <tmysik@netbeans.org> Log: #207240 cont'd - Some configuration options get always overridden from the dialog