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.
Summary: | Some configuration options get always overridden from the dialog | ||
---|---|---|---|
Product: | php | Reporter: | andrewsville |
Component: | ApiGen | Assignee: | Tomas Mysik <tmysik> |
Status: | VERIFIED FIXED | ||
Severity: | normal | CC: | jeff_rubinoff, vriha |
Priority: | P3 | ||
Version: | 7.2 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
screenshot
screenshot metal l&f |
Description
andrewsville
2012-01-12 20:50:13 UTC
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. 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 |