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.

Bug 33818 - Add "show only editable properties" menu item
Summary: Add "show only editable properties" menu item
Status: VERIFIED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: Explorer (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: _ tboudreau
URL: http://ui.netbeans.org/docs/ui/proper...
Keywords:
Depends on:
Blocks:
 
Reported: 2003-05-22 01:43 UTC by _ tboudreau
Modified: 2008-12-22 23:41 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ tboudreau 2003-05-22 01:43:50 UTC
The "show only editable properties" menu item
needs to be
implemented - but there are issues that this
complicates
the UI and does not add much value, and can hide
properties
like Fonts & Colors which show up as read-only but
have
a customizer.
Comment 1 dpavlica 2003-06-04 15:36:49 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.
Comment 2 _ tboudreau 2003-06-24 10:25:39 UTC
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.
Comment 3 dpavlica 2003-06-24 11:40:52 UTC
I see, these noneditable properties in the Option dialog...

Your scenario has sense. So, what do you think Jano ?
Comment 4 dpavlica 2003-06-24 12:57:50 UTC
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.
Comment 5 _ tboudreau 2003-07-15 16:16:03 UTC
Per discussion, closing issue.  We can reopen if it's really
impossible to get form editor to suppress useless properties.
Comment 6 Tomas Pavek 2003-07-25 08:53:22 UTC
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...
Comment 7 _ tboudreau 2003-07-28 14:02:24 UTC
>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.
Comment 8 _ tboudreau 2003-07-28 14:24:54 UTC
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).
Comment 9 Tomas Pavek 2003-07-28 18:18:24 UTC
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.
Comment 10 Tomas Pavek 2003-07-31 13:05:40 UTC
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
Comment 11 Lukas Hasik 2004-01-13 16:54:49 UTC
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).
Comment 12 Lukas Hasik 2004-01-13 16:56:12 UTC
reassigning to Tim, the property sheet owner.
Comment 13 _ tboudreau 2004-01-13 20:46:18 UTC
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.
Comment 14 Lukas Hasik 2004-01-14 09:13:41 UTC
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.
Comment 15 Marian Mirilovic 2004-02-27 14:03:04 UTC
verified