Community
Participate
Working Groups
Minor enhancement suggestion: It would be nice to have the option of minimizing Eclipse to the system tray (running on Windows of course... I'm not sure if Linux has this capability) rather than to the taskbar. I usually have Eclipse open all day on my desktop but frequently minimize it while I'm working on other tasks, minimizing to the system tray would help free up some of the limited real estate on the task bar. There may also be a benefit of introducing a "pre-initialization" feature in Eclipse that would allow Eclipse to be started up at system launch and automatically minimized to the system tray (just like Mozilla). When I want to launch Eclipse, I simply double click on the system tray icon and things start up a whole lot faster.
I am currently doing some work in and around the Windows System Tray. I would like to start some discussion in this area so this work can be aligned with everyone's expectations, hopefully making the proposal process less painful. I am looking at the following feature set: Minimizing to the System Tray Customizing the icon in the System Tray (icon swaps, animated icons, etc..) Generating alert bubbles in the System Tray (includes stacked bubbles) Contributing context menus to the System Tray Initially I'm building a new plug-in that will expose the API needed to utilize these features of Windows. My initial work does not meet the one to one mapping requirements of the SWT. There is still a lot of logic in my native layer. Eventually I would like to address this and roll it up into an SWT fragment. Please comment. -m@
Setting this up as a separate plugin would be nice but I'd like to see if something like this could also be provided for the Linux and Mac platforms also. I don't use either of those myself so I'm not sure if they have system tray capability. In any case, it would be nice to have a reusable jar (ala SWT) that would at least expose the ability to add and manipulate icons to the system tray, attach menus to those icons and respond to callbacks. The alert bubble stuff would also be nice, but I'd say is a lower priority. I'd say full steam ahead... I'm looking forward to what you put together :-)
Eclipse should not support minimizing to the system tray. This area is intended only for status notification. See the MS UI Guidelines ("Microsoft Windows User Experience"). In the section on Using System Settings and Notifications they state "Because the taskbar is a shared resource, the only kind of information you should add to it is information that is global or that needs monitoring by the user while the user works with other applications". For convenient launching, they recommend allowing the user to use the Quick Launch toolbar, but this does not require any changes to the application. The guidelines state "Unless your application replaces a user system service, such as an Internet browser or e-mail service, do not pre-install an icon for your application on the Quick Launch toolbar. This area is designed primarily for users to customize." However, there may be applications built on top of Eclipse which want to provide some kind of status monitor outside the application, so it would still be worth investigating how to support adding items to the system tray at the SWT level, in Windows and other platforms. Moving to SWT for comment.
I agree. My intention was for this to be utilized by applications that are built on top of the eclipse platform, not the eclipse IDE itself. -m@
Ok, then let me rephrase my request this way: While Eclipse itself may not have a reason to minimize itself to the system tray, but plugins should be given the means to minimize the workbench to the system tray. Individual plugins may very well initiate some type of global process and requires user monitoring and notification without the need of having the Eclipse workbench take up valuable screen real estate.
This brings up some interesting problems. Eclipse is running, a component is launched that makes the request to minimize to the system tray. The perspective is changed and no longer contains the component that made the request. Does eclipse still minimize to the System Tray? What state/perspective is presented when the System Tray icon is clicked?
The System Tray is pretty Windows specific and not a high priority for us right now.
I know that this is marked as a low priority right now, but I think it would be nice to get this functionality. I would like to be able to write an application that resides in the System Tray on Windows. I understand that this functionality is very Window Manager specific, however I think that it is useful and even if it were only possible I would still think it should be included. Most applications run on some form of Windows and if you want to be able to write any Windows App in Java using SWT this would be required. As with any function that may only work on some Operating Systems programmers should be careful when using it, but that doesn't mean it shouldn't be available. Heres hoping this gets in. Alasdair
I have recently finished work on adding support for "Systemtray Icons" in SWT. I based my modifications on SWT 2.1 and only have the win32 port done. I will post code shortly. I did not implement the balloon tip message handling. Balloon tip events are supported only on Windows XP and it required that I add some new SWT event flags and a new listener type. Support for this is trivial but wanted to get some feedback from some SWT gurus before making the effort. I'm beginning work on the Linux port now. I plan to have it complete by the end of this month. Other ports will follow. -m@
Created attachment 5438 [details] systemtray icon support for the win32 port of SWT Here is the code for the win32 port. Enjoy. Thanks -m@
*** Bug 33511 has been marked as a duplicate of this bug. ***
I took a quick look at the code and have a few observations (some which may not be right): - not sure why we have to register our own WNDCLASS (Why a "BUTTON"?) - "bRemoved" is funny (just pass a flag to the helper?) - "icondata" should only be cached for performance or state reasons - "sizeofV3" is funny. Normally this is statically resolved in the struct - showBalloon() API and functionality looks really Windows specific - "icondata" can never be null, don't test for it in removeIcon() - callWindowProc() seems like it's never called - events (like SWT.MouseDown) might be the wrong API on other platforms - should have setMenu() or support SWT.MenuDetect - TrayIcon seems like an Item class (ie. TaskItem) for SystemTray class? - who should the parent of TrayIcon be? - seems that there is only one system tray per application - should the API be on Display? This is where singletons live. - should not use getBytes() ... TCHAR should be enough Chrix to investigate further. Some of the API ideas might be completely out to lunch, depending on API available on the other platforms.
Thanks for the great feedback. Please forgive my lackluster knowledge of SWT. I'm fairly new as I've only begun studying SWT under hood a couple weeks ago. Hare are some answers. > - not sure why we have to register our own WNDCLASS (Why a "BUTTON"?) I did this to provide a Callback for event handling on the icon. Is there a better way? > - "bRemoved" is funny (just pass a flag to the helper?) Okay, are you suggesting something like "int update(boolean removed)" > - "icondata" should only be cached for performance or state reasons Right, building clean each time may require that we save off some state info like the uID. > - "sizeofV3" is funny. Normally this is statically resolved in the struct ? Not sure I understand completely, how else do we determine cbSize? > - showBalloon() API and functionality looks really Windows specific It may be, but we thought it was an important feature that could be emulated on other platforms using tooltips. > - "icondata" can never be null, don't test for it in removeIcon() icondata is set to null in releaseWidget(). > - callWindowProc() seems like it's never called it's an abstract method, I needed to do something. > - events (like SWT.MouseDown) might be the wrong API on other platforms Can you explain? > - should have setMenu() or support SWT.MenuDetect True, when you consider the Gtk StatusDocklet programming model, however mouse events with valid position information should be enough. > - TrayIcon seems like an Item class (ie. TaskItem) for SystemTray class? I disagree, items suggest being able to access all items in an a given item container, no? Tray or Task or Status icons (whatever you want to call it) are usually singleton in nature and an application needs no knowledge of it's containment. > - who should the parent of TrayIcon be? The main Shell of an application, maybe the Display. > - seems that there is only one system tray per application Yes, this is typically the case. > - should the API be on Display? This is where singletons live. Instead of a TrayIcon widget? or additional managment API? If we were to restrict one icon per Display sure, but I did not want to suggest that limitation. > - should not use getBytes() ... TCHAR should be enough In SWT 2.1 there is no accessor for the chars or bytes.
Hi Matthew, We run your code and noticed a couple of things. 1. Mouse events don't seem to be always delivered as they occur. 2. Should rename OS.ShellNotifyIconA to OS.Shell_NotifyIconA (in jni: _ becomes _1). Same for the W version. About 1. Run code snippet below. Clicking on the task icon correctly brings up the balloon the first time. The mouse events don't come in the next time unless the user does something with the application Shell. import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; import org.eclipse.swt.graphics.*; public class PR30834 { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setText("PR"); shell.open(); Image image = new Image(display, "D:/xp/2.1.1- M20030602/eclipse/workspace/java_chris/src/CD.ICO"); final TrayIcon trayIcon = new TrayIcon(shell, SWT.NONE); trayIcon.setImage(image); trayIcon.setToolTipText("tooltip!"); Listener listener = new Listener() { public void handleEvent(Event e) { System.out.println("Event "+e); trayIcon.showBalloon (SWT.ICON_INFORMATION, "balloon title", "With balloon text...", 1000); } }; trayIcon.addListener(SWT.MouseDown, listener); trayIcon.addListener(SWT.MouseDoubleClick, listener); trayIcon.addListener(SWT.MouseMove, listener); trayIcon.addListener(SWT.MouseUp, listener); trayIcon.addListener(SWT.MouseEnter, listener); trayIcon.addListener(SWT.MouseExit, listener); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } } }
Hi Chris, Thanks a lot for catching this. For some reason when testing in a runtime- workbench I did not see this behavior. The following addtion to TrayIcon.java fixes the problem. boolean sendMouseEvent (int type, int msg, int wParam, int lParam, Event event) { sendEvent (type, event); return true; }
Created attachment 5486 [details] updates per Chris' feedback I have made some updates based on Chris' feedback. -m@
Here are answers to your answers. If you answer me, we will get answers to answers to answers. It's be better to go and implement something on the other platforms to see how they work before reworking any of the code for Windows. Here goes: >> - not sure why we have to register our own WNDCLASS (Why a "BUTTON"?) >>I did this to provide a Callback for event handling on the icon. Is there a >> better way? Use Display.windowProc or instead of creating an HWND per item, use "hwndMessage" from Display which is always present. Why consume an HWND per item? >> - "bRemoved" is funny (just pass a flag to the helper?) >> Okay, are you suggesting something like "int update(boolean removed)" Yes or inline the code. >> - "icondata" should only be cached for performance or state reasons >> Right, building clean each time may require that we save off some state >> info like the uID. >> - "sizeofV3" is funny. Normally this is statically resolved in the struct >? Not sure I understand completely, how else do we determine cbSize? Shouldn't NOTIFYICONDATAW.sizeof and NOTIFYICONDATAA just get statically initialized to be the right size in the class based on the version of the ShellAPI? Could Windows constants like NOTIFYICONDATAW_V1_SIZE help? The problem is that there is different sizes based on version of the ShellAPI but we need to work on 98 and NT so we'd better only use the oldest version. From reading the documentation, it seems you can configure the new version to behave like the old. We might want to do this for simplicity. >> - showBalloon() API and functionality looks really Windows specific >>It may be, but we thought it was an important feature that could be >> emulated on other platforms using tooltips. Right but you'd never offer the API first and then hope you can implement it elsewhere. >> - "icondata" can never be null, don't test for it in removeIcon() >> icondata is set to null in releaseWidget(). The check is unnecessary, you set it to null afterwards. >> - callWindowProc() seems like it's never called >it's an abstract method, I needed to do something. This indicates one of two things. You are in the wrong place in the hierarchy or the hierarchy is not structured properly and should possibly be refactored. Seems to me you are in the wrong place in the hierarchy. TaskIcon inherits from Control. Do all the methods (such as setSize()) and events (such as SWT.Paint and SWT.Resize) work for TaskIcon? Probably not or it'd be tons of work to fake them so it'd be better not to inherit them. >> - events (like SWT.MouseDown) might be the wrong API on other platforms >> Can you explain? On GTK or the Mac, do you get mouse events from the system tray when the user clicks or do you get a higher level event like "menu requested" or "user clicked"? Not sure but we'd better find out before choosing an API. >> - should have setMenu() or support SWT.MenuDetect >True, when you consider the Gtk StatusDocklet programming model, >however mouse events with valid position information should be enough. Mouse events with valid position information are never the right answer when attempting to pop a menu up in a portable manner across platforms. Some platforms do it on mouse press, others on release. On the Mac, it's Shift+Click. >> - TrayIcon seems like an Item class (ie. TaskItem) for SystemTray class? >>I disagree, items suggest being able to access all items in an a given item >>container, no? Tray or Task or Status icons (whatever you want to call it) >>are usually singleton in nature and an application needs no knowledge of >>it's containment. See comments about being a subclass of Control and using an HWND per item. Does the application need to query back how many tray icons it has created? Are they floating in space? If an application creates something, it should be able to get it back or find out how many it has created or if there are other ones. Having it be a subclass of Control means that they can be all over the place, invisible but still appearing in the children lists, taking part in layout etc. >> - who should the parent of TrayIcon be? >>The main Shell of an application, maybe the Display. Applications have more than one main shell so it can't be a Shell. >> - seems that there is only one system tray per application >Yes, this is typically the case. Pointing to Display as the parent. >> - should the API be on Display? This is where singletons live. >>Instead of a TrayIcon widget? or additional managment API? If we were to >>restrict one icon per Display sure, but I did not want to suggest that >>limitation. Nope. I'm thinking about two classes, Tray and TrayItem. I'm not sure about this, I need to read more about the other platforms. This might make no sense. In any case, I wouldn't restrict it to be one tray icon per app. >> - should not use getBytes() ... TCHAR should be enough >>In SWT 2.1 there is no accessor for the chars or bytes. Sorry. You could have assigned the field to a new array that was exactly the same size. (Yes I know this is bogus).
Hi Matthew, Thanks for answering so quickly. The best way to help us go forward with this will be to get working prototypes on the other platforms (gnome, kde, mac). Your Windows version gave us a pretty good picture of what is ahead. We can then synthesize the details of a portable api. Chrix
Thanks Steve and Chris for being so responsive on this issue. Our team views desktop integration as an important aspect of a Rich Client Platform strategy. So here are some answers to answers to answers ;-) > The best way to help us go forward with this > will be to get working prototypes on the other platforms (gnome, kde, mac). Precisely, I will have a Gtk port very soon. From what I've read on the web the Gnome and KDE models are compatible so I should be able to kill two birds with one stone. A Mac port may take a little while as I don't have access to an OSX machine, but I've done the research and a Mac port should be fairly straight forward. > Use Display.windowProc or instead of creating an HWND per item, > use "hwndMessage" from Display which is always present. Why consume an HWND > per item? I tried this and had problems with message handling. It seemed that the tray icon and the Shell both were consuming the mouse messages. You certainly don't need an HWND per icon since the wParam contains the uID of the icon. > Yes or inline the code. Really, you'd rather see this check all over the place instead of in just one method? Maybe I'm misunderstanding. Is this a performance gain? > Shouldn't NOTIFYICONDATAW.sizeof and NOTIFYICONDATAA just get statically > initialized to be the right size in the class based on the version of the > ShellAPI? Could Windows constants like NOTIFYICONDATAW_V1_SIZE help? The > problem is that there is different sizes based on version of the ShellAPI but > we need to work on 98 and NT so we'd better only use the oldest version. From > reading the documentation, it seems you can configure the new version to > behave like the old. We might want to do this for simplicity. Ahhh! No please. Using the VX_SIZE constants allows us to work properly on all platforms. Please see "Remarks" at the bottom of http://msdn.microsoft.com/library/default.asp?url=/library/en- us/shellcc/platform/shell/reference/structures/notifyicondata.asp > Right but you'd never offer the API first and then hope you can implement it > elsewhere. Really? If we cannot implement it else where can't we always just fall back to doing nothing? Similar to the way "setBackground" doesn't work for some widgets. Balloon tips are a great/important feature in XP and 2k. > Seems to me you are in the wrong place in the hierarchy. > TaskIcon inherits from Control. Do all the methods (such as setSize()) and > events (such as SWT.Paint and SWT.Resize) work for TaskIcon? Probably not or > it'd be tons of work to fake them so it'd be better not to inherit them. At first I would agree completely. However, after researching the Mac and Gtk equivalents I'm not so certain. What would you suggest Widget? Item? > On GTK or the Mac, do you get mouse events from the system tray when the user > clicks or do you get a higher level event like "menu requested" or "user > clicked"? Not sure but we'd better find out before choosing an API. + > Mouse events with valid position information are never the right answer when > attempting to pop a menu up in a portable manner across platforms. Some > platforms do it on mouse press, others on release. On the Mac, it's > Shift+Click. Agree, but now we are changing/limiting the Windows programming model. The Windows model suggests you simply get mouse events in the icon and it's up to you to decide what to do. You could show a menu on Left click or Right click, minimize the application window on dbl click etc... It appears that the Mac and Gtk models are a little less flexible in this respect. I believe on the Mac you get the icon menu when you click and hold the icon in the Doc and on Gtk you get a menu on an RButton down. I guess it would make sense to tune the Windows model :-( > Does the application need to query back how many tray icons it has created? > Are they floating in space? If an application creates something, it should be > able to get it back or find out how many it has created or if there are other > ones. Having it be a subclass of Control means that they can be all over the > place, invisible but still appearing in the children lists, taking part in > layout etc. If we consider the tray icon to be a widget then the Application that defined it should be responsible for tracking it. It's seems like extra work for the Display to track these things, unless of course we consider them singletons, which isn't such a bad idea when looking at the Mac's Doc model where icons are singleton per application. > Applications have more than one main shell so it can't be a Shell. > Pointing to Display as the parent. Agree. I will refactor my code accordingly, but I think we also need to decide if icons will be singleton in which case the API should probably move to the Display. > Nope. I'm thinking about two classes, Tray and TrayItem. I'm not sure about > this, I need to read more about the other platforms. This might make no > sense. In any case, I wouldn't restrict it to be one tray icon per app. After studying other platforms I'm thinking two things here: 1) On some platforms (the mighty Mac osx) you have no choice here, the icon is singleton per application. 2) The statement above makes a Tray class useless, unless we wanted to support multiple icons on platforms that support it? But couldn't the Display class do the job of a Tray class since it's only real function would be to track items? So let me summarize where I think we are: 1) Icons - are they singleton or not? I'm not sure what to say here, half of me says singleton, but two out of the three major platforms support multiple icons. But what's the use case for multiple icons? I'm torn here. 2) Where do Icons fall in the hierarchy? - I suppose Item or Widget is the proper place if not just API on the Display. 3) All platforms support Menus - can someone suggest a programming model for this? 4) All platforms support Image/icon manipulation, e.g. setImage 5) Mac does not support (hide/show) 6) Mouse events do not work for Mac and Gtk. Selection/Menu request events may be a better choice here but this strictly limits the Windows model. 7) Balloon tips are supported on Windows only, can be emulated on Gtk with tooltips, may not be doable on Mac (can we just do nothing in this case). API certainly needs to be refactored, for instance the "int icon" field should be "int style"? The Gtk port is on the way. If someone out there can tackle the OSX port that would be helpful :-) -m@
Matthew, Thanks for working on this. It looks like a good start. While I don't have an opinion on most of the issues raised, I would say that I prefer being able to set multiple try icons per application. While it is an edge case, the application I have in mind for this will use two tray icons. One that is always present to allow access to configuration options, the other that displays intermittently when there are updates. Also, balloon tip support would be greatly appreciated. One last question... will this be available as a separate plugin or integrated into the next release of SWT?
Funny that "hwndMessage" didn't work. Did you try creating a window that was "Display.windowClass". Events shouldn't be eaten. Note that "hwndMessage" messages don't go through Control.windowProc(). Anyway, don't try to fix any Windows code now. You need to experiment on the other platforms. Remember, you cannot offer API that can't be implemented on all the plaforms unless there is graceful failure mode on platforms that don't support it. If it's tons of work to fake an API the you need to weigh that against the utility of the API. For example, it sounds like faking mouse events wouldn't be worth it. I suggest we continue the discussion after you have something running elsewhere. We will all know more at that time.
After a little more research it looks like Gtk2 supports balloon tips (without emulation) via the libegg module :-)
At long last I have finished a working prototype for GTK. This work is based on the Systemtray specification defined at www.freedesktop.org. This spec has been adopted by KDE 3.1 and Gnome 2.2. There are a couple open issues with this prototype: 1) Balloon tips are not yet implemented. The spec does define how to implement balloon tip support, however balloon tips do not seem to be supported in KDE 3.1 or Gnome 2.2 so I have not implemented them. Why? Because I had no way to test if I had done it properly :-) 2) There is one native interface that does not conform to the strict SWT one-to- one mapping requirement. I understand that this needs to be fixed. However, before doing so I would like to present my problem, suggest how to handle it and request feedback. The function in question is XNotifyIcon. The problem is that I need to implement support for the XSendEvent API. Now, one look at the XEvent struct and you will understand my problem. I do not want to attempt to support the whole XEvent struct, it's just too much to support one feature. My proposal is to do something similar to the memmove functions. So the code would look like: XSendEvent_XClientMessageEvent (args......) { ..... ..... XSendEvent((Display *)display, (Window)window, False, NoEventMask, (XEvent *) &ev); } This way I would only need to implement support for the XClientMessageEvent struct. What do you think? Comments please?? Enjoy the prototype. -m@
Created attachment 6207 [details] Linux/GTK Prototype for the TrayIcon widget
Windows: public TrayIcon (Shell parent, int style) { GTK: public TrayIcon (Composite parent, int style) { Will there be any consistency here?
Created attachment 6218 [details] updated TrayIcon.java for win32 Sorry, I updated the constructor for TrayIcon and forgot to post. -m@
Thank you. I have been following this patch for a while and think it is a great addition. note: I think the windows files were for SWT 2.1.1, but the gtk files seem to be for SWT 2.1 (swt.c/OS.java). I eventually patched them in to 2.1.1. Anyway, it works well for me on WindowsXP, but on Redhat9, running KDE 3.1: (<unknown>:30212): Gtk-CRITICAL **: file gtkwidget.c: line 3818 (gtk_widget_set_parent): assertion `!GTK_WIDGET_TOPLEVEL (widget)' failed And nothing shows up in my tray. I have tried using different parent Composites, but all return the same error. I'm not very familar with what I require to get this to work on gtk. Is there some trick I am missing? redhat9 has (if it matters): gnome-desktop-2.2.0.1-4 kdebase-3.1-12 gtk2-2.2.1-4 gtk+-1.2.10-25
Mouse events no longer work if I integrate this into SWT 3 (Eclipse M4 build) on windows. Where might I look to fix this? structs.c became os_structs.c, swt.c became os.c, but beyond that, has something major changed in SWT3?
After chasing my tail for quite a while, I have discovered that windowProc requires 4 parameters now, instead of 3. It now works with SWT 3. TrayIcon.java: int windowProc (int hwnd, int msg, int wParam, int lParam) { //int windowProc (int msg, int wParam, int lParam) {
This feature is critical for Rich Client Platform applications.
What can I say? Sorry that this fell off a cliff. There is an API problem with the code that is about to go into SWT. We will either solve the problem or update your patch so that it doesn't need to be part of SWT. Either way, you will get working and blessed code.
Fixed > 20040312 The system tray is represented by the classes Tray and TrayItem (just like the other "item" classes). Use "Display.getSystemTray()" to get the parent and then "new TrayItem (parent, SWT.NONE)" to create individual items.
*** Bug 54635 has been marked as a duplicate of this bug. ***
*** Bug 14213 has been marked as a duplicate of this bug. ***
I was not able to add a Menu to the Trayicon. Did I miss something, or is it not yet possible to add a Menu to the Tray?
Look for SWT.MenuDetect and use Menu.setVisible(). Don't try to position the menu.
Having attached a menu to the TrayItem I find it wont go away when I click on the desktop in the same way that other applications do. I'm assuming there is something I need to write to get this to work, but I have yet to find it, some pointers on what I need to do would be appreciated. Thanks Alasdair
Try it now (using tonights build). It was a bug.
Steve, was the bug mentioned in comment 37 and 38 fixed in M8? Just wanted to give you a heads up a Javadoc error. In ToolItem.java there is a reference to ToolBar and the info regarding styles may not be accurate. Not sure if you guys are even looking at this type of thing yet. Just FYI.
Yes, I should have wrote "Fixed > 20040322". I will fix the Javadoc right now.
Hi, Ok I managed to use a menu that shows when the user selects the TrayItem. I have passed the Shell as argument to the Menu constructor since using Tray or TrayItem is not possible (hope that was correct). As I am currently working on removing a different native Tray support for my application and use the SWT Tray support, here some questions and problems: - The menu still does not close when the focus is lost (I am using swt-N20040322-win32) - I am using a ShellListener to listen for shellIconified. Is there any better way to hide the Shell (= placing it into the system tray) than calling "setVisible(false)"? - The Menu contains an entry "Open" that will set the visibility of the Shell back to TRUE. I am then calling "shell.forceActive();", but the shell is just appearing in the taskbar with no focus. It only gets focus and places itself over all other windows when calling "setMaximized(true)". Any solution? - I assume the SWT Tray is working on Win, Linux and Mac? Thanks, Ben
>> - The menu still does not close when the focus is lost >> (I am using swt-N20040322-win32) Should already be fixed > 20040322. If not, open a bug report. >> - I am using a ShellListener to listen for shellIconified. >> Is there any better way to hide the Shell (= placing >> it into the system tray) than calling "setVisible(false)"? No, you are doing the right thing. The system tray is not actually meant for iconified windows. The Task Bar is where they are supposed to go. >> - The Menu contains an entry "Open" that will set the >> visibility of the Shell back to TRUE. I am then calling >> "shell.forceActive();", but the shell is just appearing >> in the taskbar with no focus. >> >> It only gets focus and places itself over all other >> windows when calling "setMaximized(true)". >> Any solution? Enter a separate bugzilla report for this and include a stand alone snippet. Thanks. >> - I assume the SWT Tray is working on Win, Linux and Mac? >> No Mac implemenation. Enter a bugzilla report for this. Guys, the thing is implemented. Start reporting bugs against it instead of using this problem report. Thanks.
I believe minimizing to tray should be supported. It does not matter what the system tray is for, many users, including myself, want the feature, because it allows you to keep your project "open" for ready-access. This is especially critical on lower end computers, where you cannot reopen Eclipse as fast. Minimizing to the System Tray AGREE - Yea well that's the purpose :) Customizing the icon in the System Tray (icon swaps, animated icons, etc..) DISAGREE - I don't need it or think its very necessary. Just default eclipse icon. Generating alert bubbles in the System Tray (includes stacked bubbles) AGREE - I don't need it, but I believe many users would want this. Contributing context menus to the System Tray AGREE - A few things, perhaps compiling or saving, should be accessible via a context menu. Thank you Matt for this feature...it rocks!
System tray support has been in SWT for a while. I'm going to mark these patches as obsolete.
Is there any reason that I shouldn't?
The only thing I can think of (and forgive me I did not read through the entire bug report) is that you cannot locate the systemtray. Thus it is not possible to do all the right animated rectangle drawing when "minimizing to the system tray". I realize this is probably a Windows only thing to do so it could be pointless.
Put in a feature request for TrayItem.getBounds(). We might be able to get this information, however, you are going to look pretty silly animating to the "system tray" on the Mac.
