I strongly support this initiative.
How ambitious do we want to get? We could get a lot of mileage by just reducing the number of modal event loops and dialog boxes, but I'd suggest we set the more ambitious long-term goal of removing all dialog boxes and modal event loops from the Eclipse platform.
Let's plan out what needs to happen to make this a reality. I'd suggest the following subtasks:
1. Create a notification API (probably by porting the Mylyn one).
2. Update the UI Guidelines to offer programmers guidance. For each UI use-case that was previously addressed by dialog boxes, we should explain what the non-modal, non-dialog alternative is, how to port from one to the other, and indicate where each alternative is preferred or permitted.
4. Create a set of utilities that make porting from dialog boxes to their nonmodal replacements easy.
5. Replace and deprecate all APIs that impose the requirement of a modal event loop upon third parties. Specifically, any method that may need to obtain a user response and then return it as a return value needs to be deprecated and replaced by a variant that will return the user response in an asynchronous callback. Rxjava-style patterns may be appropriate here.
6. Identify all the existing Eclipse dialogs and create a bug backlog for updating them. In each bug, we can discuss the nonmodal alternative that will replace the dialog box.
7. Divide up the bug backlog on #6 among the UI contributors willing to help, and work out a schedule as to when all this will occur. Based on our current burn rate, I'd expect this to be a multi-year effort... but once we have the backlog, we can work out the burn rate more accurately and figure out what we actually intend to deliver for 4.7.
Thoughts?
- Stefan
Friends of Platform UI,
This week I delivered a(nother) Android training session with Android Studio.
While I definitely think our Eclipse IDE is superior in terms of
stability and performance, I think IntelliJ has sometimes a nicer
user workflow.
The workflow in IntelliJ itself is rarely disrupted by popups or dialog.
I think we should improve support for this in our framework. Bad
examples in the Eclipse IDE are IMHO EGit, which shows popups for
almost every operation. Or the refactoring or the search operation
with their annoying dialog, typically over the interesting content.
I therefore clarified and extended a bit the 4.7 target which was
originally called "Migrate the Mylyn notification framework":
---
Support a less disruptive work mode by moving popups and dialogs to
inline editing and notifications
Eclipse popups and dialogs can distract the workflow of the user.
The Platform UI team should evaluate if popups can be avoided and
notifications or inline editing can be used.
For example, renaming a resource should be possible without a dialog.
Notifications about a finished job should not require a dialog, etc.
To archive this the Eclipse Platform UI team plans to migrate the
Mylyn notification framework to platform UI. This change has been
discussed with the Mylyn team and was well received.
----
Best regards, Lars
--
Eclipse Platform UI and e4 project co-lead
CEO vogella GmbH
Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
