Community
Participate
Working Groups
I suggest we change the text for the "Open Untitled Text File" menu option for two reasons: 1) you are not actually opening a file, you are creating a new file hence use of "open" is misleading 2) it is a bit lengthy for no real benefit. I suggest changing it to one of the following: "New Text File" "New File" "New Blank File"
I think that the "File -> Open Untitled File" feature would be more intuitively discovered by new users under "File -> New -> Untitled File". (Old users, too... <g>)
I totally agree with Car on this one. This menu item really drives me nuts on so many levels. :)
I suggest we turn the two options File > New > File AND File > Open Untitled Text File... into one. How about changing the File > New > File option to be more streamlined. So rather then prompting for a project and file name etc... just open an untitled file as soon as I select File > New > File , Then when I go to save we prompt (as we do not for untitled text file) for where it should go. This is often what I expect from File > New > File anyway as I am just creating a file to take some notes and don't want to decide where to put it yet. This makes the exising new file support easier to understand and does not add yet another item to the File menu for 3.1
Merging it into File>New>File would be my favorite. This raises the issue of how to open an editor of a specific type such as a Java editor. By deciding about the name and the location up-front, we never hit that problem. Assuming that we could find a solution how to pick the right editor, we'd stress upper layers' ability to build models for nonexistent resources. Alternatively, when starting with the default text editor we are facing our inability to react on file type changes cause by Save As. For example, we'd start off typing Java code, then press Ctrl+S which brings us to the Save As dialog. There we give the file a location and the '.java' extension. After pressing OK, we'd should end up with a full-fledged Java editor. Given all that I don't think we'll get something like that soon. File>New>Untitled File works well. We'd have to tackle the following issues. The whole point of the action is to give the user an editor without the need of filling out an wizard. Thus, the action must be placed into the New submenu explicitly via XML. In order to do that, Platform internal knowledge about the menu groups is needed. This way, the action appears in the submenu when using the File>New path but not when using the Alt+Shift+N modifier. Michael, what's the proposed/right way to get the action consistently into the New submenu?
This is sounding good<g>. More comments however. >>Merging it into File>New>File would be my favorite. This raises the issue of how to open an editor of a specific type such as a Java editor. * I suggest we drop that support (opening File > New > File opens the java editor when foo.java is the name of the new file) since we don't intend users will use simple file to create a Java class >> By deciding about the name and the location up-front, we never hit that problem. Actually we have this problem right now with "File > Open Untitled Text File..." >> Assuming that we could find a solution how to pick the right editor, we'd stress upper layers' ability to build models for nonexistent resources. Alternatively, when starting with the default text editor we are facing our inability to react on file type changes cause by Save As. I agree that we might be introducing the occational case where you (in the past) would have created Foo.java (using File > New > File) and gotten the java editor right away, however other then this there is no editer switching on file rename working as far as I can see so I think this is not really important. We stick with the editor you started with. You can re-open the file in a different editor if you want to. Agree that editors will have to work with files whose contents may be broken (e.g. plugin.xml or *.java) but we should support that now. >> After pressing OK, we'd should end up with a full-fledged Java editor Hmm. but it seems we don't do it now when you do Save As from foo.txt to foo.java I get a sort of a half supported java editor with errors but no syntax highlighting etc... (probably file is not on the build path) >> This way, the action appears in the submenu when using the File>New path but not when using the Alt+Shift+N modifier. One question, why not have it show up for Alt+Shift+N ? The other point is as you say, it should be an easy way to just get some white space to type some text, thats the most important, how we transition you to another editor might not be the biggest concern as New wizards (for what you know you want to create) are for this.
Created attachment 16308 [details] Strange state transitioning from text file to java
>> One question, why not have it show up for Alt+Shift+N ? I'd like to have it there but without being a New wizard contribution. Having an action contribution is unfortunately not enough. See my previous comment.
Michael, I suggest that Platform UI enhances the current org.eclipse.ui.newWizards extension point with an optional attribute "canFinish" which would allow to directly click "Finish" instead of enforcing to step to the next page? This would also allow us to add a new wizard shortcut to the page layout.
We could probably make this implicit by just having the wizard not provide any pages. If no pages are added then simply perform finish. This would be tricky for activating the wizard from within the new wizard selection dialog, however. We'd either need to eagerly load wizard classes to see if they have any pages or simply provide an empty finish page in the case where they don't.
Each client would then have to provide such an empty wizard class unless Platform UI provides it as API. What speaks against the proposed change to org.eclipse.ui.newWizards extension point?
Well, the wizard would be "empty" in that it would provide no pages but it would still require implementation for its finish method. In this scenario we'd be on the lookout for wizards that require no human intervention and treat them special.
Yes, that would solve the problem too. Tod, what does P4 mean? We really need to get this out of the File menu.
P4 means it is minor and so I will focus on either priorities. If you don't think so I can raise it to P2.
Tod, I'd be willing to look at this if you don't have the time.
I'm happy with P4 as long as it goes into 3.1 ;-) We will definitely move the item out of File for 3.1. This means the user will have to press "Next" and then press "Finish" on the empty page.
Moving to Kim as she offered to look at this if tim constraints cause a problem
Please remove this new action for 3.1.
Erich, Jim please review and approve the following API change: #1) add two new attributes to the new wizards ext. pt. wizard element: canFinishEarly - wizard has ability to finish without flipping to any pages hasPages - wizard has pages, even if it can finish early, user has other options Wizards may not specify that they have no pages and can not finish early at the same time 2) IWizardDescriptor needs new methods, roughly described below: /** * Answer true if this wizard is able to finish without loading any pages. * When finish is pressed in the context of the <code>WizardSelectionPage</code> * this wizard will be instantiated and then performFinish() will be called * without creating any pages. * @return true if this wizard can finish immediately */ public boolean canFinishEarly(); /** * Answer true if this wizard is has any pages. This allows a wizard to * indicate that it can both finish or offer next pages to work with. * WizardSelectionPage assumes that next is always an option however in some * cases it may not be. * @return true if this wizard has wizard pages */ public boolean hasPages();
approved Typo: "Answer true if this wizard is has any pages." extraneous "is"
The API is now in HEAD with minor changes to the doc. Because the IWizardDescriptor isn't necessarily bound to a particular wizard container (for RCP) I made the text more suggestive of this.
moving bug back to Dani to complete this change
I will try to put this in for M7 (depends on the outcome of the test pass).
Just to double-check: do you intend to release that to M7 or will this be RC1?
RC1 likely.
Afaik this is tagged M7 on the polish list but I agree that it's safer to finish this for RC1.
Michael and I had discussed whether to push the 0-page wizard idea all the way down to JFace (i.e. with new API on IWizardNode, and logic in WizardSelectionPage). I guess it's late for that though, and making the change locally to the workbench to satisfy this polish item is acceptable.
Released into M7 (I2005050512-1600) after confirming with Doug that the Platform UI changes are (and remain) in M7.
Verified that the entry is gone from the File menu. - 'Untitled text file' does not show up directly in File>New (Alt+Shift+N) in the Java Perspective - wouldn't we want it to be there? It does show up in the Resource Perspective, but I would expect it to be there in all (most) perspectives. - When opening the File>New>Other (Ctrl+N) wizard chooser, double clicking doesn't work on 'Untitled text file'. Filed bug 95100.
(In reply to comment #28) > - 'Untitled text file' does not show up directly in File>New (Alt+Shift+N) in > the Java Perspective - wouldn't we want it to be there? It does show up in the > Resource Perspective, but I would expect it to be there in all (most) > perspectives. This is not true - it correctly shows up on a fresh workspace using I20050513-0010
