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 11010 - [MDI] Option to kill "free" desktop area
Summary: [MDI] Option to kill "free" desktop area
Status: CLOSED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: PC Linux
: P1 blocker (vote)
Assignee: mslama
URL:
Keywords: UI
: 9135 13327 14067 (view as bug list)
Depends on: 16174
Blocks: 9135 11870 13327 13717 14219 17504 17829 18282 22874
  Show dependency tree
 
Reported: 2001-04-03 18:54 UTC by Jesse Glick
Modified: 2008-12-23 13:41 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
A patch that adds expert property to IDESettings so that even in MDI mode new windows are opened as separate frames. (6.30 KB, patch)
2001-08-21 15:14 UTC, Jaroslav Tulach
Details | Diff
Netbeans compact, more of the kind of kawa. (29.08 KB, image/gif)
2002-02-07 10:35 UTC, tveimo
Details
patch11010.jar (101.44 KB, application/octet-stream)
2002-02-19 18:51 UTC, mslama
Details
Added line border around maximized frame (101.54 KB, application/octet-stream)
2002-02-21 15:47 UTC, mslama
Details
Screenshot with blue border (74.12 KB, image/gif)
2002-02-21 17:20 UTC, mslama
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2001-04-03 18:54:57 UTC
Request for ability to complete remove the "free" desktop area used in MDI for
random windows not anchored to some side of the screen. In my current MDI
config, there is Explorer (anchored NW), Property Sheet (SW), Output Window
(SE), and then the free area in NE which contains just a "maximized" Editor
window. This works, but all of the widgets for an internal frame are displayed
in the free area, and there is a thick useless border around the Editor window
which looks bad and wastes pixels. Request to be able to anchor Editor to NE in
this case, i.e. completely filling this area just like the other panes do. Then
there would be no free area, so I guess newly opened windows not docked into a
displayed mode would have to become independent frames; which is probably
fine--in such a configuration, if I open Project Settings e.g., it is actually
easier to work with if it is a separate native window. Otherwise it overlaps and
partially hides the Editor and is just more annoying.
Comment 1 Dirk Ruiz 2001-04-04 19:43:07 UTC
This is an interesting proposal.  It seems like the most straightforward way to
present it would be to add an item to the "Attach MDI Frame" pull-right.  The
menu might look like this:

     Left
     Right
     Bottom
     Top
     ----
     Center

Choosing "Center" would force the frame to fill up the entire center area, and
would force other windows to be created as independent windows.  We would have
to warn users who chose "Center" that this would happen!

