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: | Improve Management of Hints, Formatting and Other Settings That May Need to Be Shared Across Groups of Projects | ||
---|---|---|---|
Product: | editor | Reporter: | Petr Somol <psomol> |
Component: | Hints & Annotations | Assignee: | uireviews |
Status: | NEW --- | ||
Severity: | normal | CC: | athompson, hmichel, jlahoda, markiewb, psomol |
Priority: | P2 | ||
Version: | 7.3 | ||
Hardware: | PC | ||
OS: | Windows 7 | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 228495 | ||
Bug Blocks: | |||
Attachments: | License Headers panel in Project Properties + Template Manager dialog |
Description
Petr Somol
2013-01-24 16:47:11 UTC
This seems like a great idea from the perspective of providing flexibility, but my main question is whether or not users will actually use this added flexibility. Is this a corner case? In any case, if we were to implement something like this, I think we would need to make switching between the hint modes VERY simple, i.e. not requiring the user to go into options to switch. Perhaps a selector of some sort in the editor toolbar? Couldn't it be the case that during certain coding tasks the user wants to use global hints and in others project-specific hints? Rich Jan would probably give better founded comment about how frequent the usecase would be, but as I understand it, the list of "sharing categories" would be customized not too frequently. The functionality would probably make most sense in production environment with larger teams, where for a certain project certain settings' change could thus be easily adopted and shared. An example of such situation is what I just observed in JavaFX team - in the autumn they introduced rules about which FindBugs warnings must be fixed in production code for the next release. With a functionality discussed in this issue, if it was available, such a decision would lead to creation of just one settings file that would be referenced from each sub-project; the IDE would thus show exactly those warnings (and none else) to each team member that this particular release cycle aims at fixing. When the team moves to another release or major project, the settings file can be simply adjusted and reused. Generally, sharing among team members is probably an even bigger issue than this. It would make sense to enable centralized maintenance of the IDE in full. So that for a large team there could be just one shareable configuration prepared by the responsible body just once, and then easily shareable and centrally maintainable. Such configuration would also include whatever other information would need to be shared in a team (not only formatting and hints, but also proxy settings, extension list, banned extension list, customized templates, predefined copyright files, etc. etc.). Yes, it seems like we're trying to solve a number of issues here, so perhaps its best if we split up the use cases instead of trying to find a one-size-fits-all solution. Also, another question: is it possible that we could get conflicting logic here if we had two sets of hint logic in use? What I mean is, what if the global hints said "show me this style of hint" and the project-specific one said "do not show me this style of hint". Is there a presumed hierarchy to this that we'd need to enforce? Rich Thanks Petr for writing this up, and sorry for delayed answer. The usecase (for "hints" at least) is that each developer working on a project automatically gets the same environment (more or less), so that he/she can produce code in the same code style as the rest of the team. A variant of this usecase is one developer working on multiple projects with different code styles. I don't think the user is going to switch between project-specific and global often: when a project has per-project settings enabled, these should be used. Regarding hierarchy between the settings, I think we should try to avoid multi-level hierarchies as much as possible, as these tend to over complicate the UI. There are two cases related to settings hierarchies I can see: -if the per-project settings do not contain a particular setting, some kind of default needs to be used. The possibilities I see are: a) use "disabled" (valid for hints, but may not be reasonable some settings) b) use "global default" - i.e. the setting to which the global settings are initialized c) use current global setting - i.e. whatever is currently in the global settings I incline to "b", although I can see some value in the other approaches as well. -the user might want to override a per-project settings only for him- or herself. I don't think this is a strong usecase and I am not convinced it is strong enough for the UI clutter this would cause. So I would propose to skip this usecase for now. In general, I would personally prefer to keep this as simple as possible. I think we should define which settings are shareable and which are not, and allow to independently set logical (predefined) groups of the shareable settings per-project (e.g. formatting, hints). One thing I realized is that it would make sense for the "On Save actions" to be set per-project. See also http://netbeans.org/bugzilla/show_bug.cgi?id=181726 "Make hints configurable per project" FYI: I've set-up a continuous build containing my original per-project-hints experiment here: http://bertram2.netbeans.org:8080/job/prototypes-spi.java.hints/lastSuccessfulBuild/artifact/nbbuild/ Created a related wiki page: http://wiki.netbeans.org/UEXOptionsManagement Note that the new License sharing functionality seems to fit into the scope of this issue as well. See issues Issue #226773 and Issue #226774. I am going to update [UEXOptionsManagement] wiki. @Petr: can you upload screenshots of the license management area as-is in NB now, and how it would change if we were to deal with it in a similar way to hints, formatting, etc? I want to make sure we're being consistent, because it sounds like this could creep into other areas in the future. Thanks! Rich Created attachment 133434 [details] License Headers panel in Project Properties + Template Manager dialog In response to Comment #9 I add a screenshot of current License Headers panel. The attachment also contains another screenshot of what appears when user clicks Edit global licenses. The panel resembles the ones discussed in hints and formatting context, but the logic may currently differ a bit. When Use global license is selected, the combo offers a list of prepared license headers. Use project location allows to store a custom license in a file under project structure, in concert with what we discussed so far. The Template Manager looks fairly confusing to me in this context - I could not find how for instance the Default license can be modified etc. |