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.
I was frustrated in an attempt to just add a couple menu items to the popup menu for Ant build scripts. It seems impossible to do without depending pretty heavily on the xml/text module in a number of unrelated details. What I wanted to do was just add the actions to Editors/text/x-ant+xml/Popup/ and have them appear. However the editor support is normally set to text/xml. If you set it to text/x-ant+xml, Ant scripts appear as plain text (and still do not show the actions!). Attaching patch. IMHO there should be some way to indicate that a given MIME type delegates to another except for anything specifically overridden in its Editors/$type/ subfolders. Here I would make text/x-ant+xml identical to text/xml except for the added actions. I don't want to manually redefine the editor kit, abbreviations, settings, etc., as these should all be the same, and are implemented privately in xml/text-edit in a way I would rather not depend on directly. Is some kind of delegation support planned for editor kit registration in the future? The options code already supports the Editors/text/base/ folder as a starting folder to merge into; all that is needed is to merge three or more folders rather than just two, e.g. Editors/text/base/ + Editors/text/xml/ + Editors/text/x-ant+xml/ (later folders taking precedence over earlier in case of conflict).
Created attachment 10492 [details] Attempted but failed patch for Ant module
I would definitely like to add that sort of mime-types delegation. Ideally I would like to be able to tell the SFS to give me a merge of two or more different directories that I choose in a similar way like the current overriding of a single dir on SFS by user's changes works. Currently I do it by hand in e.g. an editor toolbar that merges text/base with target mime-type toolbar dirs. But even without that functionality it should be feasible to implement it.
"Ideally I would like to be able to tell the SFS to give me a merge of two or more different directories that I choose in a similar way like the current overriding of a single dir on SFS by user's changes works." - (1) AFAIK you can already do this, without manually merging files and attributes. (BTW your code to sort the folder by attributes is probably wrong - cf. Utilities.topologicalSort.) Just use MultiFileSystem. E.g. give it two delegates, both of which are the SFS (hope it handles this correctly!), but overriding some methods. Or you may need to make a plain (not subclassed) MFS with two delegates, each of which is a MFS over just SFS with findResource overridden to add a prefix. Anyway, it is supposed to be possible. Yarda may be able to help you. (2) David, I think it might be very useful for there to be some way to do this sort of thing using the Registry API - even if 4.0 Projects are not going to use it the same way 3.x projects.jar does, there are other cases like this where it seems it would be useful. Not sure exactly what the API would look like, but something like public static Context Context.merge(Context[] delegates); documented to behave in the normal layering kind of way, with the first delegate written to, and the merged context guaranteed to be resettable. This belongs in the API not SPI, I think, since it is something a client of the Registry (like the editor module) would want to do. Anyway, just an idea to consider.
Yes, this can be easily added into Registry API and I think that it would be useful. The new projects are using something like this as well. I just wanted to wait and see whether somebody else would use it or not. Mila or Jesse, please file an enhancement issue for me for openide/settings modules. Thx.
AD (1): thanks for your idea, Jesse. You already mentioned that as a response to my question on nbdev: http://www.netbeans.org/servlets/ReadMsg?msgId=212212&listName=nbdev Unfortunately, the merging and sorting was already implemented before it and I probably didn't try your solution. We would like to split editor settings implementation from editor module and provide a new mechanism of settings via Editor Settings API. It should solve the inheritance issues like these mentioned in this issue or in i.e. : http://www.netbeans.org/issues/show_bug.cgi?id=22338
I filed #34057 for the Registry API.
Increasing priority. This is important for usability of the Ant module. After some searching, looks like BaseOptions.getOrderedMultiPropertyFolderFiles is responsible for this logic. At least for the popup menu. Not clear if something else finds the toolbar, the editor kit, etc. Looks like the whole editor settings infrastructure is quite a mess.
Any plans to fix this?
I'm willing to fix it after we clarify what exactly needs to be done. 1) We need to be able to define mime type's parent (not sure whether that's implied somehow from the mime type's name but I guess that not). Could be done through a file on SFS or possibly just through an attribute. 2) Some functionality is defined through EditorKit such as o.n.e.Syntax from createSyntax() defines the syntax coloring processing or getActions() returns actions etc. It would IMHO be better to define most of these things through the layer so that they are overridable and making the kit just a wrapper around the primary information from the layer. Regarding shortterm solution for popup menu items for 4.1 there could be sort of a hack done to use ContextAwareAction registered into text/xml mimetype (but registered from ant module's layer). If the ContextAwareAction.createContextAwareInstance(Lookup actionContext) returns null the editor popup creation code will silently ignore it so it could do so for plain xml but it could return valid action for ant script.
Well the only MIME delegation I *know* we need is from text/*+xml to text/xml, as well as the existing text/* to text/base. Re. the ContextAwareAction trick - interesting, I will try that if I get a moment.
Should this be considered fixed now? By the way I just realized that XHTML is supposed to use application/xhtml+xml as the official MIME type, so I hope this will delegate to text/xml...
>"Should this be considered fixed now?" As for Popup subfolder yes, so I am closing this issue as fixed. Other places are being rewriting to MimeLookup, that supports these "plus" mime types also >By the way I just realized that XHTML is supposed to use application/xhtml+xml >as the official MIME type, so I hope this will delegate to text/xml... No. This will delegate to application/xml and not text/xml. There is generic algorhitm for that. This seems to be an exception. Or as for xml it is probably rule, that if +xml is found the folder "text/xml" should be taken into consideration. I hope there will be not more such exceptions... I think a defect should be filed, shouldn't be?
I filed issue #61245 re. XHTML.
It doesn't work in a dev build. Attaching my current patch attempt for issue #20203. The Ant script when opened in the editor is displayed as plain text, and there is no Run Targets in the popup menu.
Created attachment 23219 [details] Failed patch attempt
Yes, because the appropriate editor kit is not found for "text/x-ant+xml", that's why a default "text/plain" is used. For more details: EditorModule.HackMap.get() method. Before, when ant module used "text/xml", a XMLKit was found. I don't know how to solve this. As a first idea that is occuring me is that we probably need to create some delegating kit in editor module that will return "text/x-ant+xml" as a content type, but it will delegate all other requests to XMLKit. Mila, this is a question for you. What do you think?
IMO when searching for the registered kits we should use the same algorithm like in the mime lookup i.e. search for the kit in "text/x-ant+xml" and then in "text/xml". This way the xml kit would be found which is IMHO desirable. What do you think?
I would say it is a little bit different. Let's assume that a XMLKit was found for "x-ant+xml" using a mimelookup. In this case an items of the Popup menu stored under the "x-ant+xml/Popup" will not be used, because XMLKit.getContentType() will return "text/xml" and not "x-ant+xml". (A kit.getContentType() is used for retrieving the content type for popup menu constructing in NbEditorKit.NbBuildPopupMenuAction.)
I would say that we should consistently use the mime-type of the model i.e. document.getProperty("mimeType") everywhere instead of kit.getContentType() because IMO the nature of the model should determine operation of the editor completely. Currently I do not see a usecase where this assumption would fail so I would go that way.
fixed in [maintrunk] /cvs/editor/mimelookup/src/org/netbeans/modules/editor/mimelookup/LayerFolderObjectsProvider.java,v <-- LayerFolderObjectsProvider.java new revision: 1.5; previous revision: 1.4 /cvs/editor/mimelookup/src/org/netbeans/modules/editor/mimelookup/MimeLookupUtils.java,v <-- MimeLookupUtils.java new revision: 1.4; previous revision: 1.3 /cvs/editor/mimelookup/test/unit/src/org/netbeans/modules/editor/mimelookup/MimeLookupInheritanceTest.java,v <-- MimeLookupInheritanceTest.java new revision: 1.5; previous revision: 1.4 /cvs/editor/mimelookup/test/unit/src/org/netbeans/modules/editor/mimelookup/layer.xml,v <-- layer.xml new revision: 1.5; previous revision: 1.4 /cvs/editor/src/org/netbeans/modules/editor/EditorModule.java,v <-- EditorModule.java new revision: 1.118; previous revision: 1.117 /cvs/editor/src/org/netbeans/modules/editor/NbEditorKit.java,v <-- NbEditorKit.java new revision: 1.87; previous revision: 1.86
Editor module and mime lookup now works correctly and merge the popup items object from text/x-ant+xml/Popup + text/xml/Popup + Editors/Popup ... For some reason menu constructing doesn't work correctly for CollectXMLAction, that provides action items like Check XML, Validate XML... (- these actions are present in context popup menu in xml document but not in ant document) I have found that CollectSystemAction.createMenu doesn't return the Check XML action, because the action is not enabled in ant context. Check XML action is NodeAction and in NodeAction.isEnabled() method getProperty(PROP_ENABLED) returns false... I will investigate further, if you have no idea, what's wrong...
Don't worry about the Check XML action etc.; I think I know what is going on there. Has nothing to do with the editor. The context menu does seem to work - thanks!