Community
Participate
Working Groups
This very useful dialog needs polishing. Some of issues to fix are: 1. We should add a help for this dialog. Maybe there should be a question mark in the corner that opens help in the tray. 2. I think that labels may not be clear for people. For instance "Always perform the selected operation in this context"... what context? 3. IMO titles for radio buttons may be confusing too. For instance "Create links for each file and directory", one could think that we create linked resources one by one for each file and directory, but we just create linked resources for the top level files and directories, right? Anyway labels should be short and explained in the help IMO. 4. The dialog title should not say "Import" , this is just a copy operation IMO, so maybe "Copy Files and Folders" or just "Copy"
Created attachment 157530 [details] "File and Folder Import" dialog in my Eclipse
5. I would also take the last item in the combo box (i.e. "Edit Variables...") and made a button out of it. 6. What does "<Automatic> mean? I would expect it work the same way as "<Absolute Path>", but I guess it's there on purpose.
(In reply to comment #0) > This very useful dialog needs polishing. Some of issues to fix are: > 1. We should add a help for this dialog. Maybe there should be a question mark > in the corner that opens help in the tray. > 2. I think that labels may not be clear for people. For instance "Always > perform the selected operation in this context"... what context? I agree, it's not very clear. The context is that this dialog can show up when the user drag and drop files from explorer, for instance, or by dragging resources in between projects in the workspace. Also, the context can differ as in when the user drags a file unto a folder, or a virtual folder, where the option to copy the file isn't present. > 3. IMO titles for radio buttons may be confusing too. For instance "Create > links for each file and directory", one could think that we create linked > resources one by one for each file and directory, but we just create linked > resources for the top level files and directories, right? That's right. > 4. The dialog title should not say "Import" , this is just a copy operation > IMO, so maybe "Copy Files and Folders" or just "Copy" Ok.
(In reply to comment #2) > 5. I would also take the last item in the combo box (i.e. "Edit Variables...") > and made a button out of it. Ok. > 6. What does "<Automatic> mean? I would expect it work the same way as > "<Absolute Path>", but I guess it's there on purpose. When 'Automatic' is selected, the most appropriate path variable is used if possible, otherwise the absolute path is used. When 'Absolute Path' is selected, the absolute path is always used as the linked resource location. For example, say you have a project1 in c:\src\project1, which contains a path variable PVAR with the value "${PROJECT_LOC}/../../foo" (which points to "c:\foo"). The user drags a file located in c:\foo\file.txt unto the project1. If the user selects 'Automatic', the linked resource location will be recorded in the .project file as "PVAR/file.txt", while if the user selects "Absolute Path", it will be recorded as "c:\foo\file.txt". Note that if it's not possible to make a path variable relative location while selecting 'Automatic' (for example, if the file was in "d:\other\file.txt"), then the absolute path will be recorded. Maybe the name 'Automatic' should be changed to something like 'Closest Variable"?
(In reply to comment #4) > Maybe the name 'Automatic' should be changed to something like 'Closest > Variable"? So this is something like "Best match variable", right?
(In reply to comment #5) > (In reply to comment #4) > > Maybe the name 'Automatic' should be changed to something like 'Closest > > Variable"? > > So this is something like "Best match variable", right? That's right, yes.
If it's simple to detect while populating the combo whether the project has defined variables, I would suggest checking this. Then you could eliminate "Absolute" and "Best Variable Match" and simply show "Default" as the choice in this case. (not sure what else is in the combo, if it's only these cases or other choices.) If these are the only choices in the combo, we could instead have an expandable "Variables" section which would have the variable edit button and the combo (or radios?) for figuring out how to resolve variables. I tried to bring up this dialog by dragging things from the explorer, but I always got a copy action by default. When does this dialog come up? I'm asking because we may want some descriptive text explaining why the user is even faced with this dialog. At first I thought it was because copy is not available, but that is the first choice in the radio, so it must be... I tried to drag something from windows explorer into a virtual folder and all I got was an error dialog (but I'm running 20100127 so perhaps this just went in?)
(In reply to comment #7) > If it's simple to detect while populating the combo whether the project has > defined variables, I would suggest checking this. Then you could eliminate > "Absolute" and "Best Variable Match" and simply show "Default" as the choice in > this case. (not sure what else is in the combo, if it's only these cases or > other choices.) If these are the only choices in the combo, we could instead > have an expandable "Variables" section which would have the variable edit > button and the combo (or radios?) for figuring out how to resolve variables. > Well, the thing is that projects always have variables, since there's at least 4 built-in variables. "Default" sounds good to me instead of 'Best Match" or the current "Automatic". > I tried to bring up this dialog by dragging things from the explorer, but I > always got a copy action by default. When does this dialog come up? I'm > asking because we may want some descriptive text explaining why the user is > even faced with this dialog. At first I thought it was because copy is not > available, but that is the first choice in the radio, so it must be... > This is because the JDT project explorer doesn't yet use the proper drop handlers. It works when you use the "Project Explorer" or "Navigator" views. > I tried to drag something from windows explorer into a virtual folder and all I > got was an error dialog (but I'm running 20100127 so perhaps this just went > in?) It will give an error if you use the JDT package explorer.
To wrap the preceding discussion, I think renaming 'Automatic' to 'Default' would make more sense. There's another point raised by Martin: >>When using the Project explorer, drag and dropping files and folders from >>windows explorer onto a virtual folder still displays a dialog (but with 2 >>options instead of 3, in the case of a normal folder). >> >>The 2 options are either to create a hierarchy of linked resource files and >>virtual folders, or to create a set of linked resource files and linked >>resource folders. Those are 2 different valid ways to built up the project >>hierarchy. >I would argue that for a casual user, > the difference between the two options is hard to understand. From an end > user's perspective, the option to choose is: > > (x) automatically track new items being added to this hierarchy > > When this option is ON, create a single folder link, when the option is OFF, > recreate the structure using groups and file-links. I think it's a good point, and understanding the difference between a hierarchy of virtual folders and linked resource files, and one with linked resource folder and files (which ends up being linked resource folders, and mostly regular files), is not straight forward to understand for users. What about wording the option as follows: [ ] Keep folders synchronized with their respective file system directories (defaults to false - so it creates virtual folders by default) A tooltip would also explain that this option causes linked resource folders to be created instead of virtual folders.
> [ ] Keep folders synchronized with their respective file system directories I find the word "synchronized" problematic since it suggests that there are two different entities being kept in sync -- but there is only one entity and a link (reference) to it. But I don't have a better proposal other than what I already proposed...
(In reply to comment #10) > > [ ] Keep folders synchronized with their respective file system directories > > I find the word "synchronized" problematic since it suggests that there are two > different entities being kept in sync -- but there is only one entity and a > link (reference) to it. But I don't have a better proposal other than what I > already proposed... There is two entities being kept in sync, though : The workspace folder children list, and the file system directory children list. Conceptually, when creating a folder hierarchy through drag and drop, the virtual folder is a workspace folder that doesn't keep in sync with the file system directory that it was created from (since all its children are linked resources), while a linked resource folder does. Does that make sense?
I also find "synchronized" problematic because the term is already used in the same context (resource model and file system) but with a different meaning: We already say "out of sync" in case the resource model is not up-to-date. Overloading too similar terms is confusing. (In reply to comment #9) The dialog should look similar when dropping onto a folder and when dropping onto a virtual folder. How would the normal folder case look if the two other options were replaced by a checkbox? 2 radios for normal vs. virtual folder, plus the checkbox as sub-option of the second radio? You could also leave the 2-3 radios, but add icons to show what happens, e.g.: 0 [1] Copy files and folders 0 [2] Create virtual folder structure with links to files 0 [3] Create links to files and folders [X] are the following icons: [1]: [file icon] [folder icon] [2]: [file icon with link overlay] [folder icon with link overlay] [3]: [file icon with link overlay] [folder icon with virtual folder overlay]
Other problems in the dialog: - there must be a way to get the dialog back after the user clicked "Always perform..." - mnemonics - radio options don't end with a '.' - the term we use is 'folder', not 'directory'
(In reply to comment #9) > I think it's a good point, and understanding the difference between a hierarchy > of virtual folders and linked resource files, and one with linked resource > folder and files (which ends up being linked resource folders, and mostly > regular files), is not straight forward to understand for users. > > What about wording the option as follows: > > [ ] Keep folders synchronized with their respective file system directories > > (defaults to false - so it creates virtual folders by default) Really? I would expect that by default the folder would be kept up to date with the file system. This is a gut reaction with no thought of actual use case, so I could be wrong. I can understand "oh, this folder is now shown in my workspace." Harder to imagine "I only want a folder that shows a snapshot in time of the content of the file system." Could get really confusing when I go to refresh it, thinking something will happen. As far as wording goes, I think radios are better than checkboxes when the choice is confusing (as it is here). More explanation of the true/false state can only help, plus address Markus' concern about the dialog being more similar in different contexts. (In reply to comment #12) > You could also leave the 2-3 radios, but add icons to show what happens, e.g.: > > 0 [1] Copy files and folders > 0 [2] Create virtual folder structure with links to files > 0 [3] Create links to files and folders > > [X] are the following icons: > [1]: [file icon] [folder icon] > [2]: [file icon with link overlay] [folder icon with link overlay] > [3]: [file icon with link overlay] [folder icon with virtual folder overlay] I like this. It becomes similar to the advanced section of the new folder wizard. I would suggest this wording (and ordering) Copy files and folders Link to folders and files Create virtual folders with links to files I think "snapshot" might be a way to describe the third case in the help. The folders represent what was in the file system when you performed the action.
(In reply to comment #14) >I would suggest this wording (and ordering) > > Copy files and folders > Link to folders and files > Create virtual folders with links to files > > I think "snapshot" might be a way to describe the third case in the help. The > folders represent what was in the file system when you performed the action. Right after I pushed commit I realize that's inconsistent. Copy folders and files Link to folders and files Create virtual folders with links to files I think saying "folder" before files makes the most sense because it's the folder behavior that drives the rest of it.
(In reply to comment #12) > I also find "synchronized" problematic because the term is already used in the > same context (resource model and file system) but with a different meaning: We > already say "out of sync" in case the resource model is not up-to-date. > Overloading too similar terms is confusing. > That's true, but it's not a different concept, it's the same. Linked resource folders are synchronizable (they are kept in sync with the file system directory by doing a refresh), while virtual folders are not.
(In reply to comment #15) > (In reply to comment #14) > >I would suggest this wording (and ordering) > > > > Copy files and folders > > Link to folders and files > > Create virtual folders with links to files > > > > I think "snapshot" might be a way to describe the third case in the help. The > > folders represent what was in the file system when you performed the action. > > Right after I pushed commit I realize that's inconsistent. > > Copy folders and files > Link to folders and files > Create virtual folders with links to files > > I think saying "folder" before files makes the most sense because it's the > folder behavior that drives the rest of it. That sounds fine to me, besides some slight modifications: Copy folders and files Link to folders and files Create virtual folders and links to files Notice the *and* instead of "with" for the last item, since links are not really a property of virtual folders, and besides, if the user drags only files, no virtual folder is created. A further sophistication would be for the UI to display only 2 choices (Copy/Link) when only files are selected, since the 2nd and 3rd options are the same.
(In reply to comment #16) > That sounds fine to me, besides some slight modifications: > > Copy folders and files > Link to folders and files > Create virtual folders and links to files > > Notice the *and* instead of "with" for the last item, since links are not > really a property of virtual folders, and besides, if the user drags only > files, no virtual folder is created. +1. > > A further sophistication would be for the UI to display only 2 choices > (Copy/Link) when only files are selected, since the 2nd and 3rd options are the > same. +1.
Created attachment 158297 [details] Patch
Created attachment 158298 [details] UI 1. Files and folders dragged on a folder
Created attachment 158299 [details] UI 2. Files and folders dragged on a virtual folder
Created attachment 158300 [details] UI 3. Files only dragged on a folder
Created attachment 158301 [details] UI 1. Files only dragged on a virtual folder
Created attachment 158302 [details] UI 4. Files only dragged on a virtual folder
Please see the attached screen shots. I tried to incorporate all suggestions so far. I have few questions: a) The spacing looks strange to me (especially the space between the question and the first radio button), although it simply uses the default MessageDialog metrics. Is this correct or should be changed? b) Do the icons improve usability or overload the UI? c) Is there any suggestion to change the string 'Always perform the selected operation in this context' to something else? The 4 UIs are example of the context the string is referring to. d) in UI 4, should we still display the only radio button? It seems to make sense in the context of the other UIs, but looks strange alone. Thanks,
Created attachment 158303 [details] New icons To be unzipped in org.eclipse.ui.ide\icons\full\obj16
The screenshots are looking good. But I wouldn't create special icon files for this. Just using the existing icons and overlays would be better, since it also ensures that the icons don't go out of sync when one of the components changes. (In reply to comment #14) > I would suggest this wording (and ordering) (In reply to comment #17) > Copy folders and files > Link to folders and files > Create virtual folders and links to files Note that I deliberately kept the existing ordering of the 3 options (2 and 3 swapped), because it maps better to the ordering in the New Folder dialog. Furthermore, I find "files and folders" more "natural" than "folders and files" (but I have no theory to justify this, except that you get 2 times more Google matches for the former). I also find it important to tell somehow that the operation creates virtual folders recursively, not only for top level folders. How about this: 1 Copy files and folders 2 Link to files and recreate structure with virtual folders 3 Link to files and folders Alternative: 2 Link to files and create virtual folder structure
(In reply to comment #27) > The screenshots are looking good. But I wouldn't create special icon files for > this. Just using the existing icons and overlays would be better, since it also > ensures that the icons don't go out of sync when one of the components changes. > I've been trying to do that, but I haven't found any public API to create images based on overlays. From what I could see, it's all done in internal code. Or am I mistaken? Then there's the problem of making an image with two other images to show both. > > (In reply to comment #14) > > I would suggest this wording (and ordering) > > (In reply to comment #17) > > Copy folders and files > > Link to folders and files > > Create virtual folders and links to files > > Note that I deliberately kept the existing ordering of the 3 options (2 and 3 > swapped), because it maps better to the ordering in the New Folder dialog. > Furthermore, I find "files and folders" more "natural" than "folders and files" > (but I have no theory to justify this, except that you get 2 times more Google > matches for the former). I also find it important to tell somehow that the > operation creates virtual folders recursively, not only for top level folders. > How about this: > > 1 Copy files and folders > 2 Link to files and recreate structure with virtual folders > 3 Link to files and folders > I like this one, I think it sounds more natural.
Created attachment 158459 [details] UI 1. Files and folders dragged on a folder
Created attachment 158460 [details] UI 2. Files and folders dragged on a virtual folder
Created attachment 158461 [details] UI 3. Files only dragged on a folder
Just a reminder about the dialog title and the check box label. See comment 0.
Re overlays, see CompositeImageDescriptor. You can create a subclass and implement drawCompositeImage, similar to how e.g. org.eclipse.ui.internal.ide.misc.OverlayIcon does it. You also need to take care that you explicitly dispose all the images you create, otherwise you're leaking SWT handles (this does not apply to mere ImageDescriptors).
Yeah, this is looking better! (In reply to comment #28) > > How about this: > > > > 1 Copy files and folders > > 2 Link to files and recreate structure with virtual folders > > 3 Link to files and folders > > > > I like this one, I think it sounds more natural. - I am still curious if anyone thinks #2 is the default/more likely. It is harder to parse/comprehend and for someone who is not sure of the difference, give them the easier choice first. Most users understand "copy" vs. "link." I don't agree that the ordering should be preserved to match new folder. Plus, in bug 297402 we discussed that virtual folders should be the last choice. The current ordering is only because of the code structure (the composite that contains the linking info). In the "files only" case, we only have "copy" and "link" so why not leave the advanced choice at the end, and always suggest the simpler one? - What about adding the word "folder" before structure? "Link to files and recreate folder structure with virtual folders" - As far as title goes. "File and Folder Copy" doesn't seem like a good term since we don't always offer copy. What about "File and Folder Operation" This is not ideal, I think we typically would put the verb first, but in this case we don't know the verb. (In reply to comment #25) > Please see the attached screen shots. I tried to incorporate all suggestions > so far. > > I have few questions: > > a) The spacing looks strange to me (especially the space between the question > and the first radio button), although it simply uses the default MessageDialog > metrics. Is this correct or should be changed? Honestly, at this point it probably shouldn't even be a message dialog. It's not asking a simple question, I suggest making it a regular dialog. Then you won't have the spacing issue with the question icon. > > b) Do the icons improve usability or overload the UI? It does look crowded compared to the one without it. However, I think they help. I guess we need feedback. I think that for the user who has never heard of virtual folders (and possibly never intentionally used linked files), the icons can help show what will happen. And I think the difference between the last two choices is extremely subtle for most people and anything that helps explain the difference is useful. > > c) Is there any suggestion to change the string 'Always perform the selected > operation in this context' to something else? The 4 UIs are example of the > context the string is referring to. What about 'Always perform the selected operation in this situation' > > d) in UI 4, should we still display the only radio button? It seems to make > sense in the context of the other UIs, but looks strange alone. > > Thanks, In this case, I think - remove the radio (and the top level message) - the dialog should be called "Link Files" - the checkbox text should say [ ] Always use the selected location when linking files There is also the question of how these preferences are remembered. For example, in the case where only link is available, we wouldn't want link to become the default operation in the more general case, though we may want to remember the location choice.
Created attachment 158525 [details] UI 1. Files and folders dragged on a folder
Created attachment 158526 [details] UI 2. Files and folders dragged on a virtual folder
Created attachment 158527 [details] UI 3. Files only dragged on a folder
Created attachment 158528 [details] UI 4. Files only dragged on a virtual folder
Created attachment 158529 [details] UI 5. Showing the Help button pressed
Created attachment 158530 [details] Source Patch
(In reply to comment #32) > Just a reminder about the dialog title and the check box label. See comment 0. Now with the new screenshot and patch: - Help is added (see UI 5.) - The title of the dialog is updated
(In reply to comment #34) > Yeah, this is looking better! > > (In reply to comment #28) > > > How about this: > > > > > > 1 Copy files and folders > > > 2 Link to files and recreate structure with virtual folders > > > 3 Link to files and folders > > > > > > > I like this one, I think it sounds more natural. > > - I am still curious if anyone thinks #2 is the default/more likely. It is > harder to parse/comprehend and for someone who is not sure of the difference, > give them the easier choice first. Most users understand "copy" vs. "link." > I don't agree that the ordering should be preserved to match new folder. Plus, > in bug 297402 we discussed that virtual folders should be the last choice. The > current ordering is only because of the code structure (the composite that > contains the linking info). In the "files only" case, we only have "copy" and > "link" so why not leave the advanced choice at the end, and always suggest the > simpler one? Fair enough, I'll put back virtual folder as last one. > - What about adding the word "folder" before structure? > "Link to files and recreate folder structure with virtual folders" > Ok, sure. > - As far as title goes. "File and Folder Copy" doesn't seem like a good term > since we don't always offer copy. What about "File and Folder Operation" > This is not ideal, I think we typically would put the verb first, but in this > case we don't know the verb. > Ok, I put now the title "File and Folder Operation" and "File Operation" (when there's only files being dragged). > (In reply to comment #25) > > Please see the attached screen shots. I tried to incorporate all suggestions > > so far. > > > > I have few questions: > > > > a) The spacing looks strange to me (especially the space between the question > > and the first radio button), although it simply uses the default MessageDialog > > metrics. Is this correct or should be changed? > > Honestly, at this point it probably shouldn't even be a message dialog. It's > not asking a simple question, I suggest making it a regular dialog. Then you > won't have the spacing issue with the question icon. > Internally, it's not a message dialog anymore, but I still re-created the "?" icon to make it look like one. Do you have another dialog that represent the idea you have in mind so I can get a better grasp of what you are suggesting? > > > > b) Do the icons improve usability or overload the UI? > > It does look crowded compared to the one without it. However, I think they > help. I guess we need feedback. I think that for the user who has never heard > of virtual folders (and possibly never intentionally used linked files), the > icons can help show what will happen. And I think the difference between the > last two choices is extremely subtle for most people and anything that helps > explain the difference is useful. > > > > c) Is there any suggestion to change the string 'Always perform the selected > > operation in this context' to something else? The 4 UIs are example of the > > context the string is referring to. > > What about > 'Always perform the selected operation in this situation' > Ok, fine. > > d) in UI 4, should we still display the only radio button? It seems to make > > sense in the context of the other UIs, but looks strange alone. > > > > Thanks, > > In this case, I think > - remove the radio (and the top level message) > - the dialog should be called "Link Files" > - the checkbox text should say > [ ] Always use the selected location when linking files > Sounds fine, to me. > There is also the question of how these preferences are remembered. For > example, in the case where only link is available, we wouldn't want link to > become the default operation in the more general case, though we may want to > remember the location choice. Currently, the preference is remembered based on the internal 'mode' flags. So that means there's a different situation for all UI 1, 2, 3 and 4 screenshots in the attachment.
(In reply to comment #42) > Internally, it's not a message dialog anymore, but I still re-created the "?" > icon to make it look like one. Do you have another dialog that represent the > idea you have in mind so I can get a better grasp of what you are suggesting? Just a plain vanilla dialog. I started playing around with move/copy/link/rename in the package explorer looking for an example, and I see that we definitely have a hodge-podge of dialog styles. - we use message dialogs, sometimes with extra controls, as in the delete project confirmation dialog. - we use plain dialogs when information is needed to continue, as in the copy project with duplicate name dialog. (I'll attach a snapshot of that one as an example of what I mean) - we are even using wizards (without banner graphics) in some cases, for example renaming a java element opens a mini-wizard - other precanned dialogs are used for certain situations (like the confirm overwrite dialog which includes the buttons for "yes to all," "no to all," etc. My feeling is that since the dialog is getting the user to pick which operation applies, and some detailed information that depends on the situation, then it is well beyond the "yes/no" of message dialog, so the question mark is not needed.
Created attachment 158537 [details] sort members dialog snapshot of sort members dialog. I'm not saying this a particularly great/interesting dialog, it's just an example of a non-message box dialog where the user is making choices from a radio box and providing additional info. I think message boxes should mainly be used when the buttons themselves (yes/no/cancel, etc.) are the choices. If the radios are presenting/explaining the choices, then I don't think we need to have the question mark.
Created attachment 158688 [details] Source Patch Latest source patch, new icons are not needed anymore.
(In reply to comment #33) > Re overlays, see CompositeImageDescriptor. You can create a subclass and > implement drawCompositeImage, similar to how e.g. > org.eclipse.ui.internal.ide.misc.OverlayIcon does it. You also need to take > care that you explicitly dispose all the images you create, otherwise you're > leaking SWT handles (this does not apply to mere ImageDescriptors). Thanks for the tip, this is now implemented in the latest patch.
Created attachment 158689 [details] UI 1. Files and folders dragged on a folder
Created attachment 158690 [details] UI 2. Files and folders dragged on a virtual folder
Created attachment 158691 [details] UI 3. Files only dragged on a folder
Created attachment 158692 [details] UI 4. Files only dragged on a virtual folder
OK. Please take a look at the latest screenshots, and the included patch, I believe I addressed all issues raised in this bug report.
Created attachment 158697 [details] More space bettwen icons? I think that icons on the latest screenshots are too crowded. I tried to find a comment saying that this is on purpose, but I couldn't. I think we should add more space as on the attached picture.
Created attachment 158698 [details] UI 1. Files and folders dragged on a folder
Created attachment 158700 [details] UI 2. Files and folders dragged on a virtual folder
Created attachment 158701 [details] Source Patch
(In reply to comment #52) > Created an attachment (id=158697) [details] > More space bettwen icons? > > I think that icons on the latest screenshots are too crowded. I tried to find a > comment saying that this is on purpose, but I couldn't. I think we should add > more space as on the attached picture. Good point, I updated the code and screenshots to add some padding between the icons
I see that 'Automatic' is gone - good. However, I still have no clue what 'Default' does. Given the time needed to explain this (not just in this bug ;-), it seems that this needs more polish. Also, when I tried this (automatic) in I20100209-2300 it did not what I'd expect as a good default i.e. when I dragged an OS folder on a project it did not link the folder using full path but somehow relative to the {$ECLIPSE_HOME}. Please find a better solution for Create linked resources as relative to: [combo] relative to: "Absolute Path" sounds bad relative to: "Default" or "<Automatic>", is not clear as stated above.
(In reply to comment #57) > I see that 'Automatic' is gone - good. However, I still have no clue what > 'Default' does. Given the time needed to explain this (not just in this bug > ;-), it seems that this needs more polish. Also, when I tried this (automatic) > in I20100209-2300 it did not what I'd expect as a good default i.e. when I > dragged an OS folder on a project it did not link the folder using full path > but somehow relative to the {$ECLIPSE_HOME}. > Hum, the general heuristic is that with 'default', the code tries to make a resource location relative to 'PROJECT_LOC' if possible. Can you file a bug with the reproducibility steps for this? Thanks. > Please find a better solution for > Create linked resources as relative to: [combo] > relative to: "Absolute Path" sounds bad > relative to: "Default" or "<Automatic>", is not clear as stated above. Is your comment about needing better documentation (when you press on the help button, it's minimal at the moment), in which case, it would be another bug than this one, since I'm trying to work the UI design at the moment.
(In reply to comment #57) > I see that 'Automatic' is gone - good. However, I still have no clue what > 'Default' does. Given the time needed to explain this (not just in this bug > ;-), it seems that this needs more polish. Also, when I tried this (automatic) > in I20100209-2300 it did not what I'd expect as a good default i.e. when I > dragged an OS folder on a project it did not link the folder using full path > but somehow relative to the {$ECLIPSE_HOME}. > > Please find a better solution for > Create linked resources as relative to: [combo] > relative to: "Absolute Path" sounds bad > relative to: "Default" or "<Automatic>", is not clear as stated above. To put it differently: Do you think that it should be presented differently to the user in that dialog, or only a matter of having more help and help topics in the help button?
>Hum, the general heuristic is that with 'default', the code tries to make a >resource location relative to 'PROJECT_LOC' if possible. OK, then name the option like that ;-) In case DnD from the OS I would never expect that as being a default. >Can you file a bug with the reproducibility steps for this? Thanks. See bug 302447. >Is your comment about needing better documentation No, it's about the UI. When I see the UI it should be descriptive enough to do the work. Note that it was not just me: also Tomasz and Szymon needed an explanation about what this actually means. We should try to find a better name for 'Default' or rework the UI so that it's no longer needed. >> Please find a better solution for >> Create linked resources as relative to: [combo] >> relative to: "Absolute Path" sounds bad >> relative to: "Default" or "<Automatic>", is not clear as stated above. "relative to absolute path" sounds irrational and "relative to default" has no meaning. ;-)
(In reply to comment #60) > >Hum, the general heuristic is that with 'default', the code tries to make a > >resource location relative to 'PROJECT_LOC' if possible. > OK, then name the option like that ;-) In case DnD from the OS I would never > expect that as being a default. > > >Can you file a bug with the reproducibility steps for this? Thanks. > See bug 302447. > > >Is your comment about needing better documentation > No, it's about the UI. When I see the UI it should be descriptive enough to do > the work. Note that it was not just me: also Tomasz and Szymon > needed an explanation about what this actually means. We should try to find a > better name for 'Default' or rework the UI so that it's no longer needed. > > >> Please find a better solution for > >> Create linked resources as relative to: [combo] > >> relative to: "Absolute Path" sounds bad > >> relative to: "Default" or "<Automatic>", is not clear as stated above. > "relative to absolute path" sounds irrational and "relative to default" has no > meaning. ;-) I agree that 'relative to' doesn't match grammatically with all the options. Here's what I suggest: 1) Have "PROJECT_LOC" as the first selection in the popup. 2) Instead of having a 'Absolute Path' item, the whole line would be preceded with a checkbox, so if the checkbox isn't set (it's set by default), the linked resources would not be generated as relative paths (i.e. they would be generated as absolute paths). 3) Regarding the "Default" item - note that it's currently broken in M5, and all it does, is do as if 'PROJECT_LOC' is selected instead - I'm open to the idea of removing it all together. But be aware that is a loss of functionality. What that means is that, say the user has a variable "ANDROID_SDK". He drag and drop files in the project from that sdk in the project. With the 'Default' item, the code would recognize that the smallest relative paths is towards the "ANDROID_SDK" variable, and then encore their location relative to that. Instead, the user would have to manually select the appropriate variable. Another option would be to rename that "Default" item to something like "Closest Variable". What do you guys think?
>Another option would be to rename that "Default" item to something like >"Closest Variable". That also means nothing to me, i.e. what's "closest"? ;-)
(In reply to comment #62) > >Another option would be to rename that "Default" item to something like > >"Closest Variable". > That also means nothing to me, i.e. what's "closest"? ;-) I welcome any helpful and constructive suggestions.
My take is that if we can't name it, and it's hard for those of us on the bug to understand the difference, can we go with your suggestion #3 and just a pick the interpretation we think is correct and not make the user figure all this out? (Or perhaps if it's important to some very small subset of users, we could make it a preference, though I'd really like to avoid this). (In reply to comment #61) > > 3) Regarding the "Default" item - note that it's currently broken in M5, and > all it does, is do as if 'PROJECT_LOC' is selected instead - I'm open to the > idea of removing it all together. > > But be aware that is a loss of functionality. > > What that means is that, say the user has a variable "ANDROID_SDK". He drag > and drop files in the project from that sdk in the project. With the 'Default' > item, the code would recognize that the smallest relative paths is towards the > "ANDROID_SDK" variable, and then encore their location relative to that. I'm sorry, but I still don't understand the example above. Can you give an example that includes concrete path names and the different path that's computed in each case? Also, do you think this is a corner case or a common one?
(In reply to comment #64) > My take is that if we can't name it, and it's hard for those of us on the bug > to understand the difference, can we go with your suggestion #3 and just a pick > the interpretation we think is correct and not make the user figure all this > out? (Or perhaps if it's important to some very small subset of users, we > could make it a preference, though I'd really like to avoid this). > > (In reply to comment #61) > > > > 3) Regarding the "Default" item - note that it's currently broken in M5, and > > all it does, is do as if 'PROJECT_LOC' is selected instead - I'm open to the > > idea of removing it all together. > > > > But be aware that is a loss of functionality. > > > > What that means is that, say the user has a variable "ANDROID_SDK". He drag > > and drop files in the project from that sdk in the project. With the 'Default' > > item, the code would recognize that the smallest relative paths is towards the > > "ANDROID_SDK" variable, and then encore their location relative to that. > > I'm sorry, but I still don't understand the example above. Can you give an > example that includes concrete path names and the different path that's > computed in each case? > > Also, do you think this is a corner case or a common one? A simple example: In project1, there's two path variables: FOO and BAR FOO points to c:\foo BAR points to c:\bar When the user drag and drop a file unto project1 that is located in "c:\foo\file.txt", relative to what path variable should the linked resource location encoded? It depends what the user selects in the combo box in the Import Dialog If, instead of selecting "FOO", or "BAR" in the combo box, "Closest Variable" (or whatever name is chosen) is selection, the code recognize that "FOO\file.txt" is shorter than "BAR\..\foo\file.txt", so it decides to import the file as relative to the variable FOO. Does that make sense? I believe this is a common case, and is the most appropriate choice second only to "PROJECT_LOC" (which in most cases should do fine for the user).
>I welcome any helpful and constructive suggestions. Sure. Let's try it ;-) 1. I fully support fixing bug 302441 2. don't provide Default/Closest/Automatic option but instead, each time the dialog comes up, select your best match by default 3. to avoid the strange "relative to: absolute" sentence I would add a radio box: ( ) absolute ( ) relative to: [ combo ] if we think that uses up too much space and we only want the combo box, we could rename "Absolute" to "Root" or "Nothing", but I'd avoid that if possible 4. I would remove the "Always perform..." option: users probably won't see that dialog often and should they decide to change their mind later they would be doomed if there's no preference where they can bring back the dialog. Not offering that option also makes the implementation of 2. easier.
(In reply to comment #66) > 1. I fully support fixing bug 302441 > Generally speaking, I think that the suggestion to make the dialog appear only when the user press a key while drag and drop (DROP_LINK) means that he will practically never see that dialog, and never be aware that projects hierarchies can be built in different ways than copying files. I think this boils down to whether it is necessary to jump through hoops to use linked resources in Eclipse (e.g. use special keys in some context to create linked resource), or it's supported as a first class citizen - along regular files - as a way to build up project hierarchies. > 2. don't provide Default/Closest/Automatic option but instead, each time the > dialog comes up, select your best match by default > I think that's a good suggestion. > 3. to avoid the strange "relative to: absolute" sentence I would add a radio > box: > ( ) absolute > ( ) relative to: [ combo ] > if we think that uses up too much space and we only want the combo box, we > could rename "Absolute" to "Root" or "Nothing", but I'd avoid that if > possible > What about this: [ ] Create linked resource locations as relative to: [combo] If it's not checked, then they aren't relative, but absolute. > 4. I would remove the "Always perform..." option: users probably won't > see that dialog often and should they decide to change their mind later they > would be doomed if there's no preference where they can bring back > the dialog. Not offering that option also makes the implementation of 2. > easier. I think that's a general principle that this dialog should conform to. In Eclipse right now, there's a lot of dialogs that One workaround would be to show a label below the dialog as something like "Press key [some modifier] to make the dialog appear again" when the use selects the checkbox. A example of such dialog in Eclipse is the 'Source/Sort Members'. There's a 'Do not show this message again' checkbox. As far as I know, there's no way to make the dialog appear again once checked. Then, that dialog as a preference. Maybe the only thing missing for that dialog is a preference setting "Always Copy / Link / Links with Virtual Folders / Prompt"?
>Generally speaking, I think that the suggestion to make the dialog appear only >when the user press a key while drag and drop (DROP_LINK) means that he will >practically never see that dialog, and never be aware that projects hierarchies >can be built in different ways than copying files. I claim that practically no user wants that when dragging an OS resource into the workspace and hence they shouldn't be bothered with a dialog. And as outlined in the other bug, there's a way to enable it for domains where this is more common. In addition this can be advertised in the 3.6 N&N. >[ ] Create linked resource locations as relative to: [combo] It depends whether it's 100% clear that not checking that box means a linked resource with absolute path is created. >A example of such dialog in Eclipse is the 'Source/Sort Members'. There's a >'Do not show this message again' checkbox. As far as I know, there's no way to >make the dialog appear again once checked. You just picked one which can be reset ;-) There's an option on the 'Java' preference page to reset all such dialogs within JDT, but there's no such thing in the platform right now. >Maybe the only thing missing for that dialog is a preference setting "Always >Copy / Link / Links with Virtual Folders / Prompt"? The other bug already suggests to add a preference.
(In reply to comment #68) > >Generally speaking, I think that the suggestion to make the dialog appear only > >when the user press a key while drag and drop (DROP_LINK) means that he will > >practically never see that dialog, and never be aware that projects hierarchies > >can be built in different ways than copying files. > I claim that practically no user wants that when dragging an OS resource into > the workspace and hence they shouldn't be bothered with a dialog. And as > outlined in the other bug, there's a way to enable it for domains where this is > more common. In addition this can be advertised in the 3.6 N&N. > I think your claim could be summarized more generally as "No user wants to use linked resources". I think that's true today, for JDT users, but my perspective is that since linked resource support was severely lacking in Eclipse for years, it was very impractical to use it, so JDT designers have been using a different approach to solve problems. One example, is that JDT users use a 'poor child' style of linked resources when they setup the java build path / Libraries, where the user can setup libraries based (among other things) on sets of variables. A feature that is fundamentally the same as the Path Variable linked resource, and was developed because linked resource support was lacking, but ends up basically re-inventing the wheel. And that gets worse when other projects need the same capabilities, but can't leverage the JDT implementation, and then have to yet again re-implement a variable-relative resource mechanism. So, the JDT could be simplified by taking advantage of the new linked resource support in allowing the user to drag and drop .jar files as path variable relative linked resources, and so on. Whether there's a will, or need, or desire to change how things currently work in the JDT, that's a whole different story. So I think your point comes from the JDT perspective, where you feel like linked resources are not a desirable feature, since the JDT was designed without them, and gets by without. Honestly, I'm not sure how displaying a dialog - which defaults to the old behavior of copying files/resources - is a problem when that's not an operation - I think - that is used commonly for JDT users (dragging files and folders from the OS shell to an Eclipse project). > >[ ] Create linked resource locations as relative to: [combo] > It depends whether it's 100% clear that not checking that box means a linked > resource with absolute path is created. > > >A example of such dialog in Eclipse is the 'Source/Sort Members'. There's a > >'Do not show this message again' checkbox. As far as I know, there's no way to > >make the dialog appear again once checked. > You just picked one which can be reset ;-) There's an option on the 'Java' > preference page to reset all such dialogs within JDT, but there's no such thing > in the platform right now. > I see. > >Maybe the only thing missing for that dialog is a preference setting "Always > >Copy / Link / Links with Virtual Folders / Prompt"? > The other bug already suggests to add a preference.
Another point, is that the JDT is part of the 'classic' Eclipse package, and the package explorer is very often used for other domain than strictly JDT/java based projects. So by being used in a broader scope, the benefit of having the dialog showing up by default I believe outweighs the inconvenience of having to click "ok" ok "always use this operation" in the rare case where JDT users actually copy file and folders from the OS shell into a project.
It's not just JDT. A normal RCP developer also expects copy here and as outlined in the other bug, those domains (e.g. CDT) that want to change that can easily do it by e.g. changing the default when their bundle is started. Also, if the user really wants to link it he can directly do it with the modifier and as said, we can put it into the N&N.
(In reply to comment #71) > It's not just JDT. A normal RCP developer also expects copy here and as > outlined in the other bug, those domains (e.g. CDT) that want to change that > can easily do it by e.g. changing the default when their bundle is started. > Also, if the user really wants to link it he can directly do it with the > modifier and as said, we can put it into the N&N. What you are suggesting is not to keep the default, but to prevent the option to be seen by the user all together. That dialog doesn't change the default - including for the CDT - it still defaults to copy. The problem with the modifier is that it prevents any user to discover that feature while building a project hierarchy, even if he would like to use linked resources, he most probably would not be aware it's possible. Then, one could argue that the default general behavior in windows is to link/move on drag, and use a special modifier for copy (CTRL). Actually, in a lot of applications, the default drag behavior changes from link/move to copy transparently depending on the target. Anyhow, this feature is not about changing the default behavior in Eclipse on drag -copy-, it's about showing available options to the user.
Created attachment 159019 [details] UI 1. Files and folders dragged on a folder
Created attachment 159020 [details] UI 2. Files and folders dragged on a virtual folder
Created attachment 159021 [details] UI 3. Files only dragged on a folder
Created attachment 159022 [details] UI 4. Files only dragged on a virtual folder
Created attachment 159023 [details] UI 5. Showing the Help button pressed
Created attachment 159024 [details] UI 6. Preference panel (the two groups) controlling the default values of the dialog
Created attachment 159025 [details] Source Patch
Ok, I re-attached a new series of screenshots (from UI.1 to 6), including the source patch. What's new: 1) The "Absolute" option in the combo box is now gone. There is a checkbox instead for the whole line (defaults to true), and deselecting the checkbox makes linked resource locations be absolute. The checkbox looks as follows: [ x ] Create link locations as relative to: [combo box] Note that I changed the text as well to be consistent with the text in the radio buttons - 'link locations' instead of linked resource, since it's really the location that is made relative, not the linked resource. 2) The "Default" option in the combo box is now gone. Instead, the combo box selection gets pre-initialized with the most appropriate value when the dialog is displayed. 3) There's now a new preference panel (under General | Workspace | Linked Resources) to control whether the dialog is shown at all, or automatically do copy/link/link with virtual folders 4) I changed the 'Always perform the selected operation in this situation' to 'Always perform the selected operation', since there's no more a multitude of situations, but only 2 - for 2 different dialogs (from the user's perspective). The 2 dialogs are a) the dialog that shows up when files and/or folders are dropped on a regular folder or project b) the dialog that shows up when files and/or folders are dropped on a virtual folder The main difference is that one has a 'copy' option, and the other doesn't. So the two dialogs have two different preference panel groups (see screenshot UI.6), and keep a separate set of settings for the 'always perform the selection operation' setting. I feel this is appropriate, since even if the user would like always a given operation when dropping files on a regular folder, he could very well want another operation on a virtual folder. Plus, selecting to always 'copy' files when dropped on a regular folder would not give any clue as what to do when files and dropped on a virtual folder. Let me know what you guys think. Thanks.
Looks nice! In UI 4. Dragging files onto a virtual folder, I'd find "always perform the selected operation" more natural than "always use the selected location". I don't see a need for being special in this case. In UI 6. Preference panel, I'd find "Drag and drop items..." or "Drag and drop files..." less crowded and thus easier to grasp than "Drag and drop files and folders on a ...".
>2) The "Default" option in the combo box is now gone. Good :-) >Instead, the combo box >selection gets pre-initialized with the most appropriate value when the dialog >is displayed. What do you do/remember if the user checks "Always perform the selected operation"? I suspect once this is checked we shouldn't guess the most appropriate value but use what the user sees in the UI when checking that box. It is not clear/obvious that unchecking the checkbox creates an absolute link. "... as relative to..." sounds strange to me, but I'm not an native English speaker. "...imported in the project:": I would replace "in" with "into".
(In reply to comment #81) > Looks nice! > > In UI 4. Dragging files onto a virtual folder, I'd find "always perform the > selected operation" more natural than "always use the selected location". I > don't see a need for being special in this case. > The text in the UI reads "Always perform the selected operation" already, so it seems to follow you suggestion. Did you meant the opposite? > In UI 6. Preference panel, I'd find "Drag and drop items..." or "Drag and drop > files..." less crowded and thus easier to grasp than "Drag and drop files and > folders on a ...". Fair enough, I now changed the text to "Drag and drop items..."
Created attachment 159761 [details] UI 6. Preference panel (the two groups) controlling the default values of the dialog
(In reply to comment #82) > >Instead, the combo box > >selection gets pre-initialized with the most appropriate value when the dialog > >is displayed. > What do you do/remember if the user checks "Always perform the selected > operation"? I suspect once this is checked we shouldn't guess the most > appropriate value but use what the user sees in the UI when checking that box. > If the users clicks 'always perform the selected operation', the dialog will remember whether the 'Create link location as relative to:' was selected or not, along with the choice between copy/link/link with virtual folders. But it will not remember towards which variable the locations are generated as relative to, the variable is internally calculated each time, so the most appropriate variable will always be selected. > It is not clear/obvious that unchecking the checkbox creates an absolute link. Maybe a tooltip would help? > "... as relative to..." sounds strange to me, but I'm not an native English > speaker. > > "...imported in the project:": I would replace "in" with "into". I'm not a native English speaker either. Can anyone comment on this please?
(In reply to comment #85) > > > "... as relative to..." sounds strange to me, but I'm not an native English > > speaker. > Create link locations as relative to: <combo> It would be "Create link locations relative to: <combo>" > > > > "...imported in the project:": I would replace "in" with "into". > > I'm not a native English speaker either. Can anyone comment on this please? "into" is more appropriate. Later, PW
(In reply to comment #81) > Looks nice! > > In UI 4. Dragging files onto a virtual folder, I'd find "always perform the > selected operation" more natural than "always use the selected location". I > don't see a need for being special in this case. > Oh, I see how what you are referring to. This was suggested by Susan (the UI expert), as (quoting): "> d) in UI 4, should we still display the only radio button? It seems to make > sense in the context of the other UIs, but looks strange alone. > > Thanks, In this case, I think - remove the radio (and the top level message) - the dialog should be called "Link Files" - the checkbox text should say [ ] Always use the selected location when linking files There is also the question of how these preferences are remembered. For example, in the case where only link is available, we wouldn't want link to become the default operation in the more general case, though we may want to remember the location choice."
Created attachment 159773 [details] UI 1. Files and folders dragged on a folder
Created attachment 159774 [details] UI 2. Files and folders dragged on a virtual folder
Created attachment 159775 [details] UI 3. Files only dragged on a folder
Created attachment 159776 [details] UI 4. Files only dragged on a virtual folder
Created attachment 159777 [details] UI 5. Showing the Help button pressed
Created attachment 159778 [details] UI.7 Showing the tooltip for the 'create link locations relative to:' checkbox
Created attachment 159779 [details] Source Patch
Ok, with this latest round of screenshots, I included: 1) Wording changes following Dani Megert and Paul Webster's comments. 2) A tooltip clarifying what happens when the 'relative to' checkbox isn't set 3) Wording changes in the preference panel. Please let me know if there's anything else with this Dialog UI. Otherwise I'll flag this bug as resolved. Thanks,
+1 on overall UI. For the tooltip in #7, it seems odd to have a tooltip that explains what happens when you *don't* choose the selected item. What about: "Link locations will be relative to the project location, rather than absolute path locations." (and vice versa when the other is selected). This minor point can be debated in another bug if needed. To clarify my suggestion for #4, the wording is different because there's no "operation" being chosen in the radio buttons.
Created attachment 159830 [details] UI.7a Showing the tooltip for the 'create link locations relative to:' checkbox
Created attachment 159831 [details] UI.7b Showing the tooltip for the 'create link locations relative to:' checkbox
(In reply to comment #96) > +1 on overall UI. > > For the tooltip in #7, it seems odd to have a tooltip that explains what > happens when you *don't* choose the selected item. What about: > > "Link locations will be relative to the project location, rather than absolute > path locations." (and vice versa when the other is selected). > This minor point can be debated in another bug if needed. > Sounds good. I changed the code (see UI 7a and 7b) so that it displays a positive statement in all cases, and the statement changes whether the checkbox is set or not. Also, I changed the text slightly to "Link locations will be relative to a path variable, rather than absolute path locations." Since it's not necessarily relative to the project location, but really to the path variable selected in the combo box.
Ok, I think we've addressed all the issues raised in this bug. I'll commit the changes to head and mark it as fixed.
*** Bug 269807 has been marked as a duplicate of this bug. ***
fixed in I20100311-1616
