Summary: | Problems running E4 with non-default Display object | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Andrew Johnson <andrew_johnson> |
Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | loskutov, tom.schindl, wim.jongman |
Version: | 4.18 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows 10 | ||
Whiteboard: |
Description
Andrew Johnson
2020-10-26 08:14:23 EDT
There are various reasons why people used Display.getDefault() - - some just are running in a non UI thread - some don't know better - some don't care because it seem to be irrelevant for the code where it was originally used So simply replacing getDefault() with getCurrent() via search/replace will not work. What is the use case? The use case for me would be preparing an RCP application for conversion to RAP where Display.getDefault works differently. I could start the conversion by using RAP libraries instead of org.eclipse.ui and try to get the application properly working under RAP. However there are certain problems which need to be fixed and it is easier to do those in the RCP application where everything should still work before starting the proper RAP migration. E.g. https://wiki.eclipse.org/RAP/FAQ#Why_does_Display.23getDefault.28.29_work_different_than_in_SWT My idea was to run my RCP application in an environment where Display.getDefault() in my code would cause problems and I could convert them to Display.getCurrent() if the thread is a UI thread, or use another way if it is a non-UI thread. I then found I had problems with standard Eclipse code which got in the way of me doing the conversion. I would not be running in this mode in production, it was just for debugging such as bug 323903. IIRC when we implemted the RAP-Port we disabled the CSS-Engine because it made no real sense because RAP has CSS-Support to theme your stuff |