Open jcompagner opened 1 year ago
laeubi
commented
1 year ago @jcompagner you probably want to introduce a system property or preference here, the problem with "just switch" something is that there will always be someone that needs the previous behavior.
I could also think about a static method that allows to set the default shell style for dialogs...
vogella
commented
1 year ago I think PRIMARY_MODAL would make sense as default, please provide PR, System property for switching back to the old behavior is a good idea from @laeubi
jcompagner
commented
1 year ago I think we already switched it for WizardDialogs... (Lars already did that for me ;) )
I do wonder about the use case for real application model (most would only see this when really using 2 windows, we have it also in other scenarios) But i kind of hate modal dialogs anyway ;)
For example even today in my own java eclipse, i open the manifest editor, i wanted to add a package to the imported package section, i press "add" and then a modal dialog popups up.. Then i don't fully remember the exact package (i know the class name not the full package) but it is modal dialog so i need to close it to open the Open type dialog really look at the package name then reopen it again..) Now in this case i didn't really do that, because i have another instance of my eclipse open (another branch) and i quickly switched to that.. But that is even weirder that you kind of need to do that.. I think only when you really want to guide a user through something maybe it should be modal, but for the most part nothing should be modal...
vogella
commented
1 year ago I think most editing should be done inline.
i open the manifest editor, i wanted to add a package to the imported package section, i press "add" and then a modal dialog popups up..
Good case of what should be inline editing, pressing Add should add a new line in which you could enter via code completion the package. Unfortunately nobody so far took the time to update this IMHO outdated "blocking dialog" UX approach with a non-blocking one.
laeubi
commented
1 year ago Well a dialog is for getting user input and based on this input proceed with that. If blocking is not desired, a dialog is most likely the wrong UI anyways, because the downside is that a dialog can get "hidden" behind some windows and the user has to "find" it again, what can become quite annoying.
So hitting the add button for a package, but having no clue what to add is kind of a quite unusual case for me, the dialog is meant to help you search for the package, but if you don't even have a clue about the name I'm not sure it can help anything vien that PDE already offers quick-fix to import it if you use a class that has a missing import.
vogella
commented
1 year ago @laeubi I like the way you did implement the "Add" Maven dependency in the target editor. IIRC it used to be a dialog but now it is an inline entry. Much better UX IMHO.
jcompagner
commented
1 year ago Well a dialog is for getting user input and based on this input proceed with that. If blocking is not desired, a dialog is most likely the wrong UI anyways, because the downside is that a dialog can get "hidden" behind some windows and the user has to "find" it again, what can become quite annoying.
not if the dialog has the correct parent.. i am fine that the dialog is on top of its parent, it only should block, and i should be able to open something else..
So hitting the add button for a package, but having no clue what to add is kind of a quite unusual case for me, the dialog is meant to help you search for the package, but if you don't even have a clue about the name I'm not sure it can help anything vien that PDE already offers quick-fix to import it if you use a class that has a missing import.
yes you are correct this is doable with a quick fix. Problem is a bit that that is just not really in my flow. i am code completion i would love if the code completion would complete also classes that are not yet in the classpath (of the project) and right away also have the option to import it correctly...
For example i know it is something like "StringUtils" (commons lang3) but not 100% sure I don't have that package imported yet. then the flow is not so nice. If i type in StringU[code complete] i don't get anything that i want, but if i do CTRL-SHIFT-T i do get it (because i know it is in the target platform or used somewhere) Then even if i fully type it with code completion nothing happens. only when i go over it again and then do a quick fix i have those options. Its just that that flow is a bit annoying.
(but code completion can be way better anyway in eclipse, especially when i talk to co workers of mine that also are very used to IntelliJ)
laeubi
commented
1 year ago I like the way you did implement the "Add" Maven dependency in the target editor.
if you mean the new table-editor this was done by @ptziegler here:
as you can see there it requires some effort to find a good and clean UI something that is often not invested, so it is more than making a dialog modal / app modal...
Add should add a new line in which you could enter via code completion the package. Unfortunately nobody so far took the time to update this IMHO outdated "blocking dialog" UX approach with a non-blocking one.
To be fair it works that way already in the source tab
See:
https://github.com/eclipse-platform/eclipse.platform.ui/blob/master/bundles/org.eclipse.jface/src/org/eclipse/jface/dialogs/Dialog.java#L442
For us we don't want that, we never want dialogs to be Applicaiton Modal that is just very annoying that they block also other windows that are not directly a parent of this dialog What we want is PRIMARY_MODAL (kind of by default for everything)
We already created for example a full copy of the MessageDialog to be able todo: https://github.com/Servoy/servoy-eclipse/blob/master/com.servoy.eclipse.core/src/com/servoy/eclipse/core/util/ServoyMessageDialog.java#L159
But Dialogs are now also deprecating the constructor like https://github.com/eclipse-platform/eclipse.platform.ui/blob/master/bundles/org.eclipse.ui.workbench/Eclipse%20UI/org/eclipse/ui/dialogs/ListSelectionDialog.java#L106
to use the Builder, problem is then we don't control that modal style property at all i kind of need to extends that class and then call a deprecated constructor... and then overrride the protected setShellStyle to be able to switch to primary modal. But this is all a bit annoying, so the question is can we just switch this default behavior to always set primary modal not application modal for all dialogs?