Hi Serge and James,
When I understood Serge right, the extension point would allow
adding new filter types, whereas the dialog would allow
instantiating those filter types with specific parameters,
right? -- For Reference, the JSR 203 DirectoryStream /
DirectoryFilter goes in this direction on the file system
level, allowing to not even bother looking at directory
entries for items filtered away [1]
I find especially the newContentTypeFilter [2] interesting,
which apparently requires that the file system layer already
has some concept of content types -- something we don't have
in EFS just yet. Given that determining a content type may
be pretty hard and might require actually opening the file
in question, I'm not even sure if it is a good idea to have
the concept of content types at this level. But, if the
actual underlying file system already supports content types,
this is of course a very powerful concept.
BTW, in terms of integration with the underlying CM system,
it would be very interesting to have a Resource Filter which
returns only those directory entries that are actually
managed by the CM system. I'm quite sure that this would
solve a large class of filtering problems, having to provide
the information only once (.cvsignore file, for instance).
Of course, the lifecycle would need some consideration (what
happens when adding a new file that's not yet under team
support... is it visible?), But it's worth a thought.
[1]
http://openjdk.java.net/projects/nio/javadoc/java/nio/file/Path.html#new
DirectoryStream(java.nio.file.DirectoryStream.Filter)
[2]
http://openjdk.java.net/projects/nio/javadoc/java/nio/file/DirectoryStre
amFilters.html#newContentTypeFilter(java.lang.String)
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
-----Original Message-----
From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
[mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On
Behalf Of Serge Beauchamp
Sent: Friday, October 17, 2008 6:57 PM
To: E4 developer list
Subject: Re: [eclipse-incubator-e4-dev] [resources] Resource
Folder filters
Hi James,
James Blackburn wrote:
Hi Serge,
Isn't this just going to be a less flexible bottom-up
reimplementation
of your groups + linked resources work? Do you expect user
to change
filters on the fly, or are they only set via your filters extension
point?
My opinion is that the Linked resources, groups, independent
paths and
resource filters are complementary mechanism.
Groups and Linked Resources allows the user to setup the project
structure by explicitly including files, while the resource filters
allows setting up the project structure by excluding files
and folders
from a larger subset.
Both approach should be fully supported, in my opinion, as
one is more
practical for some case than the other.
For example, if the user has a directory with 40 .c files,
and only 20
should be included, it would be a hassle to attempt to build a filter
set for those 20 files, while they can be simply drag and dropped as
linked resources.
While if the user has a directory with 1000 files in many sub
directories, and only 20 .c files should be included, putting an
"inherited" filter on the top directory is a convenient way
to build the
project structure.
Given a choice of both, I'd say VS style groups and linked resources
seem the way forward. To me it seems better to allow users to
fleixibly pull resources in as they see fit, rather than exclude
resources at the outset. What happens, for example, if a
user were to
accidentally change the filter to *.* would they lose metadata on
existing resources in the workspace?
Doug has mentioned CCRC, and maybe that's the right approach for
adding resources from EFS filesystems. A user could change to a
Filesystem browser perspective -- much like repository exploring --
and choose to pull in linked resources / groups into their workspace
as they see fit. Filters could then be implemented at the link /
group creation stage. The user could enter some set of expressions
for files / folders to filter and the creation dialog could
show them
a preview of the tree that will be created in the
Workspace. What do
you think?
I'm not familiar with CCRC, but I'd be curious to lean more about it,
can you point to some example?
Is the FileSystem browser perspective similar to having
Windows Explorer
in one window and the Eclipse package explorer in another and using
existing drag and drop operations?
Cheers,
James
On Fri, Oct 17, 2008 at 4:51 PM, Serge Beauchamp
<serge@xxxxxxxxxxxxx> wrote:
Hi all,
We're working on a "Resource Folder Filter" feature that,
a little bit like
Visual Studio does, allows to control which files and
folders are picked up
when a refresh is performed in the workspace on a folder.
The Resource Folder Filter works very simply by the
ability to set a list of
filters (which can be extended with a core resource
extension point) on a
IFolder, whether it is a standard folder or linked
resource, and the option
to make it "inherited", in which cases it applies to all
its children
folders.
A filter can be defined to either "include only" or
"exclude all" files and
folders matching a given criteria
A default filter is available that allows the user to
specify an "include
only" filter that match a string pattern, such as "*.c;*.h".
This feature will allow significant performance and
scalability improvement
for users having a large file system tree, as as opposed to hidden
resources, filtered files and folders are not created in
the resource tree,
so don't consume needlessly resources.
Let me know what you guys think, thanks!
Serge Beauchamp.
Software Engineer
Freescale Semiconductor
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
