Community
Participate
Working Groups
When creating a new file from the New > File menu, type foo/bar/Some.properties as file name causes an error "/ is an invalid character in resource name 'foo/bar/Some.properties'." This forces users to first create the parent folders from the new Folder wizard, which is clearly a suboptimal workflow. Most modern IDEs allow the creation of a new File by allowing path+filename. Would be awesome if Eclipse could also create the file hierarchy when necessary.
Created attachment 260454 [details] Providing a path You can do it, but the path needs to be done in the parent folder area. It seems weird until I realized that having directories in the "File name:" widget was equally weird.
Marking as WORKSFORME.
This definitely counts as a UX fail to me. Can't we just have 1 input text, prepopulated with the current path?
(In reply to Fred Bricon from comment #3) > This definitely counts as a UX fail to me. > > Can't we just have 1 input text, prepopulated with the current path? +1, Gerrit reviews welcome
New Gerrit change created: https://git.eclipse.org/r/69010
https://git.eclipse.org/r/69010 fixes the issue. I have tested it on Windows and Linux.
Thanks for the speedy patch Snjezana. I posted some comments on the patch. This ResourceAndGroupContainer is used in other areas (the SaveAsDialog and the NewFolderWizardPage) and if we're going to fix this in one place, we should fix them in all. But more to the point, having two areas for path names is kinda silly and if we're going to revisit one for UX reasons then we should do this right. If we allow specifying new paths in the file name area, then we can get rid of the parent path area to the top and just use the path selection in the directory-selection area.
(In reply to Brian de Alwis from comment #7) > Thanks for the speedy patch Snjezana. I posted some comments on the patch. > This ResourceAndGroupContainer is used in other areas (the SaveAsDialog and > the NewFolderWizardPage) and if we're going to fix this in one place, we > should fix them in all. But more to the point, having two areas for path > names is kinda silly and if we're going to revisit one for UX reasons then > we should do this right. I am not sure what change exactly you want. I could create a wizard with a field (as it is in Intelij IDEA), but maybe some users would want the existing behaviour. The current patch won't change the behaviour of the existing wizard. > > If we allow specifying new paths in the file name area, then we can get rid > of the parent path area to the top and just use the path selection in the > directory-selection area. > The ResourceAndGroupContainer is used in other locations too (Save As dialog, New Folder wizard), and > those locations should probably be fixed too. If this patch is acceptable, I can add it to other places, too. BTW I have also fixed a bug that can be reproduced in the following way: - enter an invalid file name ("/", for instance) - click the Advanced button You will get the "Unhandled event loop exception" exception.
I have updated the patch - https://git.eclipse.org/r/69010.
(In reply to Snjezana Peco from comment #8) > I could create a wizard with a field (as it is in Intelij IDEA), but maybe > some users would want the existing behaviour. > The current patch won't change the behaviour of the existing wizard. The patch should change the existing wizard so that the folder and the file name is in one field, prepopulated with the current path. See Comment 3 and Comment 4.
(In reply to Lars Vogel from comment #10) > (In reply to Snjezana Peco from comment #8) > > I could create a wizard with a field (as it is in Intelij IDEA), but maybe > > some users would want the existing behaviour. > > The current patch won't change the behaviour of the existing wizard. > > The patch should change the existing wizard so that the folder and the file > name is in one field, prepopulated with the current path. See Comment 3 and > Comment 4. That would require the API changes. Do you really want to change the mentioned wizards and dialog?
(In reply to Snjezana Peco from comment #11) > That would require the API changes. Do you really want to change the > mentioned wizards and dialog? I think we could change the UI representation of the wizard without API breakage. But I'm also OK with fixing the behavior of the existing UI, if that is what you prefer.
Let's try it for 4.13; I'll try to rebase Snjezana patch soon.
We have many wizards. If we start to add that feature it would have to be added everywhere. I don't think anyone would be willing to take up that work.
