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 44319 - Remember open files when closing a project
Summary: Remember open files when closing a project
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Projects UI (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker with 1 vote (vote)
Assignee: Jiri Rechtacek
: 49380 (view as bug list)
Depends on: 53378 59041 87552 168578
Blocks: 41535
  Show dependency tree
Reported: 2004-06-04 00:31 UTC by David-john Burrowes
Modified: 2012-03-19 23:52 UTC (History)
3 users (show)

See Also:
Exception Reporter:

proposed patch (11.24 KB, patch)
2004-12-04 11:02 UTC, Jiri Rechtacek
Details | Diff
patch to review (15.91 KB, patch)
2004-12-07 14:56 UTC, Jiri Rechtacek
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David-john Burrowes 2004-06-04 00:31:22 UTC
When I close a project, any of its source files
that were open are closed.  Yet, when I reopen the
project they are not reopened.

Not only is it aesthetically desirable to have the
open be the full inverse of the close, but I think
it is actually desirable from a usability
standpoint as well (restore my state to what it
was before I closed the project).
Comment 1 Jesse Glick 2004-09-22 15:30:11 UTC
*** Issue 49380 has been marked as a duplicate of this issue. ***
Comment 2 bht 2004-09-23 01:12:03 UTC
This worked in 3.x. Why is this a bug and future?
Comment 3 Jesse Glick 2004-09-23 04:49:11 UTC
Rather different situation than in NB 3.x. In NB 3.x, the (global
singleton) "project" (if you could call it that) persisted the entire
window system state. NB 4.x has multiple open projects and does not
tie the window system to the project system at all.
Comment 4 bht 2004-09-23 05:21:04 UTC
In the universe of the NetBeans IDE framework, Jesse Glick is most
likely 100% correct. And what he explains is entirely plausible and
easily understood.

However, from a user's perspective, the universe and the logic is

There is a widely held expectation across most industries that the
statuses and the supporting environments of different projects are not
destroyed when the workforce moves from one project to another.

What is the point of having all the gui design from another project
open when the user wants to concentrate his work on a server project?

It could be argued that in 4.0, things work differently, but users's
expectations haven't changed. In that context, and considering that
NetBeans 4.0 is an evolutionary step forward, not a differrent product
line, one can conclude that this is a bug or a design flaw.

If some users want the new 4.0 editor behavior, then this would be
unusual and should preferably, if at all, be enabled only by a setting
whose default is to save editor status in the project's context, not
Comment 5 Jesse Glick 2004-09-23 18:48:18 UTC
Look, this is very simple: closing files part of a project when the
project is closed is easy, and so we did it. Reopening those files
when the project is reopened is a somewhat harder, and will require
some minor format changes, so we didn't do it yet given the number of
more serious things that have to be fixed first. We will later, but
probably not for 4.0. There is no need to argue over design principles
Comment 6 Jesse Glick 2004-12-01 16:36:09 UTC
Possible impl (in projects/projectui?) would use
AuxiliaryConfiguration to store the list in a special section of
private.xml when closing the project, e.g.

<open-files xmlns="">

and then again use AC to read this list (if it exists) when opening a
project. Remember that any new disk format probably deserves a
fast-track review.
Comment 7 Jiri Rechtacek 2004-12-02 15:31:17 UTC
Thanks for hint, I'll use this manner and will track a review before a
possible merge.
Comment 8 Jiri Rechtacek 2004-12-04 11:02:22 UTC
Created attachment 19142 [details]
proposed patch
Comment 9 Jesse Glick 2004-12-04 17:58:26 UTC
1. I would like to see the files added to <open-files> sorted (by
URL), for predictability.

2. URLMapper.findFileObject can return null in case the file no longer
exists, and you must handle this cleanly.

3. Not sure if OpenCookie is what you want. In some cases you want
EditCookie. E.g. if I had a form file open, but only in text mode
(since the form editor is broken and opening the form would cause it
to become modified), I expect that if I close and reopen the project,
I will see the form again in text mode. Also would be nice to keep
caret position. However I think these things cannot be solved
perfectly. Try just looking for EditCookie before OpenCookie, since it
is generally safer - cf. behavior of Open File.

4. DataObject.getCookie(OpenCookie.class) must be instanceof
OpenCookie (or null); there is no need to check this condition. Normal
to write

  OpenCookie c = (OpenCookie) d.getCookie(OpenCookie.class);
  if (c != null) {...}
Comment 10 Jiri Rechtacek 2004-12-07 14:56:37 UTC
Created attachment 19177 [details]
patch to review
Comment 11 Jiri Rechtacek 2004-12-07 15:04:10 UTC
The project/projectui wants to store the files (opened by the project)
when this project is closed. These files will be open in editor when
this project will be re-opened. To store/read this information is done
by AuxiliaryConfiguration tool, writes into the project private
storage area.

Reviews, please could you review the attached patch in
review44319.diff before merge to maintrunk? Thanks
Comment 12 Jiri Rechtacek 2004-12-07 15:05:36 UTC
Reviews, please could you review the attached patch in
review44319.diff before merge to maintrunk? Thanks
Comment 13 _ rkubacki 2004-12-08 09:00:38 UTC
What about the case: open prj, open its file(s), close (& save the
config). Then reopen the project with files, close all these files and
close project. Then reopen again. Should they be opened.

Another question: why do you ask for both Open & Edit cookie. How it
works with form (what will be focused / inited in multiview),
properties, html (will it cause showing in browser?) files.

Of course this RFE is not for free and will slow down project open and
close. Do we have some numbers to know the impact? What about
Comment 14 Jesse Glick 2004-12-08 19:10:51 UTC
To Radim's scenario - so, the files should not be open, because you
closed them. I am not sure what you are asking about here.

I requested use of EditCookie to avoid the case that you open a form
as text, close the proj, reopen proj, and get the form opened as GUI -
since the current form editor will sometimes mark it as modified, etc.
(the OpenCookie is not safe).
Comment 15 _ rkubacki 2004-12-09 09:17:38 UTC
described scenario is just a possible bug in attached patch

re edit vs. open - after discussion with Jirka it seems that prefering
of edit cookie will work well with html (we try edit first and do not
attempt to open it in browser). This is likely OK also for other DOs
providing edit cookie (we went through DOs in current IDE and found
some cases liek URLDO that has edit but does not have any TC for
editing). For .form and .properties it forces use of edit not only for
Jesse's case but for all cases. It means reopened project can show you
different editors but I do not have a big problem with this and yes it
is safer.
Comment 16 Jesse Glick 2004-12-09 16:26:50 UTC
URLDataObject should die. :-)
Comment 17 Jaroslav Tulach 2004-12-10 09:00:52 UTC
Test? It should be easy and the functionality is pretty fragile to be
broken every release.
Comment 18 Jiri Rechtacek 2004-12-10 11:52:15 UTC
Thanks Radim, this bug will be fixed. Ad performance impact) No noted
impact when closing of project with files (same checks has been doing
to close all project-specific files in editor area), open of project
can be slowly if a project with many files is re-opened after IDE
restart, a subject for further improvement.
Ad tests) Yes, the test will be provided ASAP.
Comment 19 Jesse Glick 2004-12-10 16:07:33 UTC
BTW check what actually happens during IDE restart - I forgot to
mention this before. All open projects are "closed" during shutdown
and "opened" during the next start. I guess with the current patch,
you will be completely replacing the persistence of all editor
windows, at least for files owned by projects - which would (ahem)
probably be a good thing from the perspective of reliability, but is
probably not something we want at this point. E.g. caret positions
will be lost, as will multiview tab selections, etc. Perhaps we need
an API change in ProjectOpenedHook to pass a boolean parameter
indicating whether the project is "really" being opened and closed or
whether the IDE is simply being started or shut down with that project
Comment 20 Jiri Rechtacek 2004-12-14 16:45:08 UTC
Thanks for comments and suggestions, have been reflected in
integration this.

The added functionality (store&read to private configuration) is not
called during IDE restart, storing the open files in editor area is
handled by window system, included caret position, edit mode etc.
This functionality works only a project is closed/opened by
CloseProject/OpenProjevct actions.

Ad bug in attached patch) fixed and the fixed is covered by test in
Comment 21 Jiri Rechtacek 2004-12-14 16:46:51 UTC
Checking in arch.xml;
/cvs/projects/projectui/arch.xml,v  <--  arch.xml
new revision: 1.6; previous revision: 1.5
Processing log script arguments...
More commits to come...
Checking in src/org/netbeans/modules/project/ui/;
new revision: 1.10; previous revision: 1.9
Processing log script arguments...
More commits to come...
Checking in src/org/netbeans/modules/project/ui/actions/;
new revision: 1.7; previous revision: 1.6
Processing log script arguments...
More commits to come...
RCS file:
Checking in
 <--  projectui-open-files.xsd
initial revision: 1.1
Processing log script arguments...
More commits to come...
RCS file:
Checking in
initial revision: 1.1
Processing log script arguments...
More commits to come...
Checking in
new revision: 1.2; previous revision: 1.1