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.
Changing "Target Platform" changes: - bootclasspath list contents - the selected compiler (if the user did not choose a specific one, so there's default) - capabilies of the compiler I: UI unsuitable for the target platform should be eliminated - capabilities of the compiler II: if the compiler impl changes, UI should follow the platform default compiler's impl capabilities For the above reasons, having platform selector on a tab after compiler and compiler option tabs seems as an error.
The UI concepts should be flexible enough to work well even for C++ compilers, which tend to be much more customizable than Java. In other words, the concept should be strong enough that Java solution is consistent and forward compatible w/ C++ modules in extended editions. For an example what are the common gcc compiler options, see the attachment. Only subset of them should be present in the creation wizard, though.
Created attachment 8194 [details] List of gcc compiler options
Updating to the latest UIspec state (12/03): The platform seems OK for java - how does that play w/ infrastructure spec for project customizer ?
why does the Java solution need to be extensible to for c++? the inf. should be exetensible but then branches for c/c++ and Java and whatever else. i find this requirement worrying.
I did not say that Java should support C++ options, but they way how Java plugs in UI for a particular Javac implementation should be consistent with the way how C++ will plug in UI for a particular C++ compiler implementation. After all, they will BOTH appear in an JNI (Java + native methods) project, so it would be confusing to have two pieces of UI, both compilers, but each of them behaving differently or using different technique to integrate extensions. BTW How will the UI for the project's Customize appear if the project is a mixed one - using Java with some pieces of C++ code to implement native methods ? Java projects UI cannot be constrained to work only in "pure java projects", otherwise the IDE will fail to be extended by Forte Enterprise or partner modules.
i would expect that for mixed development the customizer may need to be broken into the various customizers (the customize pull right in the context menu). adding everything as tabs is a possibility but that would probably be overwhelming. it really depends on how the mix is constructed. from my point of view it would be best if the project types to do mixed development would specify how their customizers will be constructed. the contents can come straight from java and c++ (say) but the order in or number of customizers is defined by the jni or corba project.
I started to track this issue as a candidate for usability fix in my personal release of NetBeans. I am tired by endless discussion that need audience experienced with tools and their varieties; they waste too much of my time that I need for development. * This issue was marked as a candidate for `NetBeans for Developers' relelase *
i certainly don't want to waste your time but i still do not see what the usability problem is. i understand your concern that things need to be consistent (it's a page out of my own gospel) but i think you're worrying about something needlessly. the design, as it stands for java, seems pretty good. c++ will introduce more options but i see no reason it won't fit within the current design. when you get back from vacation we can chat face to face -it's faster and we have a good track record of solutions that way.
See the URL for reference what is wrong. I do not think that I worry needlessly, since other IDE vendors seem to be worried, too. Anyway I am not willing to spend more time on this issue for official 4.0 release correcting UI problems.
This issue is not for NB 4.0 projects, but rather for NetBeans for Developers. Please do not assign it away from me. Note that Milestone is TBD and no Projects keyword is there.
Does not seem to be applicable anymore.
Reorganization of java component