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 35631 - OK/Cancel approach to all dialogs in the IDE
Summary: OK/Cancel approach to all dialogs in the IDE
Status: RESOLVED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: David Simonek
URL:
Keywords: UMBRELLA
Depends on: 34245
Blocks: 35735
  Show dependency tree
 
Reported: 2003-08-21 11:05 UTC by mvinar
Modified: 2008-12-22 20:26 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mvinar 2003-08-21 11:05:01 UTC
User problem:
-----------------------------------
The concept of immediate changes without hitting
OK or Apply button is counterintuitive and does
not allow the user to Cancel changes.

User need:
-----------------------------------
User needs an intuitive and consistent way how to
enter data in the IDE's dialogs.

Product requirement:
-----------------------------------
OK/Cancel approach to all dialogs in the IDE.
Comment 1 _ tboudreau 2003-08-24 01:10:11 UTC
Difficulty: 9
Hack factor: ?

One main source of dialogs, and unfortunately, a thing that
makes this issue almost literally impossible to solve:

java.beans.PropertyEditor.getCustomEditor()

The problems:
1. An under-specified (afterthought?) API that defines no
contract for how a custom editor should behave
2. Custom editors commonly implemented as inner classes of
property editors (or PropertyEditor implemented on the
custom editor component class) - these often do their own
updating of the underlying property/property editor.  There
is no way to enforce OK/Cancel semantics (there's no way to
even enforce that the component is a component, not a window).

See
http://openide.netbeans.org/proposals/property-infrastructure.html

for a detailed exposition of some of the issues.

Solution:
 - Deprecate/discontinue usage of getCustomEditor
 - Provide a separate registry of custom editors which
   map to properties.  Define an interface that must be
   used, which defines the contract required by the 
   infrastructure

Comment 2 Jan Chalupa 2004-11-01 16:50:27 UTC
Re-assigning Tim's issues to Dafe.
Comment 3 David Simonek 2005-05-05 17:15:55 UTC
Right, but should be divided into specific enhancements for specific dialogs,
make no sense to have such overall not specific enh in IZ. Please enter specific
defects where things are broken.
Comment 4 Milan Kubec 2005-05-06 08:42:27 UTC
I think that this issue might be an umbrella issue for all specific issues. It
could be tracked better. What do you think?
Comment 5 David Simonek 2005-05-06 11:48:51 UTC
Yes, but we should have specific issues first, for umbrella to make sense.