That said, this makes me nervous.  It would be very easy for an innocent user to
choose "Center", get all the rest of their windows as independent windows, and
then assume that our MDI implementation was just broken.  I would very much like
to post this out on nbui for further discussion!  With your blessing, I will
post your original enhancement request plus this reply.
Comment 2 Jan Chalupa 2001-05-05 20:30:30 UTC
Target milestone -> 3.3
Comment 3 David Simonek 2001-07-11 09:08:57 UTC
*** Issue 13327 has been marked as a duplicate of this issue. ***
Comment 4 Jaroslav Tulach 2001-08-21 15:14:28 UTC
Created attachment 2244 [details]
A patch that adds expert property to IDESettings so that even in MDI mode new windows are opened as separate frames.
Comment 5 emmanuel 2001-09-12 22:57:07 UTC
Seeing as this wastes screen real estate, could it please get a 
higher priority - I mean is it not in similar category to 'line 
number off' as default - to increase screen real estate?
Comment 6 David Simonek 2001-09-13 11:15:21 UTC
Well, there's easy workaround and you'll get almost the same results:
Maximize frame floating in inner desktop and you're all set. No
wasting of screen estate, maybe only two pixels of floating frame
border...
Anyway, raising to P3, but don't expect this to be solved soon - we've
crowd of bugs and it will take several months to fix them :-(
Comment 7 Jan Chalupa 2001-11-27 11:52:19 UTC
Target milestone -> 3.3.1.
Comment 8 Jan Chalupa 2001-11-27 11:56:09 UTC
Target milestone -> 3.3.1.
Comment 9 Jesse Glick 2001-11-27 18:12:32 UTC
I will vote for this myself, mainly on aesthetic grounds: it just
looks wrong to have this floating area. Also other bugs aggravate it,
esp. that the editor window is not correctly set to maximized after
restarting, and occupies some strange position in the free area.
Comment 10 Jan Chalupa 2002-01-11 14:02:42 UTC
Target milestone -> 3.4
Comment 11 Jan Chalupa 2002-01-11 14:06:16 UTC
Target milestone -> 3.4
Comment 12 Jan Chalupa 2002-01-11 14:07:39 UTC
Target milestone -> 3.4
Comment 13 Jan Chalupa 2002-01-11 14:10:49 UTC
Target milestone -> 3.4
Comment 14 Peter Zavadsky 2002-01-29 10:38:36 UTC
*** Issue 14067 has been marked as a duplicate of this issue. ***
Comment 15 David Simonek 2002-01-29 17:27:08 UTC
Evaluation:
This issue is a bit complicated, I will summarize my thoughts:
- most users want to have things like editors using as much space as
possible, so default behaviour should look like there is no inner desktop
- blue thick frame around maximized editor is annoying, must go away
somehow
- layout without inner desktop could be something like more clever
replacement of maximized state of inner desktop as it is today
- newly opened windows should go into MDI area (agree with Dirk),
probably in form of tabs above "editor" area.

We need help and intensive cooperation with UI team here, as this
issue leaves many things untouched:
- how users will switch between windows in "editor" area? Tabs? List
of windows in menu on easily accessible place?
- where new windows will appear? As tabs? Separate? Configurable?
- how will users switch between "effective" and "desktop" mode? Popup
action which will be invoked on desktop or titlebar mouse right-click?
- is this change wise without full implementation of DnD support for
windows?

Comment 16 David Simonek 2002-01-31 16:41:41 UTC
Raising priority, UI team want this.
Question is about future of current desktop. UI team want to remove it
completely and burn the code away.
Ideally, I would like to see it as separate experimental part of IDE,
but more importanr, as experimental (not directly supported) part of
platform (several applications may want to use this approach).
Separate in form of separate jar archive, easily pluggable into
platform or IDE.
Comment 17 tveimo 2002-02-07 10:34:18 UTC
I created an (imaginary) screenshot and posted to a newsgroup some
time ago the way I would prefer netbeans lay out the main windows. See
the attachment.
Comment 18 tveimo 2002-02-07 10:35:17 UTC
Created attachment 4594 [details]
Netbeans compact, more of the kind of kawa.
Comment 19 Jesse Glick 2002-02-07 13:44:02 UTC
Yes, the imaginary screenshot is exactly what I had in mind.
Comment 20 _ jrichard 2002-02-10 19:35:26 UTC
For what it's worth, I like this screenshot too.  But if
this is the setup, there would need to be some way to 
see two files at the same time or quickly navigate between
recently used files.

For that, I'd suggest issue 16799, quick open file navigation needed.

Comment 21 _ ttran 2002-02-19 14:16:51 UTC
*** Issue 9135 has been marked as a duplicate of this issue. ***
Comment 22 mslama 2002-02-19 18:51:15 UTC
Created attachment 4750 [details]
patch11010.jar
Comment 23 mslama 2002-02-19 18:52:56 UTC
Attached prototype of changes suggested by Jano on nbui.

What is there (it is for MDI, dev build at least 19 Feb or newer, put
jar to lib/patches).
1. Title bar and border removed for maximized internal frame.
2. Buttons to control maximized window are added to right side of menu
bar.
3. Main window title contains title of activated frame.

What is not there:
1. List of workspace frames in Window menu
(http://openide.netbeans.org/issues/show_bug.cgi?id=16174)
2. Scrollbars are not disabled in inner desktop.
Comment 24 mslama 2002-02-21 15:47:13 UTC
Created attachment 4774 [details]
Added line border around maximized frame
Comment 25 mslama 2002-02-21 17:20:46 UTC
Created attachment 4775 [details]
Screenshot with blue border
Comment 26 Jesse Glick 2002-02-22 12:32:38 UTC
The blue border looks a little weird here, I think. Notice that the
tab for the form is a few pixels higher than the tabs in the Explorer.
Visually uncomfortable. Otherwise cool.
Comment 27 mslama 2002-04-24 13:45:18 UTC
Command line switch is disabled, new feature is now deafult.
Comment 28 mslama 2002-04-24 13:47:38 UTC
Better say command line switch is removed.
Comment 29 Marian Mirilovic 2002-04-29 09:12:34 UTC
verified in [nb_dev](20020426)

I have filed issues:

P3 issue 22362 - Maximized window's buttons are in the menu bar after
switch MDI -> SDI
P3 issue 22380 - Maximized window's buttons are in the menu bar after
switching projects
P3 issue 22810 - [Windows L&F] Buttons for maximized window aren't
visible after close|reopen

Comment 30 mslama 2002-05-16 16:04:24 UTC
Dependency on task #20223 was removed. It was decided not to touch
PerimeterLayout in this release.
Comment 31 Quality Engineering 2003-07-01 16:27:35 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.