[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).

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.
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?
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,

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