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 7069 - Disableing Object Browser dosnt remove Browser workspace from non-loaded projects
Summary: Disableing Object Browser dosnt remove Browser workspace from non-loaded proj...
Status: CLOSED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: All All
: P4 normal (vote)
Assignee: issues@platform
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2000-07-14 20:02 UTC by russells
Modified: 2008-12-23 10:57 UTC (History)
2 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 russells 2000-07-14 20:02:42 UTC
When the Object Browser is disabled in Global Settings, it correctly removes
the Browser workspace from the current project. The problem comes when you
change to another project, the Browser workspace still exists here, and a
problem occurs trying to de-serialize the browser information.

The correction would be one of two:
1)Removing the Object Browser automatically removes the browser workspace from
all projects
 or
2)When a project is opened that contains a browser workspace, it checks for the
object browser being enabled, if it is not then that workspace is removed.

This could go for other modules as well (debugger, form editor)
Comment 1 _ ttran 2000-08-24 08:45:59 UTC
this is a bug in Windows API
Comment 2 Jesse Glick 2000-08-24 12:13:59 UTC
I don't see any bug in the Window System API nor in the Object Browser module:
when installed it adds its workspace, when uninstalled it removes it. The
problem is with projects, specifically that window information is stored with
the project, when really it is a mix of module-supplied information (such as the
Browsing workspace and the Object Browser top component on it) vs. user-supplied
information (positioning of windows, extra windows the user opens, and so on). I
do not believe it can be fixed with the current project system.

In the project system being developed, "sandwich", there can be many layers of
information that make up what the user finally sees. When this happens, I think
windowing information should be split across two layers. One is the programmatic
layer, and any calls to the Window System API at the Java level will affect this
layer. Superimposed on it would be the user layer, containing user
customizations to the window configuration. Providing the user does not
customize the window configuration for e.g. a workspace in any special way, and
it was installed by a module, then removing the module will delete the workspace
from the programmatic layer and it will really disappear. If there are user
customizations to the workspace, they will be kept (for better or for worse, but
to be conservative they have to be kept).

If anyone thinks there is a workaround to fix this with the current project
system, feel free to reopen the bug. I am marking it "Later" because I think it
can be fixed in the future although I don't know exactly how.

Re. suggestions #1 and #2: #1 is not really reasonable from an API perspective;
it would be a huge hack to try to do this. #2: there is also no reasonable way
to make this work with the APIs. The windowing system can and should skip over
the Object Browser *window* if the module is no longer installed (and should be
polite about the error in this case), but not the workspace.
Comment 3 Jesse Glick 2000-09-05 16:58:59 UTC
See also thread at: http://www.netbeans.org/www-nbdev/msg00650.html
Comment 4 Jesse Glick 2002-02-14 19:45:46 UTC
x
Comment 5 Jesse Glick 2002-02-14 19:46:09 UTC
Already fixed.
Comment 6 Lukas Hasik 2002-03-19 16:40:30 UTC
closing, Object browser is gone.