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 19077 - Deleting a workspace that has the editor open on it causes the editor to close on all workspaces.
Summary: Deleting a workspace that has the editor open on it causes the editor to clos...
Status: VERIFIED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: Peter Zavadsky
URL:
Keywords: ARCH
Depends on:
Blocks:
 
Reported: 2002-01-05 19:17 UTC by _ tboudreau
Modified: 2008-12-23 09:07 UTC (History)
2 users (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 _ tboudreau 2002-01-05 19:17:04 UTC
Open the editor on the Editing workspace.
Customize workspaces and create a new workspace.
Change to the new workspace.
Open the source editor using View | Source Editor
Open customize workspaces again and delete the Editing workspace.
The editor closes.   Probably this is true of any TopComponent which is
CLOSE_ALL.
Comment 1 Jiri Rechtacek 2002-01-09 10:27:55 UTC
The mode of the editor is closed with closeOperation=CLOSE_EACH which
forces close the mode on all workspaces. I will investigate why
CLOSE_EACH.
Comment 2 David Simonek 2002-01-09 13:48:30 UTC
Jiri, hold on!
editor is CLOSE_EACH = ui group decision, they were very upset when we
(Tim and me) suggested to throw it away. Hopefully for 3.4 we can
change this.

BUT! Problem is not so simple - it should work correctly even with
CLOSE_EACH flag - I mean that during deleting of workspace, modes with
CLOSE_EACH flog shouldn't be closed as usual, but only on that
workspace that is being deleted. You'll need additional logic in
mode.close(TopComponent) method to distinguish somehow this case.

Comment 3 Jan Chalupa 2002-01-11 14:00:45 UTC
Target milestone -> 3.4
Comment 4 Jan Chalupa 2002-01-11 14:05:10 UTC
Target milestone -> 3.4
Comment 5 Jan Chalupa 2002-01-11 14:06:42 UTC
Target milestone -> 3.4
Comment 6 Jan Chalupa 2002-01-11 14:10:18 UTC
Target milestone -> 3.4
Comment 7 Jiri Rechtacek 2002-01-18 20:40:41 UTC
There is a way how fixed this issue but the fix would force the API of
Workspace, the method openide/TopCompoment.close should respond to a
state of workspace on which is opened (especially deleting) but there
is no way how TopComponent be informed. I guess any change there so it
would be solved later during 3.4 development cycle.
Comment 8 Jiri Rechtacek 2002-05-24 09:53:41 UTC
This behavior (seems as defect) is supposed and asked by ui group. It
should be tracked as enhancement for next release, should be discussed
on nbui. If I'm wrong set back to defect and start a discussion there.
Comment 9 _ tboudreau 2002-06-10 15:28:05 UTC
The larger issue is whether CLOSE_EACH is intuitive - there is a
fairly decent sized group of users who think it is not.  Probably the
thing to really address is whether CLOSE_EACH actually makes sense.

But this issue does feel more like a defect than an enhancement to me
- it is unexpected behavior.
Comment 10 Marek Grummich 2002-07-22 08:32:02 UTC
Target milestone was changed from '3.4' to TBD.
Comment 11 Marek Grummich 2002-07-22 08:39:48 UTC
Target milestone was changed from '3.4' to TBD.
Comment 12 Marian Mirilovic 2003-11-26 12:56:56 UTC
Because Window System v1 will not be supported from now by our team, all old
winsys issues (now "core/window system v1" issues) are going to be closed as
WONTFIX. 

Changes in API which emerged both from UI spec 
and problems with adjusting to the older API are described in the document
http://core.netbeans.org/windowsystem/changes.html.
 It shows also recommends how the client code should be adjusted to the new
window system.

If you think this issue apply also to the new winsys then change the
subcomponent (to "core/window system") and REOPEN it.
Comment 13 Marian Mirilovic 2004-02-27 14:11:08 UTC
issue doesn't apply to new window system - verified