Community
Participate
Working Groups
For example: I have a deep folder hierarchy on my file system (say, "c:\foo") in that hierarchy, there's a large set of files, for example: c:\foo\file1.c c:\foo\dir\file2.c c:\foo\dir\sub_dir\file3.c So when I create a linked folder in my project, pointing to "C:\foo", with the new resource filter feature, I can make sure that only the .c files are part of the workspace tree. But that I would like, is that the not only the .c files are visible, but also that the hierarchy is collapsed (or perhaps partially collapsed). So that in my workspace, instead of seeing, after refreshing 'foo': project1/ foo/file1.c foo/dir/file2.c foo/dir/sub_dir/file3.c I would see instead: foo/file1.c foo/file2.c foo/file3.c Where all .c files would be linked resources pointing to their respective files, that would have been generated automatically on the refresh action. Note also that duplicated file names would have to be handled by having a different name for the linked resource file than the underlying file system name (something already supported). This feature could be used to setup a 'CVS watch folder', in the project, for example, where the linked folder would display automatically as its children the list of CVS files that are new or modified.
For this feature to work, we would need a new kind of resource (or at least, new kind of rules for a linked resource type). We have currently two types of resources, that have different rules: 1) Normal Resource a) The parent resource point to the underlying file system entry's parent directory. b) The resource is automatically generated by its parent refresh operation c) Deleting/renaming/moving the resource causes the same operation to be done on the underlying file system entry. d) The resource name is the same as the file system entry's name 2) Linked Resource a) The parent resource does NOT have to point to the underlying file system entry's parent directory. b) The resource is NOT automatically generated by its parent refresh operation, but created explicitely c) Deleting/renaming/moving the resource does NOT cause the same operation to be done on the underlying file system entry. d) The resource name does NOT have to be the same as the file system entry's name e) An icon overlay distinguish linked resources visually to the user. For this feature, we would need another type of resource, lets call it the "Floating Resource". A floating resource is the same as a normal resource, EXCEPT that its parent does not have to point to the underlying file system entry's parent directory. Because of this important difference, to keep it API compatible, it would have to be seen as an linked resource by clients (isLinked() == true), so they the getLocation() is not assumed to be the same as "getParent().getLocation() + getName()". So the "Floating Resource" attributes would be the following: 3) Floating resource a) The parent resource does NOT have to point to the underlying file system entry's parent directory. (same as 2a) b) The resource IS automatically generated by its parent refresh operation (same as 1b) c) Deleting/renaming/moving the resource DOES cause the same operation to be done on the underlying file system entry. (same as 1c) d) The resource name does NOT have to be the same as the file system entry's name (same as 2d) e) Either a different icon overlay distinguish floating resources visually to the user than linked resources, or they have the same appearance as normal resources. So we see that the Floating Resource is really a mix of half of a normal resource, and half of a linked resource's attributes.
The way I envision for the user to create 'floating resources', i.e. to flatten a folder hierarchy, is that the resource property page would have a 'Display as a flat hierarchy' checkbox (both for normal and linked folders), so that the user would simply have to check it, for the underlying hierarchy to be collapsed in one level.
Created attachment 178553 [details] First Draft Implementation Done: - Now possible to set a folder as "flatten" hierarchy in the resource property page. - Floating resources are automatically created under flatten folders. - Decorators for floating resources. - Refresh / update mechanism. - Resource filters work transparently on a flatten folders. Remains to be done: - Decorator for the flatten folders. - Move/Copy/Delete semantics (akin normal resources, instead of linked resources) - Updating documentation
Created attachment 178554 [details] Shows how floating resources look like with the decorator
Created attachment 178561 [details] First Draft Implementation (the first patch was missing some files)
I assume you have already considered this, but couldn't this also be implemented as a display/UI feature rather than flattened within the resource model itself? For example both the Package Explorer and Synchronize views today have some variant of a "flat" or "collapsed" presentation that is done purely within the view. Is it just that the user wants to view it as a flat list, or that you actually want it to behave like a flat list when manipulated programmatically? Second, would a "floating" folder be limited to only containing files that are in the sub-tree on disk? Since the mapping from resources to disk is being cut here, it seems the floating folder could actually contain contents from anywhere, rather than being restricted to the subtree on disk. Flattening seems like a specific example of a more generic feature - where a folder's contents are defined by some query/search rather than by the file system structure. The problem of automatically renaming conflicting file names bothers me. I'm not sure how we would define those renamings, and how it would be managed. For example say there are three "a.c" files, and you called the resources "a.c", "a_2.c", and "a_3.c". Now say "a.c" is deleted - do you rename the other two resources or leave them alone? How does the user figure out which is which?
(In reply to comment #6) > I assume you have already considered this, but couldn't this also be > implemented as a display/UI feature rather than flattened within the resource > model itself? For example both the Package Explorer and Synchronize views today > have some variant of a "flat" or "collapsed" presentation that is done purely > within the view. Is it just that the user wants to view it as a flat list, or > that you actually want it to behave like a flat list when manipulated > programmatically? > Yes, creating 'visual' hierarchies in the navigator views is something that is already possible, especially when using the common navigator framework. The Flatten/Floating resources allows, as you mention, the underlying resource tree to be specified in a new way, which is then consistently visible from any API client. > Second, would a "floating" folder be limited to only containing files that are > in the sub-tree on disk? Since the mapping from resources to disk is being cut > here, it seems the floating folder could actually contain contents from > anywhere, rather than being restricted to the subtree on disk. Flattening seems > like a specific example of a more generic feature - where a folder's contents > are defined by some query/search rather than by the file system structure. > The user can create a linked folder that points to anywhere in the file system, and flag it as 'flatten', this works already with this patch. I believe this covers the user case you are describing. The content of flatten folders is not limited to floating resources (files), since the user can all linked resources (files and folders) under a flatten folder, which in turn can be flatten (or not), and so on. The main advantage of flatten/floating resources, is that they build linked resources (style) dynamically from the refresh operation. This is especially powerful when resource filters are set on the flatten folders. So the user can build a rich, dynamic structure that maps to arbitrary locations on the file system, and that update itself automatically when the file system changes, based on customizable criteria. > The problem of automatically renaming conflicting file names bothers me. I'm > not sure how we would define those renamings, and how it would be managed. For > example say there are three "a.c" files, and you called the resources "a.c", > "a_2.c", and "a_3.c". Now say "a.c" is deleted - do you rename the other two > resources or leave them alone? How does the user figure out which is which? Right now, how the conflict is handled, is that the name of the conflicting floating files are dynamically generated to unique names. Keep in mind that the floating files are internally linked resources, so the name of the resources can be different than the underlying file system file name. The algorithm currently changes the name by appending the parent directory of the conflicting file name. For example, say I have: flatten_folder/ file.c dir/ file.c foo/ file.c bar/ sub/ file.c it will currently appear in the workspace as follows: flatten_folder/ file.c file.c (dir) file.c (foo) file.c (bar-sub) I'm not sure that the renaming is ideal yet, I'm sure there's something we can come up with that is better, but the general idea is that this mechanism resolves the name conflicts in a way that let the user knows which file points to where. About renaming, I think the best is probably to leave the other files as-is, and only change their names according to conflict resolution when the parent folder is refreshed. The semantic of floating files is more like a normal file anyhow (they are not shown to the user as linked resources), so the UI would have to be change to handle renaming floating resources properly (by renaming the target, not only the resource) - same for move/copy/delete.
setting milestone target
Serge, I remember we were talking about fixing it in M5. Since we are past M5, do you plan to address it during M6?
Realistically, this won't make it in 3.7
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
