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
From: John Arthorne/Ottawa/IBM@IBMCA
To: "Eclipse platform general developers list."
<[email protected]>,
Date: 06/27/2013 11:11 PM
Subject: Re: [platform-dev] Should closed project behave like folders?
Sent by: [email protected]
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
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ platform-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/platform-dev
