Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-incubator-e4-dev] [resources] Resource Folder filters

Oberhuber, Martin wrote:
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]
This is correct, the extension point allows plugins to add new filter types, which the user can then instantiate on a folder of his choice, along with optional arguments.

The DirectoryStream.Filter could be a way to improve the efficiency of the Resource filter implementation as well, if Eclipse ever moves to the latest JDK :)

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.

It's an interesting idea, and I think that with the extension mechanism, any type of filters, including one that works on the content type of the file could be implemented by plugins, the performance issue can always be resolved by the user deciding to use the filter or not.

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.



Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
-----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
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

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?



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
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 mailing list
eclipse-incubator-e4-dev mailing list

eclipse-incubator-e4-dev mailing list

Back to the top