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.
There are already quite a few options categories related to HTML and JS development technologies in NetBeans. * Miscellaneous / Node.js * Miscellaneous / CSS Preprocessors * Miscellaneous / Mobile Platforms * Java / JavaScript And more categories may be coming. HTML and JS development options would deserve a new top-level options category, next to Java, PHP, C/C++. On the other hand the top level Appearance could be finally merged into General category. Opinions?
A new "HTML/JS" category seems fine. Although I don't think 'Mobile Platforms' really fit there. Merging General and Appearance categories is also a good idea. But how shall we call the current 'General' tab in the new layout?
(In reply to Stanislav Aubrecht from comment #1) > Although I don't think 'Mobile > Platforms' really fit there. +1
(In reply to Stanislav Aubrecht from comment #1) > Merging General and Appearance categories is also a good idea. But how shall > we call the current 'General' tab in the new layout? One possibility could be to name the existing tab as 'Genaral'. The new merged category would have 'General', 'Document Tabs', 'Windows' and 'Look and Feel' tabs. Finding some new name for the new merged category might not be trivial though.
(In reply to Stanislav Aubrecht from comment #1) > A new "HTML/JS" category seems fine. Although I don't think 'Mobile > Platforms' really fit there. I tend to agree but if we are thinking about Cordova, HTML/JS is what Cordova is all about.
(In reply to Vladimir Riha from comment #4) > I tend to agree but if we are thinking about Cordova, HTML/JS is what > Cordova is all about. So, perhaps "Cordova Platforms" instead of - too general - "Mobile Platforms"? It would be perhaps better since we don't support any other Android/iOS development than Cordova, right? What do you think?
I think it is named so general because path to Android SDK is used also when running plain HTML5 project in mobile browser, which is not related to Cordova. So naming it Cordova could be a bit confusing but one the other hand would help to promote Cordova support. I'm not sure, personally I would probably keep it Mobile Platforms (or simply Mobile?).
(In reply to Vladimir Riha from comment #6) > I think it is named so general because path to Android SDK is used also when > running plain HTML5 project in mobile browser, which is not related to > Cordova. So naming it Cordova could be a bit confusing but one the other > hand would help to promote Cordova support. Did not know that, sorry.
(In reply to Antonin Nebuzelsky from comment #0) > * Miscellaneous / CSS Preprocessors I just found out that CSS Preprocessors are part of the "ide" cluster but HTML/JS category makes sense to me to be in web.clientproject[.api] module (which one is better? Anyway, both modules are in "webcommon" cluster). Any ideas how to solve this? Or should we register this category in web.common module which is part of the "ide" cluster as well? But then, the "HTML/JS" category would be present in IDE Options always, right (with only CSS Preprocessors for e.g. Java builds)? Thanks.
(In reply to Tomas Mysik from comment
something went wrong while posting sorry (In reply to Tomas Mysik from comment #8) > (In reply to Antonin Nebuzelsky from comment #0) > > * Miscellaneous / CSS Preprocessors > > I just found out that CSS Preprocessors are part of the "ide" cluster but > HTML/JS category makes sense to me to be in web.clientproject[.api] module > (which one is better? Anyway, both modules are in "webcommon" cluster). Any > ideas how to solve this? Or should we register this category in web.common > module which is part of the "ide" cluster as well? But then, the "HTML/JS" > category would be present in IDE Options always, right (with only CSS > Preprocessors for e.g. Java builds)? > > Thanks. Maybe css.prep should not be regular, I guess eager is more appropriate or even autoload as web.common is. If HTML/JS category is registered in web.common then it will only be visible in options dialog when/if web.common gets activated, which is the expected behavior, right? I am not sure when css.prep should be activated though. I mean should it be activated for java builds? I guess it should be active when webcommon cluster gets activated. Or perhaps I did not understand the question?
Should be done now. BTW I have renamed Java/JavaScript to Nashorn. Thanks. http://hg.netbeans.org/web-main/rev/cef70ac7f5a9
Integrated into 'main-silver', will be available in build *201411290001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/cef70ac7f5a9 User: Tomas Mysik <tmysik@netbeans.org> Log: #247778 - Top level HTML/JS category in Options dialog