Community
Participate
Working Groups
I know that it is not normal to have more than one Display and the Display JavaDoc says: >Applications which are built with SWT will almost alwaysrequire only a single >display. In particular, some platformswhich SWT supports will not allow more than >one activedisplay. In other words, some platforms do not supportcreating a new >display if one already exists that has not beensent the dispose() message. > >In SWT, the thread which creates a Displayinstance is distinguished as the user->interface threadfor that display. However, this makes it seem possible to do so, but E4 has a couple of problems. In E4Application.createE4Workbench the display passed in is stored in the context (good). appContext.set(Display.class, display); but is not set in the object. If it is set then that avoids a problem later in setCSSContextVariables() Also: ToolItemUpdaterUpdateContributionItems(). has Display.getDefault().timerExec(DELAY, this); which fails if run with a non-default display. Using Display.getCurrent() works better and I don't think timerExec would work if getCurrent returned null. See bug 340594 for some example code to run an Eclipse application with a non-default display. In general: Callers of Display.getDefault() - do you really mean that, or is it the UI thread where Display.getCurrent() would work, or do you have a widget, or IEclipseContext to get the correct display? It's not a major problem - originally I ran Eclipse in this mode to try to get ready for a RAP conversion (where there are multiple displays), but that isn't an active thing for me now: https://wiki.eclipse.org/RAP/FAQ#Why_does_Display.23getDefault.28.29_work_different_than_in_SWT
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
