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 36843 - Output Window isn't persistent after restart
Summary: Output Window isn't persistent after restart
Status: CLOSED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: All All
: P4 blocker (vote)
Assignee: jrojcek
URL:
Keywords:
: 41534 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-10-27 11:45 UTC by Marian Mirilovic
Modified: 2009-12-03 03:24 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marian Mirilovic 2003-10-27 11:45:03 UTC
[nb winsys](031024), [jdk1.4.2_02]

Steps to reproduce:
- run IDE
- create new java file HelloWorld
- run it in debugger
-> tabs Debugger Console and Process Output are
shown in the Output Window
- restart IDE
-> Output window is empty !

This is in conflict with UI specification :
http://ui.netbeans.org/docs/ui/ws/ws_spec.html#3.2
-----------
#  Persistence - a closed window keeps the content
(an expanded tree, compiler output) and displays
it when it is open again. It means closing of a
window doesn't dismiss a displayed object (neither
output). Same should be true when the IDE is
finished and started again.
-----------
Comment 1 Peter Zavadsky 2003-10-27 13:47:18 UTC
Well, I guess Jano told once, the individual tabs shouldn't be persistent.
Assignign there to get the statement.
Comment 2 jrojcek 2003-10-29 13:26:27 UTC
All the windows should persist their contents. Even the output window.
But this is not a high priority issue.
Comment 3 mslama 2003-10-29 13:36:13 UTC
Jano are you sure content of output tabs should be persistent? I do
not think so. It looks like session specific. Process Output for
example contains output of some process probably started from IDE but
after IDE restart process is lost process is not restarted. If it
should be persistent content is handled by inner component - terminal
emulator in this case. I do not think it has/had such functionality.
Anyway so far it was NOT persistent.
Comment 4 Peter Zavadsky 2003-10-31 14:08:03 UTC
Again passing to Jano, to get his comment.
Comment 5 jrojcek 2003-11-05 13:24:06 UTC
The result of discussion between HIEs is that all windows should be
persisted (in ideal state). Please, provide an analysis of how it
would affect performance if we implement it.
Comment 6 _ ttran 2003-11-28 15:35:57 UTC
Jano,

it seems you are too academic here.  If the window shows a content
which by its nature is transient I don't think we should save/restore
it.  In many cases it's even impossible.

I do agree that from pure UI point of view, the session should be
restored with everything but the fact of life is it's not always
possible or even desirable.  Let's say the user is exiting the IDE in
the middle of the debugging session.  Does she expect the IDE to
restore everything including the process which was debugged back to
the exact state where it was yesterday?  I don't think so

I think the UI spec must be corrected to specifically address the
situation when the UI visualize information about running processes.
Comment 7 jrojcek 2004-01-17 15:51:14 UTC
Okay, I will update the spec. The output tabs won't be persisted, even though I still 
think they should be.

Decreasing priority, as the spec is affected.

Sidenote:
My opinion is that each application should always remember as much of its state as it 
is technically possible. Our IDE has a few windows containing data that can be marked 
as "transient" - search results, todo list, VCS output, output, in the future it would be 
the refactoring window. I think it is correct if all of those windows were persisted.
Comment 8 Marian Mirilovic 2004-03-31 13:02:55 UTC
*** Issue 41534 has been marked as a duplicate of this issue. ***
Comment 9 Marian Mirilovic 2004-06-14 13:59:26 UTC
re-evaluate please ...
Comment 10 jrojcek 2005-03-18 15:33:14 UTC
Lowering priority. The user impact isn't big in this case. I will reevaluate if this is really needed (or 
worth the effort).
Comment 11 Jesse Glick 2009-10-20 16:47:56 UTC
I don't believe we have any plans to do this.
Comment 12 Marian Mirilovic 2009-12-03 03:24:14 UTC
v/c