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 12003 - The default windows layout in MDI does not fully utilize the abilities of MDI
Summary: The default windows layout in MDI does not fully utilize the abilities of MDI
Status: CLOSED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: PC All
: P2 blocker (vote)
Assignee: mslama
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-05-07 18:57 UTC by iformanek
Modified: 2008-12-22 23:51 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
Editing Workspace snapshot (32.85 KB, image/gif)
2001-07-20 20:46 UTC, iformanek
Details
GUIEditing Workspace snapshot (44.79 KB, image/gif)
2001-07-20 20:46 UTC, iformanek
Details
Browsing Workspace snapshot (35.90 KB, image/gif)
2001-07-20 20:46 UTC, iformanek
Details
Running Workspace snapshot (25.69 KB, image/gif)
2001-07-20 20:46 UTC, iformanek
Details
Debugging Workspace snapshot (24.56 KB, image/gif)
2001-07-20 20:46 UTC, iformanek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description iformanek 2001-05-07 18:57:21 UTC
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
Comment 1 iformanek 2001-05-07 18:58:24 UTC
Created attachment 1315 [details]
Editing Workspace snapshot
Comment 2 iformanek 2001-05-07 18:59:08 UTC
Created attachment 1316 [details]
GUIEditing Workspace snapshot
Comment 3 iformanek 2001-05-07 18:59:43 UTC
Created attachment 1317 [details]
Browsing Workspace snapshot
Comment 4 iformanek 2001-05-07 19:00:16 UTC
Created attachment 1318 [details]
Running Workspace snapshot
Comment 5 iformanek 2001-05-07 19:00:45 UTC
Created attachment 1319 [details]
Debugging Workspace snapshot
Comment 6 Jan Zajicek 2001-05-08 10:52:48 UTC
assigning
Comment 7 mslama 2001-08-23 10:08:39 UTC
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).
 
Comment 8 mslama 2001-09-04 14:38:38 UTC
Changed in Editing and Running workspace using XML workspace layout.
Comment 9 Quality Engineering 2003-07-01 16:00:52 UTC
Resolved for 3.4.x or earlier, no new info since then -> verified.

Comment 10 Quality Engineering 2003-07-01 16:29:00 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.