Community
Participate
Working Groups
Spawned from bug 301144. When will we show the new "Files and Folders Operation" dialog on drop? For many users (e.g. JDT and PDE users), the new functionality is most of the time not wanted, so we should not hijack the existing drop operation (which defaults to DROP_COPY). But as people from CDT explained, this seems to be different for CDT users. Here's a strategy that could satisfy both sides and solve the problem of the one-way "Don't ask again" checkbox: - DROP_COPY stays as in 3.5, i.e. don't show the dialog and always copy (never create links) - DROP_LINK shows the dialog - we add a new preference (e.g. in General > Workspace > Linked Resources), e.g. a checkbox "Dropping files and folders shows dialog to create links". If the preference is set, the default drop operation becomes DROP_LINK (and hence the dialog appears by default). - CDT-based products can initialize this new preference with "true", so their users get the dialog out-of-the-box - the dialog could offer a checkbox to toggle the preference (e.g. with label "Show this dialog by default when dropping files and folders") The current "Always perform the selected operation in this situation" checkbox is confusing, since: - it does not spell out what "situation" is affected - there's no way to get the dialog back - the default drop cursor is always DND.DROP_COPY even if the operation will create links If there is sufficient interest, you can work out a proposal to fix these 3 problems. Otherwise, the "Always perform..." checkbox must go away.
Bugzilla's "Clone This Bug" link forgets to add the Assignee to the CC List...
I agree that "don't show this dialog again" may not be appropriate for the drop operation. In my experience, dropping stuff into Eclipse is infrequent enough to always prompt - or have the default behavior changed via Preferences only. I also agree that the "drop-to-link" gesture feels somewhat special and nonstandard. As a user, I'd ideally like to be able and pick a particular operation by the drag-and-drop gesture already (without having to do an extra choice in a dialog). Two common gestures that I've seen for resolving the copy-vs-link issue include * Windows explorer: - Leftclick-drag for the default operation (copy) - Rightclick-drag for advanced operation (including linking) * Some paint programs: - click-drag for the default operation (copy, or move) - Pressing a Ctrl modifier for special operation (e.g. clone) showing a "+" or "arrow" decorator to indicate the kind of drop operation. I guess that the first gesture is out of question since Mac's only have one mouse button, but perhaps a modifier key would be an option?
> but perhaps a modifier key would be an option? That's exactly what I'm proposing. SWT implements this in a platform-independent way with the DND.DROP_* constants.
I think that, as Martin pointed, it is more complicated than simply using the SWT constants. The default operation of the pointer varies depending on what is the default conceptual operation of objects being dragged on the target. If the object is dropped on a target that the default operation is to copy, the cursor turns to [+]. If the object is dropped on a target where the default operation is to move, the cursor has the default icon, and if the default operation is to show a menu, the cursor turns to '[+]' typically. The SWT constants alone have no clue of what is the context in which the object is being dropped, nor what should be the default operation. First, the original bug description has been partially resolved by bug 301144. There's now a preference (two actually, one for regular containers, one for virtual folders) that the user can set to either "prompt", "copy", "link" or "link and create virtual folders". Right now, the default for regular containers is "prompt". In 3.5, the equivalent behavior would be to have the default at "copy" (no dialog is shown, the file is simply copied). There's several issues at hand here: 1) What should be the default value for the preference setting? I think there's two points here: a) What is the default operation when files and folders and drag and dropped in a workspace container? Arguments could run both ways. In Eclipse, it used to be copy, since there was no other possibility, while other IDEs (Visual Studio, etc..) have typically 'link' (again, they mostly have no other possibilities too). Now in Eclipse we have a choice. I think both choices are ultimately arbitrary, and based on what people feel will be the most likely wanted operation in their domain (and likely to be different for the JDT, CDT, etc...). b) If the default operation is to copy or link, then the user has to use a special key modifier to have the window appear, it will cause that i) Very few people will discover this new feature (critical especially since users have been using Eclipse for some time, and would never even think of using the modifier, and without this feature, user have to use the cumbersome and tedious new resource dialog to create linked resources hierarchies), and ii) if the default setting is to "prompt" with the default dialog selection to "copy" (the same as 3.5), the annoyance for un-interested parties is minimal, since they only have to either hit "enter" for copy, or click the "always select this operation" and enter for reverting to the strict 3.5 behavior. So, I think the cost of not having the user discover this new feature is significant, while the inconvenience of having the dialog presented to the user possibly un-necessarily is minimal (a rare operation for JDT users after all), my opinion is to have the default preference setting to "PROMPT" and the default dialog selection to "copy". 2) What should be the pointer behavior I think the pointer behavior should be according to what is the current preference setting in effect. If the preference setting is to "copy", the pointer should be using DND.DROP_COPY. If the preference setting is to "link", the pointer should be using DND.DROP_LINK. If the preference setting is to "link and create virtual folders", the pointer should be using DND.DROP_LINK. If the preference setting is to "prompt", the pointer should be using DND.DROP_COPY (same as Explorer with using control/right click drag and drop). And drag and drops between workspace resources could include DND.DROP_MOVE when appropriate too. Does that make sense?
> So, I think the cost of not having the user discover this new feature is significant, while the inconvenience of having the dialog presented to the user possibly un-necessarily is minimal (a rare operation > for JDT users after all), my opinion is to have the default preference setting to "PROMPT" and the default dialog selection to "copy". Oh, also, if the current setting isn't 'prompt' for some reason, pressing the modifier key (control) would make the dialog appear.
A possible compromise between the option of having "prompt" or "copy" by default, is that the dialog would prompt by default, but would have the 'always perform this operation' checkbox set too, so that once the user clicks 'OK', the dialog won't show up anymore.
According to http://wiki.eclipse.org/Polish3.6 this issue seems to be quite important. Do we have an agreement on what the right fix is?
Serge asked me to take a look at this. Forgive me for restating some of what has been said above, but I thought it might be helpful. (In reply to comment #4) > The SWT constants alone have no clue of what is the context in which the object > is being dropped, nor what should be the default operation. This is not true. SWT is suggesting the appropriate operation in the DropTargetEvent detail. Yes, the receiver is free to ignore/change the suggestion given the context, but the SWT suggestion is based on the modifier keys. If there is no modifier key, the constant is DND.DROP_DEFAULT, and all the rules of negotiation apply. But if the user has pushed a modifier, then the operation is interpreted as appropriate for the platform. This is important because we should always honor any modifier key in play. When the user presses a modifier key, they are the ones saying what the drag operation means. SWT handles mapping the modifier keys to the appropriate constant per platform. For example, on Windows, Ctrl = COPY (no prompt required) Alt = LINK (there may be a prompt required if there are multiple valid ways to link to the target and the preference does not indicate what to do) Shift = MOVE (no prompt required) So we are *not free* to decide that Ctrl = Prompt. There is no SWT constant for PROMPT and we need to respect the SWT determination because it is smart about what key means what on each platform. (It's too bad there's not DND.DROP_PROMPT defined by SWT! That's where the decision needs to be made, using the appropriate platform-specific gesture.) From an implementation point of view, we aren't saying "what should the pointer be?" We should only be deciding, "how should we interpret DND.DROP_DEFAULT"? If the SWT drop target detail constant is DND.DROP_MOVE, DND.DROP_COPY, or DND.DROP_LINK, this is what we do, and if we can't support that operation, we say DND.DROP_NONE, because the operation specifically requested by the user is not available. In the case of DND.DROP_LINK, there is more than one way to link (sometimes) so we might need to prompt, depending on the value of the preference. If the preference or the context makes it clear that only one kind of link is appropriate, then no prompt is needed. Ideally, in the case of DND.DROP_LINK, we should only be prompting for different kind of links (copy should not even be one of the choices.) There is a preference in place that drives what the default behavior should be, and this preference should be consulted *only* when the drop event specifies DND.DROP_DEFAULT. Given all this, the coding for targets who are getting the drop target event should be very straightforward and consistent, and all we are debating here is the question: "what should be the default value of the preference?" Markus is suggesting "COPY" (for the SDK) because he believes that for JDT and PDE users, the new functionality is usually not wanted, and CDT could always set it PROMPT or one of the link variants. I would agree with this idea if there were a way for a user, during the drag, to "force" a prompt to see what was available, like on Windows, where you can use the second mouse button to see the list of available drop actions. But we don't have a modifier key for this, so there is a discoverability problem. The user may not think to go looking in the prefs, and if they are in the middle of a drag, it's too late. Serge is worried about the discoverability of the new function, so he wants "PROMPT" with a default of COPY. I think this is quite reasonable, but I'm worried about the burden on the user of figuring out all those link intricacies if they don't care. However, as long as COPY is the default, and first in the list, I think we are okay. Martin points out that the operation is not all that common so that the cost of a prompt may not even warrant a "don't show me again" and that if the user is annoyed by constant prompting, they will go looking in the preferences. I suggest: - the default is PROMPT (for discoverability). The default selection in the prompt is "copy" and "copy" is always first in the dialog. (ie, the first word the user should have to read is "Copy") - *don't* put a "always perform this operation" toggle because as we've discussed before, it's not a simple "always do this" choice, it is slightly different depending on the source and target. - *do* put a link to the preference page on the prompt dialog. This way, the user can visit the preference page and think more about it if they wish, and the link also serves as a way to teach the user that there is a preference that can make this dialog go away if they are tired of it. The user can also push the modifier key to force a copy and they will never see the dialog. I think this resolves all the issues...comments?
(In reply to comment #8) > I suggest: It looks like a reasonable compromise. I like it. > The user can also push the modifier key to force a copy and they will never see > the dialog. This means we would have to agree that a key modifier is used to force some behavior without prompt. I think we could use this modifier to delete content on disk on project delete for instance. Maybe we should not introduce it so eagerly but discuss at the beginning of 3.7.
(In reply to comment #9) > (In reply to comment #8) > > I suggest: > > It looks like a reasonable compromise. I like it. > > > The user can also push the modifier key to force a copy and they will never see > > the dialog. > > This means we would have to agree that a key modifier is used to force some > behavior without prompt. I think we could use this modifier to delete content > on disk on project delete for instance. Maybe we should not introduce it so > eagerly but discuss at the beginning of 3.7. It means we would be honoring what SWT suggests in the drop target event. So if SWT says DND.DROP_COPY then a copy is performed. If there is some action that implies a delete I would expect the normal "do you want to delete" prompts? All I was suggesting was that a key modifier that says COPY or LINK should not cause the "which operation" prompt because the user has pre-answered the question...
That sounds fine to me.
One more thing: At the moment, the Project Explorer explicitely overrides the DND.DROP_DEFAULT setting when the user drag and drops from Windows Explorer to DROP_COPY. This is to fix Bug 16308. My take on this, is that we should revert it to DND.DROP_DEFAULT (when the default settings is 'prompt'), since it displays the dialog box. Then, if the default in the preferences is not 'prompt', should we set it to either DROP_COPY (if the default is copy) or DROP_LINK (if the default is link or link and create virtual folders)? I'm guessing yes, but I'm not sure.
(In reply to comment #12) > One more thing: > > At the moment, the Project Explorer explicitely overrides the DND.DROP_DEFAULT > setting when the user drag and drops from Windows Explorer to DROP_COPY. This > is to fix Bug 16308. > > My take on this, is that we should revert it to DND.DROP_DEFAULT (when the > default settings is 'prompt'), since it displays the dialog box. > > Then, if the default in the preferences is not 'prompt', should we set it to > either DROP_COPY (if the default is copy) or DROP_LINK (if the default is link > or link and create virtual folders)? > > I'm guessing yes, but I'm not sure. Actually, if we do it, it would vary according to the target too. For instance, if the user hover the mouse over a normal folder, the default might be 'copy', but over a virtual folder, it would change the 'link'. So something isn't quite clear to me yet: When I get the dragEnter, the operation is DROP_DEFAULT. Then, I get the dropValidation, and now the operation is DROP_MOVE, i.e. someone changed it to MOVE because it assumed that move was the default operation (the navigator code used to set it to copy as the default operation). So what I was saying about the DND_* flags not being sophisticated, after looking at it deeper, I still think it's still the case, because they are only good for abstracting the key modifier that the user presses. But when the user doesn't press any, it's up to the implementation to decide what should be the operation (and indirectly, the cursor shown) in that context. This is hard-coded in SWT in DropTarget.java line 299, after the drop enter go through the listeners - and come back still as "DEFAULT", then MOVE or COPY is chosen: if (event.detail == DND.DROP_DEFAULT) { event.detail = (allowedOperations & DND.DROP_MOVE) != 0 ? DND.DROP_MOVE : DND.DROP_NONE; } So basically, we can't *not* set a value, otherwise one is chosen by SWT automatically - most likely the wrong one. Does that make sense?
Created attachment 165394 [details] ImportTypeDialog change with the link to the preferences
Created attachment 165395 [details] Patch (without API change) Removes the 'always perform this operation' checkbox, instead displays a link to the preferences.
Comment on attachment 165395 [details] Patch (without API change) ### Eclipse Workspace Patch 1.0 #P org.eclipse.ui.ide Index: src/org/eclipse/ui/ide/dialogs/ImportTypeDialog.java =================================================================== RCS file: /cvsroot/eclipse/org.eclipse.ui.ide/src/org/eclipse/ui/ide/dialogs/ImportTypeDialog.java,v retrieving revision 1.9 diff -u -r1.9 ImportTypeDialog.java --- src/org/eclipse/ui/ide/dialogs/ImportTypeDialog.java 19 Apr 2010 14:50:32 -0000 1.9 +++ src/org/eclipse/ui/ide/dialogs/ImportTypeDialog.java 20 Apr 2010 08:54:35 -0000 @@ -22,6 +22,7 @@ import org.eclipse.jface.window.Window; import org.eclipse.swt.SWT; import org.eclipse.swt.dnd.DND; +import org.eclipse.swt.events.SelectionAdapter; import org.eclipse.swt.events.SelectionEvent; import org.eclipse.swt.events.SelectionListener; import org.eclipse.swt.graphics.Image; @@ -32,13 +33,16 @@ import org.eclipse.swt.widgets.Composite; import org.eclipse.swt.widgets.Control; import org.eclipse.swt.widgets.Label; +import org.eclipse.swt.widgets.Link; import org.eclipse.swt.widgets.Shell; import org.eclipse.ui.ISharedImages; import org.eclipse.ui.PlatformUI; +import org.eclipse.ui.dialogs.PreferencesUtil; import org.eclipse.ui.internal.ide.IDEInternalPreferences; import org.eclipse.ui.internal.ide.IDEWorkbenchMessages; import org.eclipse.ui.internal.ide.IDEWorkbenchPlugin; import org.eclipse.ui.internal.ide.IIDEHelpContextIds; +import org.eclipse.ui.internal.ide.dialogs.LinkedResourcesPreferencePage; import org.eclipse.ui.internal.ide.dialogs.RelativePathVariableGroup; import org.eclipse.ui.internal.ide.misc.OverlayIcon; import org.eclipse.ui.plugin.AbstractUIPlugin; @@ -80,8 +84,7 @@ */ public final static int IMPORT_VIRTUAL_FOLDERS_AND_LINKS = 2; - private Button alwaysPerformThisOperation = null; - + private final static int IMPORT_WITHOUT_PROMPT = 32; private Button copyButton = null; @@ -237,22 +240,31 @@ String mode = store.getString(targetIsVirtual? IDEInternalPreferences.IMPORT_FILES_AND_FOLDERS_VIRTUAL_FOLDER_MODE:IDEInternalPreferences.IMPORT_FILES_AND_FOLDERS_MODE); + if ((operationMask & IMPORT_WITHOUT_PROMPT) != 0) { + if (hasFlag(IMPORT_COPY)) + currentSelection = IMPORT_COPY; + if (hasFlag(IMPORT_LINK)) + currentSelection = IMPORT_LINK; + if (hasFlag(IMPORT_MOVE)) + currentSelection = IMPORT_MOVE; + return Window.OK; + } if (mode.equals(IDEInternalPreferences.IMPORT_FILES_AND_FOLDERS_MODE_PROMPT)) return super.open(); if (mode.equals(IDEInternalPreferences.IMPORT_FILES_AND_FOLDERS_MODE_MOVE_COPY) && hasFlag(IMPORT_COPY)) { - this.currentSelection = IMPORT_COPY; + currentSelection = IMPORT_COPY; return Window.OK; } if (mode.equals(IDEInternalPreferences.IMPORT_FILES_AND_FOLDERS_MODE_MOVE_COPY) && hasFlag(IMPORT_MOVE)) { - this.currentSelection = IMPORT_MOVE; + currentSelection = IMPORT_MOVE; return Window.OK; } if (mode.equals(IDEInternalPreferences.IMPORT_FILES_AND_FOLDERS_MODE_LINK) && hasFlag(IMPORT_LINK)) { - this.currentSelection = IMPORT_LINK; + currentSelection = IMPORT_LINK; return Window.OK; } if (mode.equals(IDEInternalPreferences.IMPORT_FILES_AND_FOLDERS_MODE_LINK_AND_VIRTUAL_FOLDER) && hasFlag(IMPORT_VIRTUAL_FOLDERS_AND_LINKS)) { - this.currentSelection = IMPORT_VIRTUAL_FOLDERS_AND_LINKS; + currentSelection = IMPORT_VIRTUAL_FOLDERS_AND_LINKS; return Window.OK; } @@ -331,22 +343,6 @@ IPreferenceStore store = IDEWorkbenchPlugin.getDefault().getPreferenceStore(); store.putValue(IDEInternalPreferences.IMPORT_FILES_AND_FOLDERS_RELATIVE, Boolean.toString(variable != null)); - if (alwaysPerformThisOperation.getSelection()) { - String mode = IDEInternalPreferences.IMPORT_FILES_AND_FOLDERS_MODE_PROMPT; - switch(currentSelection) { - case IMPORT_COPY: - case IMPORT_MOVE: - mode = IDEInternalPreferences.IMPORT_FILES_AND_FOLDERS_MODE_MOVE_COPY; - break; - case IMPORT_LINK: - mode = IDEInternalPreferences.IMPORT_FILES_AND_FOLDERS_MODE_LINK; - break; - case IMPORT_VIRTUAL_FOLDERS_AND_LINKS: - mode = IDEInternalPreferences.IMPORT_FILES_AND_FOLDERS_MODE_LINK_AND_VIRTUAL_FOLDER; - break; - } - store.putValue(targetIsVirtual? IDEInternalPreferences.IMPORT_FILES_AND_FOLDERS_VIRTUAL_FOLDER_MODE:IDEInternalPreferences.IMPORT_FILES_AND_FOLDERS_MODE, mode); - } } super.buttonPressed(buttonId); } @@ -466,16 +462,32 @@ currentSelection = IMPORT_LINK; parent.getShell().setText(IDEWorkbenchMessages.ImportTypeDialog_titleFilesLinking); } - alwaysPerformThisOperation = new Button(parent, SWT.CHECK); - alwaysPerformThisOperation.setText(linkIsOnlyChoice? IDEWorkbenchMessages.ImportTypeDialog_alwaysUseLocationWhenLinkingFiles: IDEWorkbenchMessages.ImportTypeDialog_alwaysPerformThisOperation); - gridData = new GridData(GridData.HORIZONTAL_ALIGN_BEGINNING); - gridData.horizontalIndent = convertHorizontalDLUsToPixels(IDialogConstants.HORIZONTAL_MARGIN); - alwaysPerformThisOperation.setLayoutData(gridData); - + createLinkControl(parent); refreshSelection(); return composite; } + private Control createLinkControl(Composite composite) { + Link link= new Link(composite, SWT.WRAP | SWT.RIGHT); + link.setText(IDEWorkbenchMessages.ImportTypeDialog_configureSettings); + link.addSelectionListener(new SelectionAdapter() { + public void widgetSelected(SelectionEvent e) { + openSettingsPage(); + } + }); + GridData gridData= new GridData(GridData.FILL, GridData.CENTER, true, false); + gridData.horizontalIndent = convertHorizontalDLUsToPixels(IDialogConstants.HORIZONTAL_MARGIN); + link.setLayoutData(gridData); + link.setFont(composite.getFont()); + + return link; + } + + protected void openSettingsPage() { + String prefID = LinkedResourcesPreferencePage.PREF_ID; + PreferencesUtil.createPreferenceDialogOn(getShell(), prefID, new String[] {prefID}, null).open(); + } + protected Control createMessageArea(Composite parent) { Composite composite = new Composite(parent, 0); GridData gridData = new GridData(SWT.FILL, SWT.FILL, true, true); @@ -540,10 +552,36 @@ * @return the appropriate import mask given the files dropped on the target */ private static int selectAppropriateMask(int dropOperation, IResource[] resources, IContainer target) { - int mask = ImportTypeDialog.IMPORT_VIRTUAL_FOLDERS_AND_LINKS | ImportTypeDialog.IMPORT_LINK; - if (!target.isVirtual() && (dropOperation != DND.DROP_LINK)) - mask |= ImportTypeDialog.IMPORT_COPY; - if (areOnlyFiles(resources)) + boolean onlyFiles = areOnlyFiles(resources); + int mask = selectAppropriateMask(dropOperation, target, onlyFiles); + return mask; + } + + /** + * @param dropOperation + * @param target + * @param onlyFiles + * @return the appropriate import mask given the objects dropped on the target + */ + private static int selectAppropriateMask(int dropOperation, + IContainer target, boolean onlyFiles) { + int mask; + switch (dropOperation) { + case DND.DROP_LINK: + mask = ImportTypeDialog.IMPORT_VIRTUAL_FOLDERS_AND_LINKS | ImportTypeDialog.IMPORT_LINK; + break; + case DND.DROP_COPY: + if (!target.isVirtual()) { + mask = ImportTypeDialog.IMPORT_COPY | ImportTypeDialog.IMPORT_WITHOUT_PROMPT; + break; + } // otherwise, fall to default + case DND.DROP_MOVE: // always for prompt + default: + mask = ImportTypeDialog.IMPORT_VIRTUAL_FOLDERS_AND_LINKS | ImportTypeDialog.IMPORT_LINK; + if (!target.isVirtual()) + mask |= ImportTypeDialog.IMPORT_COPY; + } + if (onlyFiles) mask |= ImportTypeDialog.IMPORT_FILES_ONLY; return mask; } @@ -560,11 +598,8 @@ * @return the appropriate import mask given the files dropped on the target */ private static int selectAppropriateMask(int dropOperation, String[] names, IContainer target) { - int mask = ImportTypeDialog.IMPORT_VIRTUAL_FOLDERS_AND_LINKS | ImportTypeDialog.IMPORT_LINK; - if (!target.isVirtual() && (dropOperation != DND.DROP_LINK)) - mask |= ImportTypeDialog.IMPORT_COPY; - if (areOnlyFiles(names)) - mask |= ImportTypeDialog.IMPORT_FILES_ONLY; + boolean onlyFiles = areOnlyFiles(names); + int mask = selectAppropriateMask(dropOperation, target, onlyFiles); return mask; } Index: src/org/eclipse/ui/internal/ide/IDEWorkbenchMessages.java =================================================================== RCS file: /cvsroot/eclipse/org.eclipse.ui.ide/src/org/eclipse/ui/internal/ide/IDEWorkbenchMessages.java,v retrieving revision 1.84 diff -u -r1.84 IDEWorkbenchMessages.java --- src/org/eclipse/ui/internal/ide/IDEWorkbenchMessages.java 14 Apr 2010 14:32:05 -0000 1.84 +++ src/org/eclipse/ui/internal/ide/IDEWorkbenchMessages.java 20 Apr 2010 08:54:36 -0000 @@ -786,7 +786,7 @@ public static String ImportTypeDialog_importElementsAsTooltipSet; public static String ImportTypeDialog_editVariables; public static String ImportTypeDialog_alwaysPerformThisOperation; - public static String ImportTypeDialog_alwaysUseLocationWhenLinkingFiles; + public static String ImportTypeDialog_configureSettings; // ============================================================================== // Editor Framework Index: src/org/eclipse/ui/internal/ide/messages.properties =================================================================== RCS file: /cvsroot/eclipse/org.eclipse.ui.ide/src/org/eclipse/ui/internal/ide/messages.properties,v retrieving revision 1.201 diff -u -r1.201 messages.properties --- src/org/eclipse/ui/internal/ide/messages.properties 14 Apr 2010 16:48:25 -0000 1.201 +++ src/org/eclipse/ui/internal/ide/messages.properties 20 Apr 2010 08:54:37 -0000 @@ -807,7 +807,7 @@ ImportTypeDialog_importElementsAsTooltipSet=Link locations will be relative to a path variable, rather than absolute path locations ImportTypeDialog_editVariables=Edit Variables... ImportTypeDialog_alwaysPerformThisOperation=&Always perform the selected operation -ImportTypeDialog_alwaysUseLocationWhenLinkingFiles=&Always use the selected location +ImportTypeDialog_configureSettings=<a>Configure Drag and Drop Settings...</a> # ============================================================================== # Editor Framework # ============================================================================== Index: src/org/eclipse/ui/internal/ide/dialogs/LinkedResourcesPreferencePage.java =================================================================== RCS file: /cvsroot/eclipse/org.eclipse.ui.ide/src/org/eclipse/ui/internal/ide/dialogs/LinkedResourcesPreferencePage.java,v retrieving revision 1.10 diff -u -r1.10 LinkedResourcesPreferencePage.java --- src/org/eclipse/ui/internal/ide/dialogs/LinkedResourcesPreferencePage.java 24 Feb 2010 10:11:33 -0000 1.10 +++ src/org/eclipse/ui/internal/ide/dialogs/LinkedResourcesPreferencePage.java 20 Apr 2010 08:54:37 -0000 @@ -46,6 +46,8 @@ IWorkbenchPreferencePage { private Label topLabel; + public static String PREF_ID = "org.eclipse.ui.preferencePages.LinkedResources"; //$NON-NLS-1$ + private PathVariablesGroup pathVariablesGroup; private ResourceDragAndDropEditor dragAndDropHandlingEditor;
Created attachment 165439 [details] Patch (without API change) I removed the API addition.
I almost agree with everything here i.e. we - add preference page - initially enable the feature i.e. show the dialog on drop so that it is discoverable for users - replace the 'Always perform' checkbox with a link to the preference page - set 'copy' as default in the dialog and have it on top What I'm not OK with is to use/honor the modifier at this point (like Szymon also pointed out) since we've never done that so far and also don't honor 'Shift' to allow move. One more thing we have to do: if the preference is set to link, then the drop feedback must indicate this to the user with the link icon instead of the [+].
(In reply to comment #18) > I almost agree with everything here i.e. we > - add preference page > - initially enable the feature i.e. show the dialog on drop so that it is > discoverable for users > - replace the 'Always perform' checkbox with a link to the preference page > - set 'copy' as default in the dialog and have it on top > > What I'm not OK with is to use/honor the modifier at this point (like Szymon > also pointed out) since we've never done that so far and also don't honor > 'Shift' to allow move. > > One more thing we have to do: if the preference is set to link, then the drop > feedback must indicate this to the user with the link icon instead of the [+]. That sounds good.
Created attachment 165618 [details] Patch (no API change) Includes: - add preference page - initially enable the feature i.e. show the dialog on drop so that it is discoverable for users - replace the 'Always perform' checkbox with a link to the preference page - set 'copy' as default in the dialog and have it on top - does not use/honor the modifier at this point - if the preference is set to link, then the drop feedback must indicate this to the user with the link icon instead of the [+] Note: this patch is for the ImportTypeDialog change and navigator view only (ui.ide only).
The ui.ide part is now fixed on head. The CNF part (which requires some API change to do the part where the operation changes according to the target and preference, as far as I can see, and is tracked by Bug 309985
>The ui.ide part is now fixed on head. Looks good! Verified in N20100421-2000 for the Navigator part.
>- if the preference is set to link, then the drop feedback must indicate this >to the user with the link icon instead of the [+] The longer I look at the code and think about it I think we should wait with adding LINK feedback because this has consequences to the existing code paths. So for 3.6 I think it's best we stick to the existing code/feedback. It also avoids the need for new API.
(In reply to comment #23) > >- if the preference is set to link, then the drop feedback must indicate this > >to the user with the link icon instead of the [+] > The longer I look at the code and think about it I think we should wait with > adding LINK feedback because this has consequences to the existing code paths. > So for 3.6 I think it's best we stick to the existing code/feedback. It also > avoids the need for new API. Fair enough, that means this bug should be deferred all together.
>Fair enough, that means this bug should be deferred all together. I think this bug here can be closed as we answered/decided how to do it and we file a new one about the MOVE feedback. For consistency we should remove the MOVE feedback that was introduced on the Navigator, so that it behaves the same as the Package and Project Explorer.
(In reply to comment #25) > >Fair enough, that means this bug should be deferred all together. > I think this bug here can be closed as we answered/decided how to do it and we > file a new one about the MOVE feedback. > well, I think this bug covered this discussion. From what I can understand of your comments, "I think we should wait with adding LINK feedback because this has consequences to the existing code paths. So for 3.6 I think it's best we stick to the existing code/feedback" We should remove the M7 target. Being the last day, I agree that this issue is still too fuzzy and risky to be addressed in 3.6M7. > For consistency we should remove the MOVE feedback that was introduced on the > Navigator, so that it behaves the same as the Package and Project Explorer. It was DROP_LINK that was added. Anyhow, this is now reverted with Bug 301144 to be consistent with the other views current behavior.
>It was DROP_LINK that was added. Yes, of course. I had that in mind and wrote 'MOVE'. I've opened bug 310280 and 310281 for the remaining work in Platform and JDT.
Verified in I20100429-1549
