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 88352 - Ability to use NbPreferences for singleton window persistence
Summary: Ability to use NbPreferences for singleton window persistence
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: issues@platform
URL:
Keywords: API
Depends on:
Blocks:
 
Reported: 2006-10-31 19:01 UTC by Jesse Glick
Modified: 2010-08-11 13:29 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 Jesse Glick 2006-10-31 19:01:02 UTC
Currently you have three choices for singleton windows:

1. Serialize state always.

2. Serialize state when open.

3. Never serialize state and thus do not reopen after a restart.

For #1 and #2, you are forced to use a .settings file with serialized hex data
in it. It would be great if you could somehow choose to keep your state
information (if you have any - you might not) in Preferences instead, and use
something else for the TC instance definition - e.g.
$userdir/config/Windows2Local/Components/*.instance.

TBD what API would be best for this. It need not explicitly mention Preferences
since you can read and write Preferences without any help from the window
system. Probably no special equivalent to readExternal is needed - when your
component instance is first created, just load its state from preferences, e.g.
in the constructor. TBD whether some equivalent to writeExternal is needed. If
there is none, then you are forced to eagerly persist state changes while the
IDE is running, which could be a performance problem for some windows (e.g.
those that wish to persist node expansion states).
Comment 1 Jesse Glick 2006-10-31 19:02:20 UTC
Note: some solution for non-singleton windows (e.g. documents) would also be
nice, but I think that might require a different design, so I limited this to
singletons for now.