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.
Umbrella issue for navigator related work targeted to 4.2 release.
Attaching materials for dev-rev inception review:
Created attachment 22549 [details] answers to arch questions
Created attachment 22550 [details] API clients how to mini guide
All code can be found in cvs module core/navigator, on branch navigator_58819. In "arch" subfolder, example implementations and layer declarations can also be found.
Where is BasicNavPanelImpl.java? The link http://www.netbeans.org/nonav/issues/showattachment.cgi/22550/BasicNavPanelImpl.java didn't work for me.
Doh I should have read your comment about the branch, I'll look there. (Just FYI the link I followed was in the ModulesHowTo.html document)
The second link - basicNavLayer.xml doesn't work for me as well.
In the manifest there is OpenIDE-Module-Layer: org/netbeans/modules/navigator/resources/layer.xml But the layer doesn't exist and the module is not started.
Petr and others - links from ModulesHowTo attachment don't work, I know, sorry you have to checkout from cvs and browse. PPisl - module is not yet ready for development, but thanks for info anyway.
To make review interesting a bit, here is a list of open issues that I have in my mind: 1) How to specify order of multiple providers? (Imagine you'd want your special xml view, say for web.xml to be always higher in Navigator UI combo than generic xml view). My idea is to either put optional integer attribute "order" in xml layer or use layer sorting mechanism itself. 2) Persistence - navigator views may want to persist some information, most likely filter options of what to show, what to hide. Currently there is no explicit mechanism for persistence in Navigator API. Easy solution is to store views' settings in Navigator top component serialization, but TopComponent serialization is not friendly to storing format changes, which may be serious problem. Any idea here? 3) JSP people already expressed their wish to differentiate between node selected in opened editor and node selected somewhere else (explorer), mostly because of their performance and implementation reasons. I feel this could be common case. How to approach such problem? We could have a flag in the layer, meaning that a provider wants to be active only when node in editor is selected. Or more generally, we could give providers info about selected node type and give them chance to refuse to show completely or to show simpler structure for in specific situations. This would lead to additional filtering-like interface with method accept(Node node).
Looking at public packages (in project.xml): 1. I don't see the org.netbeans.api.navigator package in the code. What classes should be there. 2. The dependency on org.openide.loaders doesn't seem to be required.
As far as the persistence problem - what about to provide the ability to create the layer file for settiongs. The layer file (xml file) can consist of 2 parts : optional part with known elements (like the order of view that should be open) extesible part : anything can be included there. Suggested schema for that file : <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://xml.netbeans.org/navigator/settings" xmlns="http://xml.netbeans.org/navigator/settings" elementFormDefault="qualified"> <xsd:element name="settings" type="ns:SettingsType"/> <xsd:complexType name="SettingsType"> <xsd:sequence> <xsd:element name="viewToOpen" minOccurs="0" type="xsd:integer"/> <xsd:element name="optional" minOccurs="0" type="xsd:anyType"/> </xsd:sequence> </xsd:complexType> </xsd:schema> Sampe xml document : <settings> <viewToOpen>0</viewToOpen> <!-- number of view that should be opened --> <optional> <!-- anything can be included here --> </optional> </settings>
The problem nr.3 is also related to MultiView editors. We'like to have different structures in Navigator for different views. See for example the web.xml editor.
Only a quick node: I would recommend to use NavigatorPane.panelActivated(Lookup) instead of NavigatorPane.panelActivated(Node).
Y01 arch document talks about openapis. they are gone. please enumerate what you really depend on Y02 the navigator shall not listen on activated node, but on Utilities.actionGlobalContext, imho. It returns Lookup which then contains selected nodes. This will make the system more testable and composable. Y03 Load the registered providers using standard mechanism - e.g. FolderLookup so the set of registration formats is the same. Btw. otherwise document format-types question. Y04 The API cannot be under development forever. When you change it to official? Y05 Is it guaranteed that the SPI method is called from AWT thread or not? Y06 Why the how to is not part of arch*xml usecases document? If you do that you will be included in standard pages with usecases. Y07 Why the <api /> tag is not used to describe layer interface? We now generate summary page based on that and it is shame there is no description now:
Looking at the branch, I guess package org.netbeans.api.navigator should be removed from public packages - it does not exist.
Note that the layer content in the example is not in accordance with the ProviderRegistry class code. The currently required layer format for NavigatorPanel instancies is following: <folder name="navigator"> <folder name="panels"> <folder name="text"> <folder name="xml"> <file name="org-netbeans-modules-xml-text-navigator-XMLNavigatorPanel.instance"> <attr name="mimeTypes" stringvalue="text/xml"/> </file> </folder> </folder> </folder> </folder> Please fix the example content.
How the new navigator (newly inspector) module coexists with the old navigator api/spi and its java implementation? I suppose the old one will be removed right? Just now I have to disable the old navigator module to be able to use the new one.
I believe there was a TCR to remove the mimeTypes attribute, so plain FolderLookup could be used. No?
Hi all, sorry for delayed response, I was warking on TCRs and java navigation module conversion at full speed :-) Situation now: Nearly all TCRs completed, some documentation remnants left. Example xml layer updated, Jesse is right it now conforms to FolderLookup style of registration. I'll ask for exit review soon, there are several minor topics that I'd like to talk about: 1) I added spi.navigator.NavigatorLookupHint interface. It is for clients which want to specify their Navigator content type in their node. I hope you'll have no objections. 2) There seems to be a performance/flicking problem in Java client of new Navigator API. When user is traversing java source code in editor code by arrows, node for each method is activated, triggering repeated panelActivated/panelDeactivated calls on java client's NavigatorPanel impl. This causes flickering/unnecessary reloading of Navigator content. My solution: I'd add method to the NavigatorPanel, say "contextChanged (Lookup)" which will be called if node changes but still the same NavigatorPanel provider is available. Client impl side then can judge if old and new context are somehow related and not reload everything in such case. How about that?
Can you attach results of "ant javadoc" and "ant coverage" here?
Re. flicking: The lookup is designed to be mutable and everyone working with it is supposed to listen on changes inside it. That is why it would be enough imho, to just call activated(Utilities.actionGlobalContext()) as soon as first java file is selected and then ignore all node changes until someone selects different file type. The java impl would then listen on changes of its Lookup and update itself to the correct file content.
Yes, works but with one caveat - when lookup (activated nodes) is changed to contain navigator window itself, clients would need to be adviced to not empty their content, but stick with last context valid for them, which is not very nice :(
Hmm. I have not thought about that. Possible fix is to Use Lookups.proxy to have the selection of the lookup to delegate to under your control. Would mimic Utilities.actionsGlobalContext(), only in case when navigator window is selected, the previous Lookup would remain active. I do not know how much work this is, hopefully not much. This solution would still keep the spirit of dynamic behaviour of Lookup.
Opinion document available here: http://openide.netbeans.org/tutorial/reviews/opinions_58819.html
Thanks Tomas for opinion document. TCRs requested to be fixed before merge are fixed now, no further SPI changes I could see on my radar, so I'm going to merge to main trunk in a minute. Remaining TCRs and TCAs will be solved continually ASAP. Thanks again for your work.
Merge completed. Leaving this task still open until I resove remaining TCRs and TCAs.
Completed long time ago, just forgot to close this, closing now.