This is an interesting idea and there has been some good discussion in this thread. Overall I think there are many possible reasons for closing a project, and disabling builds is just one of them. There is an overall performance benefit to closing projects. The entire metadata for that project and its children is flushed to disk and removed from memory. Any listener or resource traversal will never see that subtree, which speeds up many operations such as search, open resource, etc. It also removes visual clutter from various views, although there are other mechanisms such as working sets to accomplish that.
If I understand correctly, your suggestion narrows the definition of close project to mean it only disabling builds. Although it is a bit hidden and less convenient, there is already a mechanism for disabling builds if you select a project and go to File > Properties > Builders. The consequence here is that if resources in the project can continue changing, incremental builds are broken when disabled and will require a full rebuild when re-enabled. Depending on the cost of a full build this can remove any advantage to disabling it in the first place. It sounds like the main use case is making it easier to open a file for editing that is not in your current workspace. I usually do this by opening a file system browser from the OS and drag the file into the Eclipse editor area. Maybe there is something else we can do to make this more convenient. Maybe for example a different variant of "Open Resource" that will search well known external locations such as closed projects, recently edited external files, etc? John From: Mickael Istria <[email protected]> To: [email protected], Date: 06/27/2013 10:33 AM Subject: [platform-dev] Should closed project behave like folders? Sent by: [email protected] Hi all, I've been thinking about some possible usability improvements in the platform that would make daily usage easier. As part of this brainstorming, I wondered why do we (Eclipse users) have to close or open projects everytime? In my case, and probably in most cases, I close a project to avoid extra-actions to happen (validation and build) in order to keep a good reactivity in IDE. However, whenever they want to change a simple file -let's say a pom.xml- , they need to open the project, then a build start and Eclipse can slow down or lag because of heavy operations, which are not always necessary in order to make a simple edit. In some cases, I think it would be convenient to have the ability to edit a file in Eclipse without opening a project. To do so, I'm proposing the following approach: a closed project should behave like a folder. It would simply list its content (file and folders, no container) so it would be possible to make simple editions, but no build, no validation, no smart thing would occur. The only drawback I see is that the "Show Resources" wizard would contain a lot of things, but anyway, it always contains a lot of things so I don't see that as a serious drawback. Thoughts? -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets_______________________________________________ platform-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________ platform-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/platform-dev
