Community
Participate
Working Groups
SWT supports access to the system tray. As we cannot support a tray in RAP, we should implement this API as no-op. SWT itself states that platforms that do not support system tray, should return null. But the API like classes / methods are needed for compiling. See /** * Returns the single instance of the system tray or null * when there is no system tray available for the platform. * * @return the system tray or <code>null</code> * * @exception SWTException <ul> * <li>ERROR_DEVICE_DISPOSED - if the receiver has been disposed</li> * </ul> * * @since 3.0 */ public Tray getSystemTray () {
Created attachment 176884 [details] Patch for Bug 320389
In order to support a getSystemTray method that always returns null in RAP, we introduce an API classes Tray and TrayItem with some empty method implementation like TrayItem#setVisible. I would prefer to not implement this method at all, instead of introducing an unsupported API classes/methods. Maybe another possible solution is to change the method signature to: public Widget getSystemTray (). Benny, what do you think?
But... after looking more carefully in the code, Display#getSystemTray is the only way to create an instance of the Tray widget. The empty implementations of Tray and TrayItem can't be accessed at all, but will help single sourcing. Please discard comment #2.
(In reply to comment #3) > But... after looking more carefully in the code, Display#getSystemTray is the > only way to create an instance of the Tray widget. The empty implementations of > Tray and TrayItem can't be accessed at all, but will help single sourcing. > Please discard comment #2. Not sure if it would ever make sense to do a 1:1 port of an application to RAP that makes use of the SystemTray. However, I agree with Ivan that it would do no harm and would help single-sourcing.
Applied patch to CVS HEAD.
