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.
There are several issues with the default layout of MDI: - the NetBeans Window does not come up maximized. This has a negative impact on anyone who does not use the expected default windows configuration on Windows, with 1 line high taskbar along the bottom. - the default window sizes and locations are absolute, so any resize of the main window affects the windows configurations, and many times creates unnecessary scrollbars - the editor window does not open maximized, and so it does not fully utilize the available space in the NetBeans desktop (the area with blue background) - if a component is docked into a window making a split, there is a tab always visible. Since the most common usage of splits is with only one component on one side, this consumes valuable space and does not provide useful information or functionality to the user Here is a proposed default layout on all the workspaces, attached are screenshods of what is described: Editing: - the Explorer is attached to the left - Properties are docked into the Bottom of the Explorer - Editor opens maximized on the desktop - Output window is not by default displayed, when it is forcibly displayed (e.g. compiler error), it opens attached to the bottom side of the desktop. All opened editors survive this without problems (i.e. without the desktop displaying scrollbars), because they are maximized. GUI Editing: Note: IMO, this workspace will become obsolete when the Form Editor components (Inspector, palette, form window) will be merged into one window. - the Explorer is attached to the left - the Component Inspector is docked into the Bottom of the Explorer (the same way Properties are on the Editing workspace) - the Form Window is attached to the Top of the desktop - Editor opens maximized on the desktop - Output window is not by default displayed, when it is forcibly displayed (e.g. compiler error), it opens attached to the bottom side of the desktop. All opened editors survive this without problems (i.e. without the desktop displaying scrollbars), because they are maximized. Browsing: - Object browser is attached to the Top of the desktop - Properties are docked into the Left of the Object Browser - Editor opens maximized on the desktop - Output window is not by default displayed, when it is forcibly displayed (e.g. compiler error), it opens attached to the bottom side of the desktop. All opened editors survive this without problems (i.e. without the desktop displaying scrollbars), because they are maximized. Running: - Execution View is attached to the Right of the desktop - Output Window is attached to the Bottom, and is Dominant - Editor opens maximized on the desktop Debugging: - Debugger View is attached to the Right of the desktop - Output Window is attached to the Bottom, and is Dominant - Editor opens maximized on the desktop
Created attachment 1315 [details] Editing Workspace snapshot
Created attachment 1316 [details] GUIEditing Workspace snapshot
Created attachment 1317 [details] Browsing Workspace snapshot
Created attachment 1318 [details] Running Workspace snapshot
Created attachment 1319 [details] Debugging Workspace snapshot
assigning
Now when XML workspace layout comes to main trunk it is possible to use it to solve this issue. I will change default MDI layout of Editing and Running workspace. I file new issues to Form Editor, Browser and Debugger to change default layout of GUI Editing, Browsing and Debugging workspaces. Problem with absolute bounds should be now solved using relative bounds for modes and areas (area is pane in split container).
Changed in Editing and Running workspace using XML workspace layout.
Resolved for 3.4.x or earlier, no new info since then -> verified.
Resolved for 3.4.x or earlier, no new info since then -> closing.