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: | Add "show only editable properties" menu item | ||
---|---|---|---|
Product: | platform | Reporter: | _ tboudreau <tboudreau> |
Component: | Explorer | Assignee: | _ tboudreau <tboudreau> |
Status: | VERIFIED WONTFIX | ||
Severity: | blocker | CC: | dpavlica, jrojcek, lhasik, mmirilovic, tpavek |
Priority: | P2 | ||
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://ui.netbeans.org/docs/ui/propertysheet/ | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
_ tboudreau
2003-05-22 01:43:50 UTC
Fonts and colors in the Form editor are editable, so I don't think that there is a problem with them. On the other hand, there are some read only properties in the Form editor and it's good to hide them by mentioned menu item. No, I mean Options | Editing | XXX Editor | Fonts and Colors (or Abbreviations). Scenario: User selects Show Only Editable Properties. Then they try to customize the editor colors or abbreviations. They will never find these properties in the Options dialog, because they will not be visible - they are read only properties which do supply a custom editor for editing them. Any property in the options dialog which uses this technique and doesn't allow direct editing as text will be hidden from the user. Wouldn't it make more sense to file issues against the Form editor to hide useless properties (like "ancestorListeners")? Such properties are just noise for the user - there is *never* anything that can be done with them. I see, these noneditable properties in the Option dialog... Your scenario has sense. So, what do you think Jano ? About that Fonts&Colors, Abbreviations, Macros in the Option dialog. I realized, that these properties should be visible as editable, because user could use customizer for change them. And they are visible as editable in old version of the Property Sheet as well. They aren't inline-editable of course, but more important is the fact, that value could be changed. Per discussion, closing issue. We can reopen if it's really impossible to get form editor to suppress useless properties. I don't agree here. Form Editor surely can eliminate the read-only properties, but these properties exist and if some bean have such properties, the user might want to see them (not to edit them, just to see the values). The problem is that Swing components have many such properties that are useless, so they are better to be hidden by default, but there should be a way to show them. I guess the "show only editable properties" menu item could work per property sheet instance, not globally, and the state need not be persistent. It worked well so far - all property sheets in the IDE showed all properties (and the users had no need to see only editable), form editor by default showed only editable properties with the possibility to show all if user wanted (and form editor remembered this setting for its property sheet). I don't understand why it should be UI issue if this remained... >It worked well so far - all property sheets in the IDE >showed all properties (and the users had no need to see only >editable), form editor by default showed only editable >properties with form editor by default showed only editable > properties with > the possibility to show all if user wanted (and form editor > remembered > this setting for its property sheet). Okay. Reassigning to Form->Property Sheet from openide. Removing block from 29447 - form editor can implement some UI for showing editable properties only independantly (by changing what properties are returned by the node and firing a property change of PROP_PROPERTY_SETS). I'll investigate whether it is possible to remove the superfluous read-only Swing properties some other way - as they are probably the only reason for the feature. I've added the read-only Swing properties to filter table, so they are no longer displayed now. They will be shown for custom subclasses of Swing components, but here the user have the possibility to provide correct BeanInfo. The "show editable properties" feature has not been implemented, but I'm marking this fixed anyway. trunk: /cvs/form/src/org/netbeans/modules/form/FormUtils.java new revision: 1.68; previous revision: 1.67 prj40_prototype: /cvs/form/src/org/netbeans/modules/form/FormUtils.java new revision: 1.66.2.3; previous revision: 1.66.2.2 Reopening as defect. P2 to be fixed in 3.6. Will reassign to Tim. The popup menu should be same as defined by the ui spec (see URL). reassigning to Tim, the property sheet owner. Huh? As far as I know, everyone involved agreed that it made much more sense to simply eliminate unnecessary properties than create a "feature" to compensate for not doing that. Lukas, did you talk to anybody about this before reopening? I think the only problem is that the visual spec was never updated to not show the menu item. I've talked with Dusan about it. The ui spec should be up-to-date. One have to be fixed - spec or menu. Up to you, Dusan. verified |