[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ui-best-practices-working-group] Should editor show new wizard for empty files?

Must we open the actual new file wizard dialog? I'd prefer not to help spread the plague of dialog boxes in Eclipse. Perhaps the wizard content could be embedded within the body of the newly opened editor part?

 - Stefan

On Thu, Apr 20, 2017 at 1:33 AM, Mickael Istria <mistria@xxxxxxxxxx> wrote:
On 04/20/2017 10:10 AM, MikaÃl Barbero wrote:

Le 20 avr. 2017 Ã 09:44, Mickael Istria <mistria@xxxxxxxxxx> a Ãcrit :

On 04/20/2017 09:30 AM, MikaÃl Barbero wrote:
Let's push the idea with a .java files:
I create a new file Test.java in a project.
If it's a project without Java natureÂ
 do nothing and return
 OR
 propose to add Java nature to project?
fi
Definitely the 2nd one.

if Test.java is not in a source folder
  do nothing and return
  OR
 Âpropose to make parent folder a source folder or to move to existing source folder? if parent is project, propose to create a source folder or move to existing source folder?
fi
In this case, it seems like an heuristic of reusing some source folder in the parent hierarchy if existing, or creating a new source folder for the parent project would cover that vast majority of cases. Then, for those who are in trickier state, they'd have to go to JDT project settings (which isn't difficult).

I don't think it's user friendly to use an heuristic to move the file to a location different from where the user ask to create the java file.
I think there is some misunderstanding: I'm not at all suggesting to move to another place, I'm suggesting that
* if there is one of the *parent* folder that's already configured as a JDT source folder, use this as parent folder and assume the relative path between file and source folder is the package
* if there is no parent folder configured as a JDT source, assume the folder is the source folder and set no package.



We already know it, so we can pre-fill the name field, why don't you want to let name change it in case they did a typo?
Because as the file already exists at that time, if we let user change the name, we leave room for user creating a Java error. In such case, I think it's better to force the classname to be the filename and let user refactor later if they need to.

Java imposes constraints about where Java files can be put (and JDT adds some more, e.g.g, source folders), and I have the feeling that inferring the file stats (name, location) from the Java information (package names, compilation unit name) offers a better UX than inferring the Java information from the file stats. When I develop some Java code, I think in terms of Java types, packages and not files... That's also why I love my IDE, why I use "Open Type..." dialog and not "Open Resource...", etc.
That's because you're a Java and Eclipse native ;) People coming from other tools, or from nowhere, without big experience about the language think more in term of files/resources. The proposed workflow would IMO help them.
Note that as I'm looking more and more at other languages and file format (am I becoming polyglot finally?) , I now tend to prefer workflows which are language independent and start to abandon Open Type in favor or Open Resources, because overall, Java constraints mentioned above make it pretty easy to browse a Java project with resources-based approach.


--
Mickael Istria
Eclipse developer for Red Hat Developers
My blog - My Tweets

_______________________________________________
ui-best-practices-working-group mailing list
ui-best-practices-working-group@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ui-best-practices-working-group