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.
In the Form Editor, it appears that if a Class is not checked out, that a bunch of menuitems are removed from the JPanel popup. Rather than being removed, these should be disabled. (although disabling still has a problem if the user doesn't know why they are disabled; in that case it may be better to leave the menuitem enabled and let the user select it and then given them an error dialog that explains why that menuitem can't be run right now) I was recently running detached from our network with my laptop and I wanted to look at the gridbaglayout for a form to see how it was done (very nice gridbag editor). But as the class wasn't checked out, that menuitem was missing. Sad that I can't view the gridbag layout for a class I don't have checked out, as that would be useful. But it's also not good that the "Customize Layout" menuitem is removed from the menu (makes you think that this panel doesn't use a gridbaglayout).
Hmm, you can see all the GridBagConstraints properties in ComponentInspector (the same properties as you see in the customizer). You can see there also the GridBagLayout node under the container node, so why should you think that some panel doesn't use GridBagLayout? Only things you cannot see are the guiding lines (grid) and insets highlighting painted by the customizer, but these are useful rather for editing than just for overviewing I'd say... Another thing: the problem with customizer is that it is generally intended to be used for editing - but if the form is read only you can't edit anything. And there's nothing like read-only customizers (in JavaBeans spec., AFAIK). As for the hidden popup menu items - if they don't have sense (edit operations in read only forms) I think they should not be there. I don't think it's nice to have a menu with half of items showing error dialogs... Thanks for ideas, but I don't see this problem to be really a significant problem.
the Java Look and Feel Design Guidelines say "If an application feature is not currently available in a window, but users can do something to make it available, make the corresponding menu item unavailable an dim its text." Since Netbeans does not appear to me to be following this guideline here, I am reopening this.
> "... but users can do something to make it available ..." But user can't do anything if the form is read only, the hidden menu items are realy irrelevant in such situation.
I am reopening this issue because I, too, would like to see the layout properties for a form even when the form is read-only and even if I cannot edit the layout. As a frequent user of the form editor, there are many times that I have wanted to look at the values of a layout and have had to make the form file read-write, even though I didn't make any changes. This is a usability problem. As a tool developer you have to understand that your customers will use your tool in different ways and you should provide flexibility. Your customers would find this enhancement useful even though you yourself would not.
Jeri, the properties are there - they are just read only. The problem is that the property sheet by default does not display read only properties, but there's a toggle button to make them visible.
This issue is about missing menuitems in the Form editor, and not about missing properties, so I am re-opening because the problem still exists. In the Form editor, if a class is not checked out, then many menuitems are missing on the nodes in the tree panel (upper right). Examples: for a JPanel widget with a gridbaglayout, the popup menuitem "Customize Layout" is missing (not just dimmed out); for a JScrollPane the popup menuitem "Add From Palette" is missing. I believe this issue is scratching the surface of a general problem with the limited functionality of read- only forms; an important example (mentioned by Jeri above): if a VCS form is not checked out, then you can't even look at the gridbaglayout editor -- you may want to just look at it, so you can copy that layout for another form you are building -- but in order to see that editor, you have to check out the form. But that limited functionality problem is a different topic and is not the subject of this issuezilla -- the missing menuitems in some form states are the subject of this issuezilla.
Several "problems" are mixed in this issue: * Display of layout properties in read-only forms These properties are displayed by default by now. * Customize layout dialog cannot be invoked for read-only form. The Customize dialog is a part of a more general JavaBeans concept that doesn't support read-only "customizers". * Some actions doesn't appear in popup menus of read-only forms. That is exactly according to the Java Look and Feel Design Guidelines: "If there is nothing users can do to make a menu item available, omit the item entirely rather than just making it unavailable. Making an item unavailable implies that users can do something to make the item available. A similar rule applies to submenu items and contextual menus."