[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-incubator-e4-dev] [resources] Resource Folder filters
|
Hi, James,
James Blackburn wrote:
Hi Serge and Martin,
You both raise interesting points! I think you're right and agree
exclusions are complementary to links.
A couple quick points. I noticed over the weekend that on the
"Resource Exclusion Filters" bug
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=84988) JohnA states in
comment 16 that exclusion filters are supported in the current
platform -- albeit in a roundabout way:
" You can create an exclusion filter in I20060110 by creating a linked resource
to the "null" file system. The linked resource will hide any file system
resource with the same name, thus acting as an exclusion mechanism."
Well, it may hide any file system resource of the same name, but you
will need to have a linked resource for it, so a resource will still be
visible in the workspace, although it will point to nowhere :)
So it kinda defeats the purpose of being able to exclude resources from
the resource tree.
Now I find this really interesting because I think the two features --
enhancing linked resources & groups, and these exclusion filters --
are two sides of the same linked resources / alias management coin.
Given that these exclusions are implemented on top of linked
resources, if bugs / performance are fixed / improved in one, the
other benefits for free!
I see problems with using the existing linked resources implementation:
Sharing:
As Martin said team sharing a large .project file will become more
of a problem. I have a project with 85 linked resources which is 17k
of text. It's certainly very important that a team can share a
project built like this especially for large projects coming from
flexible VS style projects.
Performance:
Serge if I use your linked resources feature to it's full and create a
completely virtual project entirely of groups and linked files, the
.project file might be full of thousands of items.
A simple optimisation might be to say:
Include this tree <some_tree_location_root>, virtually.
Exclude:
these subtrees and resources: x, y, x
resources matching this filter: *.jpg
The virtual flag would tell Eclipse to build the tree from the given
filesystem location as 'linked resources' and 'groups'. Deleting
files or groups would result in an additional 'exclusion' (or deletion
of the actual resources if the user chose to do so).
You are right, only using inclusive operations - with linked resources -
instead of filters tend to create large .project files, and it is more
efficient (if fine grained inclusion is not required) to use resource
filters. Although the drawback with resource filters is that it can be
hard to specify filters in such a way that a heterogeneous set of files
is included and another heterogeneous set is excluded from the same file
system hierarchy (for example, specifying a set of filters to include
"foo.c", "abc.h" and "dfg.c" but exclude "foo.h", "abc.c" and "dgh.h"
can be a pain), hence I believe both mechanism are complementary,
Resource filters and linked resources can also be used at the same time,
where the project can contain different folder linked resources
(specified using variable relative paths) which in turn have resource
filters applied on them. Also, normal folder resources that have a
filter applied to can also contain linked resource, which pass through
the filter, since it applies at the EFS (file system) layer only. This
can help a lot where a single file would normally be excluded based on
the filters but should still be included for some reason.
To perform what you are suggesting, if I understand correctly, the user
can already do it with the 'group and independent path' patch by drag
and dropping files and folders from Windows Explorer, opting to create
groups and linked resources, and after manually removing the unwanted
linked resources that were created automatically.
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?
Yes, that's right. So you could imagine a Navigator style view which
shows the complete tree of EFS resources provided (they're not real
Eclipse IResources - no metadata, no delta notification). From this
view the user can choose to create / import projects, as well as trees
of resources into existing projects. When a resource is added to the
workspace it becomes managed by Eclipse. So effectively a Windows
Explorer that speaks EFS.
Cheers,
James
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
