[
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?
|
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.
open a dialog with
wizard proposal (Class/Interface/Enum/JUnit Test Case...)
user fill the wizard
value
if the package name does
not match the current location
move the file to
correct location (create the directory structure eventually)
// should ask for confirmation?
fi
This branch should IMO be avoided: from the file
and a source folder, we can infer the package and shouldn't let
user configure it in the wizard. The wizard would pre-set the
value and not let it be changed. Then if later user wants to
change package, they can use a refactoring for that.
I surely don't want to create package folders structure by hand. I expect my IDE to do it itself. I suppose that when you already have packages, your suggestion would work, but in the case of a new empty project, it just sucks to have to mkdir -p org/eclipse/xxx/yyy/zzz or even worst to use another wizard.
if the class name does
not match the current filename
rename the file //
should ask for confirmation?
fi
Same thing as above. Why letting user change
classname if we already know it?
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?
fill the file with
correct content
To me, this seems a more complicated workflow (than
the current one) with too many branches to cover all the
situations a user may face. Also, it could bring a lot more
dialogs than today.
As you present it, it seems more complicated because you focus on
the various existing configurations rather than on how to best
assist the end-user. I believe the key here isn't to let user do
everything from this workflow, but to put constraints and give them
a way to do what they most likely want less configuration and less
risk of doing something wrong. If they want to do something more
complicated, they already have all the necessary workflows to do so,
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.
Mikaël Barbero Eclipse Platform Developer & FEEP Technical Leader Eclipse Foundation T: (+33) 642 028 039
|
Attachment:
signature.asc
Description: Message signed with OpenPGP
