Bug 81330

Created attachment 32294 [details]
diff to architecture questions

Created attachment 32295 [details]
changes in apichanges :-)

Some further comments:

This change may look dangerous, but in fact it isn't. Here is what will happen:

1) IDE Users that has saved NetBeans config in SDI mode from older version - IDE
will start always in MDI mode and users can restore their desired state by few
DnDs, with now more powerful ability to have separated even editor windows.

2) For module writers, nothing has changed now. DTDs for winsys layout xml are
planned co change compatibly in short future, but for now it stays the same.

3) Developers working on Netbeans platform. If they were using SDI mode
primarily for their apps, now they just need to ensure that their mode's xml
defining separate windows contain <state type=separated />, and they will get
the same fuinctionality as in old SDI, even with some improvements.

What is the timeframe? From testing tools point of view before SDI mode is
removed we need to:

- update the commit validation suite (remove or update testSeparateWindowsMode)
- remove SDI related stuff from Jellytools
- remove usage of netbeans.windows property from XTest

It should not take much time and I can do it.

Timing - after two or three weeks I guess, when there will be no pushback from
other teams. Floating windows functionality will hopefully be integrated into
main trunk later this week, but SDI removal must wait for agreement from other
teams.

Is this fixed and can it be closed or not?

No, this issue is still in progress, as it requires agreement from other teams
which I didn't receive yet. However API review is done I believe, taking back.

SDI mode removed from GUI and command line option, impl inside winsys will be
changed in next steps.

Removing core/windows/src/org/netbeans/core/windows/UIModeHandler.java;
/cvs/core/windows/src/org/netbeans/core/windows/UIModeHandler.java,v  <-- 
UIModeHandler.java
new revision: delete; previous revision: 1.5
done
Checking in core/windows/src/org/netbeans/core/windows/PersistenceHandler.java;
/cvs/core/windows/src/org/netbeans/core/windows/PersistenceHandler.java,v  <-- 
PersistenceHandler.java
new revision: 1.49; previous revision: 1.48
done
Checking in core/windows/src/org/netbeans/core/windows/WindowManagerImpl.java;
/cvs/core/windows/src/org/netbeans/core/windows/WindowManagerImpl.java,v  <-- 
WindowManagerImpl.java
new revision: 1.58; previous revision: 1.57
done
Checking in core/windows/src/org/netbeans/core/windows/Constants.java;
/cvs/core/windows/src/org/netbeans/core/windows/Constants.java,v  <-- 
Constants.java
new revision: 1.20; previous revision: 1.19
done
Checking in openide/arch/arch-openide-windowsystem.xml;
/cvs/openide/arch/arch-openide-windowsystem.xml,v  <-- 
arch-openide-windowsystem.xml
new revision: 1.53; previous revision: 1.52
done
Removing core/src/org/netbeans/core/UIModePropertyEditor.java;
/cvs/core/src/org/netbeans/core/UIModePropertyEditor.java,v  <-- 
UIModePropertyEditor.java
new revision: delete; previous revision: 1.6
done
Checking in core/src/org/netbeans/core/IDESettings.java;
/cvs/core/src/org/netbeans/core/IDESettings.java,v  <--  IDESettings.java
new revision: 1.88; previous revision: 1.87
done
Checking in core/src/org/netbeans/core/IDESettingsBeanInfo.java;
/cvs/core/src/org/netbeans/core/IDESettingsBeanInfo.java,v  <-- 
IDESettingsBeanInfo.java
new revision: 1.49; previous revision: 1.48
done
Checking in openide/windows/apichanges.xml;
/cvs/openide/windows/apichanges.xml,v  <--  apichanges.xml
new revision: 1.12; previous revision: 1.11
done
Checking in openide/windows/manifest.mf;
/cvs/openide/windows/manifest.mf,v  <--  manifest.mf
new revision: 1.14; previous revision: 1.13
done
Checking in
core/windows/src/org/netbeans/core/windows/view/ui/toolbars/ToolbarConfiguration.java;
/cvs/core/windows/src/org/netbeans/core/windows/view/ui/toolbars/ToolbarConfiguration.java,v
 <--  ToolbarConfiguration.java
new revision: 1.43; previous revision: 1.42
done

A note to add, a user has just mentioned that he used SDI and window placement
was remembered.  He wants Windows placement and docking remembered between
closing and opening files with undocking.  This would be similar to what the
Swing Application Framework does with its Window placement for it's main window.
 Any ideas here?

I noticed in the UI spec document this is to work this way for the main top
components.  The user mentioned wants this to work for editor tabs and all.

Changing the issue to task, what remains is code cleanup of now obsolete classes and parts of model.
wadechandler , to discuss new or desired behavior please use mailing lists and/or new enhancements/defects in
IssueZilla, thanks.