Bugzilla – Full Text Bug Listing
| Summary: | [CSS] Provide mechanism to listen for theme changes | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Brian de Alwis <bsd> |
| Component: | UI | Assignee: | Brian de Alwis <bsd> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | gheorghe, tom.schindl |
| Version: | 4.2 | ||
| Target Milestone: | 4.2 M7 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
Would it be better to send an event on the IEventBroker? (In reply to comment #1) > Would it be better to send an event on the IEventBroker? I think that's a good approach Tom. We should also provide detail in the notification as to whether it's a permanent change or temporary (the "restore" flag provided to ThemeEngine#setTheme()). Note that there is already a section in UIEvents called UILifeCycle that might be a good place to put these. We currently use these events to notify listeners about changes that may not actually affect the model (i.e. bringing a part to the top when it's already there...). I'm also planning in adding an 'AboutToRender' and 'RenderingFinished' events here and could easily be convinced to do these at the same time if it seems like the right approach... Commit: 2585b4d64e5ae7c03d08465774e1247c5a7fb489 Added an OSGi EventAdmin-based solution (couldn't use IEventBroker/UIEvents as it's to be independent of the remainder of the e4 code. On theme change, an event is sent providing as attributes the theme object, the display, the CSS engine, and the "restore" flag. (I've tried to ensure the event names are in parallel the UIEvents layout.) Updated the Contacts demo to listen for the changes and print strings to System.out (purely diagnostic). Added a test too. I've marked in the javadoc that the event layout is not considered API. the draw back of using the EventAdmin directly is that this will cause problems for multi user envs like RAP in future (In reply to comment #5) > the draw back of using the EventAdmin directly is that this will cause problems > for multi user envs like RAP in future That's a problem inherent to using EventAdmin/IEventBroker. I've included the Display and Engine instances as event attributes to allow some filtering. Brian, is there any work left to do in this bug? We are trying to clean up list of 4.2M7 bugs. As part of some experimental work that I was doing for EclipseCon, which uses several multiple CSS engines, I've changed the event notification to not be specific to SWT. On a theme chanEvent properties now provided: IThemeEngine.Events.THEME_ENGINE: the theme engine where the theme was changed IThemeEngine.Events.THEME: the new theme IThemeEngine.Events.RESTORE: flag indicating whether this theme change The IThemeEngine now provides the CSS engines that it manages; the device/display can be obtained from that engine, as required. Committed to head (commit 9594ffcc946ea8d70ee72de341435c8a8b85970a). Verified in I20120503-1800 |
The new CSS theme management doesn't provide a good way to listen for theme changes. The best that can be done currently AFAICT is to listen for a key change 'themeid' on the org.eclipse.e4.ui.css.swt.theme bundle with code like the following: InstanceScope.INSTANCE.getNode("org.eclipse.e4.ui.css.swt.theme").addPreferenceChangeListener(new IPreferenceChangeListener() { public void preferenceChange(PreferenceChangeEvent event) { if(event.getKey().equals("themeid")) { System.out.println("THEME CHANGED: " + event.getNewValue()); } } }); It'd be nice if the context could have a ITheme variable that was updated, though that's complicated since org.eclipse.e4.ui.css.swt.theme is independent of E4.