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.
If a module totally replaces the toolbar items, the toolbar is only about half as high as it should be and you can't manually resize it larger than the first row of buttons. Even when the layer file has explictly ordered contents, 1) the explicit ordering is ignored (it uses alphabetical ordering) and 2) only the toolbars that can fit in the first toolbar row are visible. http://www.netbeans.org/issues/show_bug.cgi?id=17439 is also an ordering problem; I don't know whether it's related.
Dafe, UI/Swing bugs are yours :-)
It may be a problem with the layer file. See thread: http://www.netbeans.org/servlets/ReadMsg?msgId=240644&listNam e=nbdev This is a top-priority problem for me. I'll try to recreate the problem with a test module and would appreciate any pointers you may have for fixing this.
Accepting, please if you have test module attach it, it will help me to reproduce and understand what's going on.
Created attachment 4347 [details] zip file with test module layer.xml, .jarContents, & .jar file
The test module I just attached has a layer file with ordered toolbars to demonstrate these problems: - ordering is ignored - at most one row of toolbars is added - if you remove the TOolbars contents in mf-initializer.xml, the toolbar is only half-height. - sometimes you can't reorder them by dragging. The module has a layer file with toolbars ordered as follows: SSystem01 VView02 MMemory03 EEdit04 DData05 BBuild06 Misc07 Misc08 They require at least two rows. The layer file also hides all of the standard toolbars. 1) If you mount the directory for this module and 'execute' the .jarContents file to add this as a test module in NB 3.3.1RC2 (with OpenAPIs Support [org.netbeans.modules.apisupport 2.10.2), one row of toolbars are displayed, in alphabetical order: BBuild06, DData05, EEdit04, MMemory03, Misc07, Misc08 (partial). (order is ignored, only one row appears). You can reorder them onto a 2nd row by dragging. 2) If you do a NB3.3.1RC2 build using ant -f build.xml -Dmodules= then copy the module jar to nbbuild\modules, and do ant tryme you see the toolbars named BBuild06, DData05, and EEdit04. 3) If you remove or comment out all of the Toolbars section of org/netbeans/core/resources/mf-initializer.xml, copy the test module jar as above, and do a tryme, you'll get the half-height toolbars, with only BBuild06 & DData05. You can't reorder by dragging.
I tried to create a Toolbar Configuration to see if that would honor the ordering and row assignments. It appeared to be ignored also. I'm attaching the modified files, in case there's something wrong or missing in them that was really the problem.
Created attachment 4409 [details] layer file that includes a toolbar config reference
Created attachment 4410 [details] Toolbar Configuration xml file
Apparently the WKSPNAME.wswksp line that names the toolbar configuration is required. If I create a Configuration file in my module named Standard.xml and the Editing.wswksp file contains: <toolbar configuration="Standard" /> then the order and rows here are respected. So I don't know whether this is a bug or feature, since I can't find it documented anywhere, but I think I can configure my toolbars now correctly.
I take this issue.
It seems to me that toolbar configuration file is missing like Standard.xml. This file contains list of toolbars available in given configuration. For example Standard.xml describes toolbars used as standard and Debugging.xml for debugging. (Debugging.xml can be found in debuggercore module.) These configurations are then used in workspace to activate currently selected configuration. Can you tell me where did you find description how to add your own toolbars? (Perhaps something is missing or not clear there. I will check it.) I think you must have at least one toolbar configuration file. It will appear in popup menu in toolbar area. Let me know how it works when you add configuration file. Now description of wswksp file is available in description of Window System API. Definitely in description of toolbars there should be note about this. In wswksp file <toolbar configuration="" /> sets active toolbar configuration for given workspace. I do not know what happens when it is missing.
When there is no or unknown toolbar configuration set in workspace default toolbar configuration is activated. Default is "Standard" - this is hardcoded in ToolbarPool. If "Standard" is not found any available is set. When no toolbar configuration is found no one is activated ... It is in org.openide.awt.ToolbarPool.setConfiguration(). You can create some simple toolbar configuration, then create using ui custom, save it and use in module layer.
Yes, if you have a .wswksp file that names a toolbar configuration, the order is respected. I find this anti-intuitive -- why isn't the toolbar ordering used from the layer file just like the menubars? Now that I understand all of this, yes, http://www.netbeans.org/download/apis/org/openide/actions/doc-files/ap i.html#adv-install explains that you need a toolbar configuration, but I sure didn't understand it before. An explicit example would really help here, and also in other places toolbars are mentioned: http://www.netbeans.org/download/apis/org/openide/modules/doc-files/ap i.html#how-layer http://core.netbeans.org/tutorial/toolbars.html is the only place I can find that gives an example of a toolbar configuration, but doesn't say what to do with it. I don't think this document is linked from the other two above, it needs to be. I think the half-height problem stems from some sort of XML parsing error. Sometimes these errors are quietly ignored (when the layer file is sytactically but not semantically correct?), but once I saw it when I had a mis-placed "<" in my toolbar configuration file and it generated an exception. So I think this may be more of a documentation issue rather than a coding issue. I don't know where the information needs to go, exactly, but I definitely think it needs to be more explicit and more examples are needed somewhere. Thanks for looking into it.
I will cc Jesse, he can decide what and where to add. Please Jesse can you look at it? As you can see from last two comments some link(s) would be probably helpfull to make connection between toolbars and window system doc. What do you think?
I guess layer ordering could be respected in the absence of a toolbar configuration, though I am not sure it is all that helpful. Roxie's original (2) "only the toolbars that can fit in the first toolbar row are visible." sounds like a clear bug to me, was this resolved? I am getting lost in all the comments here. Re. why toolbar configurations are not described completely in the Actions API: last I checked with Yarda, the XML toolbar configuration syntax is not supported by the Actions API. It happens to work now but is not guaranteed, i.e. is a core feature. Creating an instance of org.openide.awt.ToolbarConfiguration *is* supported (and is what the XML file in fact does); but of course no one in their right mind would hand-code a custom ToolbarConfiguration when the normal XML syntax works and has worked for several releases. Yarda should we just decide that this XML syntax is supported now, and document it properly?
With NB3.3.1 RC3, I tested the first module again and only see one row of toolbars.
Assigning to Dafe
Target milestone was changed from '3.4' to TBD.
changed owner Dafe -> Peter Z.
See also issue #17439
reassign to Tim, new owner of AWT/Swing
Passing toolbar XML issues back to Marek per Dafe's request.
Assigning to Tim
Trying the attached module, I saw no half height toolbars; interestingly I was able to install it once and the toolbars changed; the second time I installed it there was a message that core compiler was missing, but that's another issue. Given that workspaces are gone and the toolbars appeared correctly, and it appears the filer solved the problem by using a toolbar configuration file, closing as works for me. If there is still urgent interest here, reopen.
verified/closed