Community
Participate
Working Groups
Merge Groups UI from the e4 branch to HEAD.
What's the "group UI" and what's the benefit for Eclipse SDK? Shouldn't this bug be in the UI component?
(In reply to comment #1) > What's the "group UI" and what's the benefit for Eclipse SDK? Groups are folders that exist only in the resource tree and allow to organize linked resources in more flexible way. Groups can contain other groups or linked resources and are not backed in EFS. For more details see Bug 229633. > Shouldn't this bug be in the UI component? Right. This was my intention. Thanks.
(In reply to comment #2) Groups UI are groups decorator for resource navigators, some changes to resources wizards, etc.
>Groups UI are groups decorator Only decorators? No new elements in the tree?
(In reply to comment #4) > >Groups UI are groups decorator > Only decorators? No new elements in the tree? No. Groups are IFolder objects not backed by EFS elements. Groups have also some specific constraints i.e. they can contain only other groups or linked resources.
Created attachment 150507 [details] Group UI patch Group UI patch merge (without the Project Path Variable Changes
Adding Francis Upton, since this path contains (small) changes to the o.e.ui.navigator.resources plugin.
Created attachment 152570 [details] Updated patch to the latest cvs sources Updated patch to the latest cvs sources
Some comments: - The patch contains an unrelated change to ICoreConstant class in core.resources - Thumbs.db files :-) - I would create a separate decorator for groups (right now linked resources and groups use the same one) - I tried to copy a file to a group. This causes an exception. - UI designer needs to prepare icons for us, however I think that an overlay would be better to indicate Group (I will raise a bug for this, when the code is released) - what are changes to ConfigurationLogUpdateSection? - how can I trigger ImportTypeDialog? Shouldn't there be a separate bug for it? - I still see some dynamic variables API in the patch, e.g. AbstractCopyOrMoveResourcesOperation#setRelativeVariable. I would get rid of it, just to keep this patch clear and as small as possible. I assume that some UI guys will be looking at it and this would make their life easier.
(In reply to comment #9) > Some comments: > - The patch contains an unrelated change to ICoreConstant class in > core.resources > - Thumbs.db files :-) Gah, sorry about that, I must have done it 10 times and forgot for the last one. > - I would create a separate decorator for groups (right now linked resources > and groups use the same one) I'm not sure to follow, you mean (as below) using a decorator to indicate a group? > - I tried to copy a file to a group. This causes an exception. It gives an exception only if you are using the JDT package explorer. If you are using the Project Explorer, it transparently creates a linked resource. The JDT package explorer needs fixing to make it use the ui.navigator drop target handlers. > - UI designer needs to prepare icons for us, however I think that an overlay > would be better to indicate Group (I will raise a bug for this, when the code > is released) I guess this relates to the question of groups being just a kind of folders, or being a first class object. In my perspective, things that are presented as overlays, indicate an transient, temporary, or abnormal state, or an attribute of the object ('tracked' by CVS, 'new in repository', etc...) as opposed to its fundamental nature. For example, warnings and error markers are shown with an overlay. For that reason, I always think that having an overlay for linked resources give the impression to the user that normal resources are not linked, and linked resources are unusual. Having a tree full of linked resources somewhat pollutes the tree with tons of overlays. So with the group being an overlay as well, it would do the same thing, instead of being a first class object that the user can create project hierarchies with. What do you think? > - what are changes to ConfigurationLogUpdateSection? I though I removed it from the patch. Anyhow, it should be discarded. > - how can I trigger ImportTypeDialog? Shouldn't there be a separate bug for it? You can use it by drag and dropping files from windows explorer in a project in the Project Explorer, for example (it doesn't work with the JDT package explorer yet). > - I still see some dynamic variables API in the patch, e.g. > AbstractCopyOrMoveResourcesOperation#setRelativeVariable. I would get rid of > it, just to keep this patch clear and as small as possible. I assume that some > UI guys will be looking at it and this would make their life easier. Ok, sure, I'll make the change.
Created attachment 152582 [details] Latest changes Latest changes, removing a reference to setRelativeVariable()
Created attachment 152583 [details] Again, same patch, but hopefully without the unwanted files.
(In reply to comment #12) > Created an attachment (id=152583) [details] > Again, same patch, but hopefully without the unwanted files. So it worked this time. What I was doing to remove the files from the patch, is that I was selected 'remove from view'. Apparently, that works for commits, but not for patches. I had to uncheck the file instead.
CCing our UI design guru to get an "outside" perspective on this. Susan, we have this new "group" concept that is like a folder but doesn't exist anywhere in the file system. It's just used as a logical container for other resources (conceptually a bit like a working set). They can appear anywhere in the Eclipse resource tree where files and folders can appear today. The question is whether we should display this as a folder icon with a decoration, or as a different icon. There are related questions, such as whether it should just be a checkbox option in the "New Folder" wizard or a different wizard, but the general form of the question is: "should we present this to the user as a special kind of folder, or as a conceptually different entity? I could go either way, but my feeling is that groups are sufficiently different from folders that a different icon is better than an overlay. From an implementation standpoint they are just a special kind of folder, but I'm not sure that an end user would see it that way.
(In reply to comment #14) > I could go either way, but my feeling is that groups are sufficiently different > from folders that a different icon is better than an overlay. From an > implementation standpoint they are just a special kind of folder, but I'm not > sure that an end user would see it that way. 1. Personally I don't think we need to introduce Group name/concept, since this may confuse users. For me Groups are just Folders but Folders are backed in a filesystem. We already have deprecated concept of non-local folders and files and Groups are for me just like these non-local resources. 2. We already discussed that switching a resource from Group to Folder may be possible. So for me it means that being backed in filesystem is an attribute of Folder. The same kind of attribute as Linked Folder. Since being Link Folder is indicated by an overlay, it seams that being Group should be indicated in the same way. 3. Couldn't we have the decoration configurable? By default we could have a slightly changed icon for Groups. However one could configure to use a regular icon and overlay to indicate the kind of Folder. 4. AFAIK wizard pages for creating folders can be extended by others and if we just use one wizard for regular Folders and Groups, consumers of this wizard page will get Groups for free.
(In reply to comment #15) > (In reply to comment #14) > > I could go either way, but my feeling is that groups are sufficiently different > > from folders that a different icon is better than an overlay. From an > > implementation standpoint they are just a special kind of folder, but I'm not > > sure that an end user would see it that way. > > 1. Personally I don't think we need to introduce Group name/concept, since this > may confuse users. For me Groups are just Folders but Folders are backed in a > filesystem. We already have deprecated concept of non-local folders and files > and Groups are for me just like these non-local resources. > > 2. We already discussed that switching a resource from Group to Folder may be > possible. So for me it means that being backed in filesystem is an attribute of > Folder. The same kind of attribute as Linked Folder. Since being Link Folder is > indicated by an overlay, it seams that being Group should be indicated in the > same way. > > 3. Couldn't we have the decoration configurable? By default we could have a > slightly changed icon for Groups. However one could configure to use a regular > icon and overlay to indicate the kind of Folder. > > 4. AFAIK wizard pages for creating folders can be extended by others and if we > just use one wizard for regular Folders and Groups, consumers of this wizard > page will get Groups for free. To illustrate my argument that groups should be seen as different UI objects than folders, is that the rules for building hierarchies with groups are different than folders. For instance: Under a folder, you can create: Folder, files, linked resources, groups. Under a group, you can only create: linked resources, groups. Folders and linked resources have a 'location' property. Groups don't. (the API always returns null). You can move a group under a folder. You can't move a folder under a group (it creates a linked resources automatically with 'group aware' explorers). You can copy a group under a folder You can't copy a folder under a group. You can set filters on a folder or linked resource folder. You can set filters on a group, but it will make sense only if the filter is set to inheritable, and affect only sub-folder or linked resources that happens to have that group as a parent. You can have aliases on a folder (linked resources that point to a folder) You can't have aliases on a group. I feel like having the UI communicate to the user that a group is just a kind of group, mislead him into thinking that groups behaves like folders. Fundamentally, actually, it's the opposite: a folders is a kind of group, not the other way around, and the folder properties are a super-set of the group's property. You could display the class hierarchy as follows: group: name parent children-list linked folder: extends group -location - children-list can be automatically populated by the location's file system children. folder: extends 'linked folder' - parent needs to have a 'location' property -location is read-only, set to the parent.location/this.name
(In reply to comment #16) I'm not so attached to the name Group. For me they are all folders because looking at API, you create a folder. The differences are that some are backed in a filesystem, some are not. And I agree that a folder not backed in a filesystem is a more general concept than a regular folder. Of course there are some limitation for folders not backed in fs, however people are aware of that even without calling in Group. If Groups (or folders not backed in fs) are decorated properly and context menus don't allow to perform invalid actions, we are fine. My opinion is that what we should communicate to users is that Folder is a wider concept now and you can create a folder that is not backed in a filesystem. This means that all operations that require fs are not available for this kind of folders. This also means that local folders or linked folders are more specialized folders with more options available. However this is my perception of this thing :-)
I think we could commit the patch and do further changes in HEAD. I would not commit WorkbenchFolder changes and group_obj.gif at this moment. I would get rid of warnings, especially in new added classed, e.g. CreateGroupOperation.
Created attachment 152749 [details] Updated patch Correcting compiler warnings, removing the WorkbenchFolder changes
(In reply to comment #18) > I think we could commit the patch and do further changes in HEAD. I would not > commit WorkbenchFolder changes and group_obj.gif at this moment. I would get > rid of warnings, especially in new added classed, e.g. CreateGroupOperation. The changes are now committed according to your comments. Note that because the WorkbenchFolder changes are not in, groups are currently indistinguishable in the UI from normal folders - the user has to open the properties window to see that the resource is a group.
I think we can consider it FIXED. We will be raising new bugs to address remaining issues.
(In reply to comment #14) > CCing our UI design guru to get an "outside" perspective on this. Susan, we > have this new "group" concept that is like a folder but doesn't exist anywhere > in the file system. It's just used as a logical container for other resources > (conceptually a bit like a working set). They can appear anywhere in the > Eclipse resource tree where files and folders can appear today. The question is > whether we should display this as a folder icon with a decoration, or as a > different icon. There are related questions, such as whether it should just be > a checkbox option in the "New Folder" wizard or a different wizard, but the > general form of the question is: "should we present this to the user as a > special kind of folder, or as a conceptually different entity? Since this bug is fixed (a merge has been done), I've moved the "what should the UI look like" discussion into a new bug, bug 296051. I think we need to be really careful about what we expose to the end user in 3.6 and I don't understand the end user use cases enough. More discussion in the new bug...
Verified in I20091210-1301.
