Community
Participate
Working Groups
Created attachment 279711 [details] Video Bug 548877 introduced inline editing in the project explorer. Thanks for that. But if I rename certain resources, for example a folder, I still get a rename dialog AFTER the inline editing. See attached video.
Andrew, can you please have a look?
The rename action still relies on the refactoring action (that's desired and not something we should/can change). At the moment, to minimize the risk, the inline renaming will show the dialog whenever there is a refactoring handler for the rename action; this allows for example to get the preview. We could imagine a way to perform the refactoring action without having the dialog for cases where the refactoring action provides no option. However, I don't know how easy it would be to implement. I'm removing Andrew as assignee at the moment to make it clear that anyone is free to work on it. I'll let Andrew mark himself as assignee when he starts working on it (if ever ;).
(In reply to Mickael Istria from comment #2) > The rename action still relies on the refactoring action (that's desired and > not something we should/can change). At the moment, to minimize the risk, > the inline renaming will show the dialog whenever there is a refactoring > handler for the rename action; this allows for example to get the preview. The preview just says "A" will be renamed to "B", so what's the value? I'm sorry I didn't validated the original feature during implementation, because I could not imagine that "inline rename" makes the rename process *longer*, not faster. 4.12: F2 -> typing -> Enter 4.13: F2 -> typing -> Enter -> Enter (+ surprise about dialog) This is surprising at least, or, in my POV, doesn't make any sense. (In reply to Mickael Istria from comment #2) > We could imagine a way to perform the refactoring action without having the > dialog for cases where the refactoring action provides no option. However, I > don't know how easy it would be to implement. As long as we are thinking about a proper "final" solution, we require a possibility to disable this "inline rename" at least via product customization (without UI), or, if anyone needs, with an extra new entry on preferences UI page. I will add this on the internal list of patches that we (Advantest) expect to be fixed in 4.14 before we can migrate. We plan contribute this "product customization" way to disable this "inline renaming" if there will be no other way to get rid of the extra dialog.
(In reply to Andrey Loskutov from comment #3) > The preview just says "A" will be renamed to "B", so what's the value? Some cases of rename are refactoring and build complex composite actions. For those, the Preview is valuable. Some refactoring actions also have options (java refactoring among them) that needs the user to review them. So for this case, we can't even skip the dialog. At the moment, I think the LTKRenameAction could be tweaked so that if it's a plain resource without specific refactoring handler and a name is pre-set, then we can skip the dialog and just apply. But for the case when the dialog has options, I don't think it's possible to skip it, nor that it's possible from inside the RenameHandler to know in advance whether there will be need for a dialog or not at the moment. Maybe we could add some extra API to LTKRenameAction to inform about that in advance.
(In reply to Mickael Istria from comment #4) > But for the case when the dialog has options, I don't think it's possible to > skip it, nor that it's possible from inside the RenameHandler to know in > advance whether there will be need for a dialog or not at the moment. Maybe > we could add some extra API to LTKRenameAction to inform about that in > advance. Definitely that needs to happen I do not want to start inline and see a dialog after 'Enter'. This will get a -2 in the future from me.
(In reply to Dani Megert from comment #5) > Definitely that needs to happen I do not want to start inline and see a > dialog after 'Enter'. This will get a -2 in the future from me. In a first iteration, we may make it a preference "always use inline renaming", as the case of refactoring dialog being important typically doesn't affect some EPP packages (like Rust or JavaScript) where inline renaming is nicer than dialog.
Thanks for the feedback Dani and Andrey. I'm working on adressing the abovementioned issues and have been making progress.
New Gerrit change created: https://git.eclipse.org/r/150517
Created attachment 280146 [details] Don't show rename dialog for simple changes The latest patch I submitted does not show the dialog for cases where the rename operation only affects the file being renamed. @Andrey & Dani, let me know your thoughts.
New Gerrit change created: https://git.eclipse.org/r/150854
New Gerrit change created: https://git.eclipse.org/r/150855
New Gerrit change created: https://git.eclipse.org/r/150856
New Gerrit change created: https://git.eclipse.org/r/151857
Gerrit change https://git.eclipse.org/r/150517 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=7eddcb88ea104856c43dfbe9f280e3d5598eba99
@Andrew: now the JDT part is merged, can you please rework the Platform UI part to rely on those changes. It should be a matter of reverting https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=c99322eec70b19200e9b8dbc9e45f2b25e751fdb and tweaking it a bit, isn't it? Or is there a patch ready for review on that area?
(In reply to Mickael Istria from comment #15) > Or is there a patch ready for review on that area? Yes, this is the new Platform UI patch which relies on those changes: https://git.eclipse.org/r/#/c/151857/
Gerrit change https://git.eclipse.org/r/151857 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=c99196e067da13f2b0804992922853da5931400c
New Gerrit change created: https://git.eclipse.org/r/152589
Gerrit change https://git.eclipse.org/r/152589 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=f8aa673146a84b8ed89d5f80d304095221bb148c
hi, what has been actually fixed for that. if i rename a Xtend file inline i get another rename resource dialog in project explorer after the rename. any idea? shouldnt the fix be generic (4.15.0M2)
seems to be caused by // Let user see rename dialog with preview page for composite changes or if another RefactoringProcessor is used (which may offer rename options) if (newName == null || change == null || isCompositeChange(change) || !(processor instanceof RenameResourceProcessor)) { RefactoringWizardOpenOperation op= new RefactoringWizardOpenOperation(refactoringWizard); op.run(activeShell, RefactoringUIMessages.RenameResourceHandler_title); } else { //Silently perform the rename without the dialog change.perform(new NullProgressMonitor()); } which i dont understand. why is a dialog shown if there is a composite change?
Yep. We use XText and we see in our IDE that rename on every Xtext related file opens a dialog *after* inline rename and to make things worse, the "OK" in the dialog is grayed out and user has to change already changed name *again* in order to continue. I see here at least two major issues: 1) The code obviously doesn't work with XText based files. 2) It is inconsistent. In our projects, where every second file is from an xtext related provider we have totally inconsistent "F2" behavior - sometimes it opens a dialog, sometimes "inline" edit, sometimes *both* inline editor and dialog (due point 1). As a product owner, I see no reason why should I explain users why can't they see a *consistent* rename behavior in same project for two sibling files, no one will understand / accept that. With the dialog rename was consistent - we simply had differently complex dialogs, but usage was very similar. Now it just feels wrong. Re-opening this bug for the fix problem with XText based file types. I will open another one to disable "inline" rename entirely via preference for those who want to have consistent rename behavior.
(In reply to Andrey Loskutov from comment #22) > Re-opening this bug for the fix problem with XText based file types. > I will open another one to disable "inline" rename entirely via preference > for those who want to have consistent rename behavior. Please open a new bug.
(In reply to Dani Megert from comment #23) > (In reply to Andrey Loskutov from comment #22) > > Re-opening this bug for the fix problem with XText based file types. > > I will open another one to disable "inline" rename entirely via preference > > for those who want to have consistent rename behavior. > Please open a new bug. See bug 560113 for "double rename" and bug 560100 for a new preference to disable inline rename.
Setting this to VERFIED FIXED as the related bugs (bug 560100 & bug 560113) have been fixed.
