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.
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).
*** Issue 49380 has been marked as a duplicate of this issue. ***
This worked in 3.x. Why is this a bug and future?
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.
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 different. 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 global.
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 here.
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="http://www.netbeans.org/ns/projectui-open-files/1"> <file>file:/prj/p1/src/org/foo/Bar.java</file> <file>jar:file:/prj/p1/dist/p1.jar!/META-INF/MANIFEST.MF</file> </open-files> 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.
Thanks for hint, I'll use this manner and will track a review before a possible merge.
Created attachment 19142 [details] proposed patch
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) {...}
Created attachment 19177 [details] patch to review
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
Reviews, please could you review the attached patch in review44319.diff before merge to maintrunk? Thanks
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 responsiveness.
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).
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.
URLDataObject should die. :-)
Test? It should be easy and the functionality is pretty fragile to be broken every release.
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.
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 open?
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 ProjectUtilitiesTest.
Checking in arch.xml; /cvs/projects/projectui/arch.xml,v <-- arch.xml new revision: 1.6; previous revision: 1.5 done Processing log script arguments... More commits to come... Checking in src/org/netbeans/modules/project/ui/ProjectUtilities.java; /cvs/projects/projectui/src/org/netbeans/modules/project/ui/ProjectUtilities.java,v <-- ProjectUtilities.java new revision: 1.10; previous revision: 1.9 done Processing log script arguments... More commits to come... Checking in src/org/netbeans/modules/project/ui/actions/OpenProject.java; /cvs/projects/projectui/src/org/netbeans/modules/project/ui/actions/OpenProject.java,v <-- OpenProject.java new revision: 1.7; previous revision: 1.6 done Processing log script arguments... More commits to come... RCS file: /cvs/projects/projectui/src/org/netbeans/modules/project/ui/resources/projectui-open-files.xsd,v done Checking in src/org/netbeans/modules/project/ui/resources/projectui-open-files.xsd; /cvs/projects/projectui/src/org/netbeans/modules/project/ui/resources/projectui-open-files.xsd,v <-- projectui-open-files.xsd initial revision: 1.1 done Processing log script arguments... More commits to come... RCS file: /cvs/projects/projectui/test/unit/src/org/netbeans/modules/project/ui/ProjectUtilitiesTest.java,v done Checking in test/unit/src/org/netbeans/modules/project/ui/ProjectUtilitiesTest.java; /cvs/projects/projectui/test/unit/src/org/netbeans/modules/project/ui/ProjectUtilitiesTest.java,v <-- ProjectUtilitiesTest.java initial revision: 1.1 done Processing log script arguments... More commits to come... Checking in test/unit/src/org/netbeans/modules/project/ui/actions/TestSupport.java; /cvs/projects/projectui/test/unit/src/org/netbeans/modules/project/ui/actions/TestSupport.java,v <-- TestSupport.java new revision: 1.2; previous revision: 1.1 done