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: | Implement "bridge" modules | ||
---|---|---|---|
Product: | platform | Reporter: | honglin <honglin> |
Component: | Module System | Assignee: | Jesse Glick <jglick> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | lkramolis, mmatula, rkubacki |
Priority: | P2 | ||
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 17773, 18781 |
Description
honglin
2001-11-10 00:23:52 UTC
Makes some sense although the question is open-ended which modules you should remind the user about. If there are modules the user truly does not care about, it will be annoying to have constant reminders about them. There was a proposal recently on nbdev (Martin Matula, Fri.) to have some modules be "greedily enabled" (his scenario #1) whenever they can be. I think there is some merit to it--though I doubt the situation you describe here fits into it exactly. The editor support bridge module, definitely; but it ought not be used for any module providing substantial additional functionality, only for "bridges" which tie together basic functionality of already enabled modules. For the "Forte Developer ..." module in your case, it seems dangerous to have it be automatically reenabled. You can however place it in the same display category as the base CPP module, making it quite visible to users that it is available for reenablement. Will not be changed for NB 3.3, will consider for 3.4. More descriptive summary. Started in branch module_deps_jan_2002. Seems to be working well enough in that branch. Need to clean up the build system to understand modules/eager/ directory, otherwise looks OK. Behavior and UI is as follows: 1. If a module is found in the modules/eager/ directory, it is considered "eager". Compare modules/autoload/. This information is stored in the module XML file: <param name="eager">true</param> 1a. Modules which used to be normal modules which are now made to be eager can be upgraded from old user directories in such a way that the old module information is now marked as being eager. 2. No action, from the GUI or code, may explicitly enable or disable it, nor is its enablement state persisted. The module system controls the enablement state internally. Similarly to autoload modules. 3. When some regular modules are turned on, and some eager modules then can be turned on, they are automatically turned on. 4. Disabling a regular module will disable any eager modules dependent on it, without prompting the user, i.e. it is quiet. 5. When the Modules node is sorted by category (default), all eager modules appear in a special subnode "Bridges", immediately before "Libraries". They have an "Enabled" property but it is read-only. Should be reasonably straightforward. I plan to make some standard NB modules eager: - apisupport+ant - i18n+form - *+editor (various syntax coloring helper modules) Marking as an IFDEF-relevant issue. API impact: none, should be considered core feature not officially guaranteed by APIs. It is enabled only by placement of the module in a certain folder and does not require any modifications of the module JAR. Jesse, it is great, you implemented this. I have little enhancement. I think, it is not good to avoid user to disable some module. I would like to suggest to still have possibility to enable eager module. Table displays UI of suggested behaviour: Enabled property || of eager module || Module enabled | Module disabled =================++======================+===================== Enabled property || User has chance to | User has chance to is read-write || disable eager module.| enable eager module. -----------------++----------------------+--------------------- Enabled property || imposible | Dependencies failed. is read-only || state | (When dependencies will be | fulfilled, then module | return to previous state. I think, if such behaviour implemented, then each module could be classified as eager module. Sorry, I don't think I understand your table. The reason I decided to omit any GUI for disabling an eager module is that it rather simplifies things internally. Otherwise you have to decide how long it is supposed to stay disabled if some other things change. It can get very complicated. The implemented solution is relatively simple (= testable). So I don't think what you suggest is a "little enhancement" at all, it is a quite different system, probably dealing mostly with UI code in the Modules node rather than with the module installer itself. The eager attribute should only be used for modules which provide no exciting user functionality in and of themselves: they only bridge together other modules. This way there is no reason why a user would want the module off. If you have form and i18n enabled, why would you want to turn off form+i18n? It is an implementation detail that it is even a separate module at all. For modules like "XML tree editing" etc. that provide noticeable and optional functionality on top of e.g. "XML core", these should not be marked eager. The user should decide whether it is to be turned on or off. I tried to say, that 'Enabled' property must not be read-only. And when this property is not read-only, this could be used for common modules. E.g. - All modules are on. - User will disable XML Core and then XML Tree, XML Text and XML Tools are also disabled, because of they depend on XML Core. - Now, when I enable XML Core, then XML Tree, XML Text and XML Tools will be automatically enabled, because they was previously disabled by module, not by user. - XML Core and XML Text and enabled; XML Tree and XML Tools are disabled. - User will disable XML Core and then XML Text is also disabled, because of it depends on XML Core. - Now, when I enable XML Core, then XML Text will be automatically enabled, because it was previously disabled by module, not by user. And XML Tree and XML Tools stay disabled, because it was previously disabled by user. I think that implementation could not be hard - probably one new property, which describes who disabled module - user or failed module dependency. When I am thinking about it, my table was not really correct. Read-only Enabled property is not good thing, because I would not be able to enabled XML Tools (when XML Core disabled) - so current state (XML Core is enabled because of XML Tools depend on it) is good. What you are asking for is definitely a different thing than bridge modules. Please open a separate RFE, I will try to implement it, but I don't have time for it now (in the current branch). I do not suggest bridge modules be used for the XML modules except for XML Text. It makes no sense for XML Tree or XML Tools, for example. Your suggestion makes more sense now; it is a job for a higher UI layer than the module system per se, more for the Modules node: if disabling A prompted the user in a dialog to also disable B since B depends on A, then if later on A is enabled via the module node, the user will be prompted to also enable B (if B still exists). Nothing of the sort will happen if the enablement is controlled by other means, for example session switching, etc. Of course, an alternate approach is to display just the module category by default in the Modules node, so that novice users will just enable/disable "XML" (meaning a cluster of modules), whereas more advanced users could choose to turn on only the core but not tools. This convinces me that the approach for what you are describing is more of a UI concern, and should probably get nbui involved. Issue 17776 has been deprecated in favor of issue 18781 Work complete in branch incl. tests, pending merge. Implemented. http://core.netbeans.org/source/browse/core/Attic/moddeps-todo.txt?rev=1.2&content-type=text/x-cvsweb-markup functionality verified in 3.4 dev builds |