Re: [platform-dev] Should closed project behave like folders?

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

I've been following this thread with interest myself...as John points out there are multiple consequences of closing a project so perhaps talking about how to 'partially close' a project simply leads to a protracted conversation about what 'partially' means.

If this is more about gaining access to *files* within a closed project perhaps something as simple as an 'Open File...' command that uses the standard dialog but sets its default search location to be the project's folder might suffice.

Just my two nickels worth (Canada doesn't have cents anymore...;-),
Eric


John Arthorne---06/27/2013 11:11:05 PM---This is an interesting idea and there has been some good discussion in  this thread. Overall I think

From:	John Arthorne/Ottawa/IBM@IBMCA
To:	"Eclipse platform general developers list." <platform-dev@xxxxxxxxxxx>,
Date:	06/27/2013 11:11 PM
Subject:	Re: [platform-dev] Should closed project behave like folders?
Sent by:	platform-dev-bounces@xxxxxxxxxxx

---

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 <mistria@xxxxxxxxxx> 
To:        platform-dev@xxxxxxxxxxx, 
Date:        06/27/2013 10:33 AM 
Subject:        [platform-dev] Should closed project behave like folders? 
Sent by:        platform-dev-bounces@xxxxxxxxxxx

---

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
platform-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-dev