Community
Participate
Working Groups
This is a proposal for an article on embedding Swing components in RCP applications. Many organizations have a large investment in Swing components, and they need a way to transition from Swing applications to the Eclipse Rich Client Platform without starting from scratch. We've learned that using the SWT_AWT bridge is only the first step along the way to embedding usable Swing components in RCP applications. A large part of the article will be devoted to explaining the additional practices necessary to use Swing effectively in an RCP application. Without these practices, the SWT_AWT bridge would be insufficient for enterprise application use. With them, we are able to successfully host our key Swing controls in RCP apps. We think that these techniques would be broadly useful for anyone who needs to host legacy Swing components in RCP apps, and would like to share them with others. The article will focus on embedding AWT frames inside SWT composites. This is just one half of the SWT_AWT bridge, but there is easily enough content for a sizable article. While there are important uses for the other half (embedding SWT in AWT), I think that topic would be best suited for a separate article. Here's a rough outline of the article: - Basics of using org.eclipse.swt.awt.SWT_AWT - Dealing with multiple event threads - Additional best practices for embedding AWT/Swing - Creating the right top-level AWT/Swing components in the embedded frame - Configuring the system look and feel - Reducing flicker - Allowing tab traversal in and out of the embedded frame - Making AWT/Swing dialogs modal across the entire application - Dismissing Swing pop-up menus when focus changes to SWT - Synchronizing with system settings changes - Working around AWT bugs - Unresolved issues The article will be platform neutral as much as possible, but it will be necessary to talk about specific platform issues from time to time. Not surprisingly, we've dealt most with the Windows platform, so that is where the most detail will be. Most of the practices outlined above can be encapsulated in a single common base class for all embedded Swing composites (and some additional helper classes for the implementation). This code will be used to help demonstrate the best practices, and a full version will be included with the article. We can also include some screenshots from sample applications, and possibly from products we have in development at SAS.
+1
I searched the Internet for references to the SWT_AWT bridge but did not find much information. Is such an article already existing or has someone already started writing such an article?
Did you find the SWT Snippits? http://www.eclipse.org/swt/snippets/
(In reply to comment #2) > I searched the Internet for references to the SWT_AWT bridge but did not find > much information. Is such an article already existing or has someone already > started writing such an article? Not yet, but I haven't forgotten. I'm hoping to have a first draft available in maybe a month. Sorry for the delay.
Due to apparent inactivity, I'm marking this bug as LATER. Feel free to reopen the bug when you have your first draft ready.
The draft is actually written at this point. We're just getting the necessary internal review and approvals done.
Finally, finally, I'm able post a first draft of this article. Apologies for the delay. There are a couple of sections that need a little more detail (in the area of Swing keyboard/focus issues), but I think the article is ready for review. Comments would be greatly appreciated. Wayne, in an email last year, you asked if a review from someone on the SWT team would be appropriate. I'd like to emphasize that it would, in fact, be very valuable, if it could be arranged. Attachment to follow.
Created attachment 57602 [details] 1st draft of swing/swt integration article
It's a great start. I noticed at least one "TODO" in the document. Any idea when that will be complete? I've added platform-swt-inbox to the cc list in hopes that an SWT committer or two can review this article.
Thanks, Wayne. The TODO items are only maybe a paragraph or three, but it could take a day of digging to get the answers I need. I'll try to get to it by the first or second week of March. This is a more reliable estimate than the last one I made here :-). I don't think any review needs to be held up waiting for this.
I believe that some reviewers have added their names the CC list. If somebody is actively reviewing the article, can you please leave a comment to that effect?
Steve and I are reviewing the article. Where do you want the feedback? Here?
That's great! Personally, I'm happy with wherever you want to do feedback. Either here or email is fine. Coincidentally, I'm about to upload an updated draft. The changes are very localized, so I don't think it is necessary to start over if you've already begun.
Upload the draft. Wayne, how is the review process normally done? Do we communicate through email or the bug report?
Created attachment 60867 [details] Second draft of the article Here's the updated draft. Changes: - updated the Tab Traversal section with more details - updated the Dismissing Popups section with a simpler way to dismiss Swing popups on SWT menu events. - Traded the Keyboard Issues section (under Unresolved Issues) for a Keyboard Contention section. The new section describes a partial solution and sketches a fuller solution to the original issue. Example code has been update to reflect the changes above. I had some good feedback in email from Marco Koch and Gilles d'Andrea. Some of their feedback is incorporated in the above changes. There were other suggestions that I haven't yet addressed: - integrating access to resources (images, localized strings, etc.) across the two environments - unifying actions to some degree - synchronizing the selection I'm starting to have concerns about article size (too large) if these items are addressed in any detail. Thoughts?
(In reply to comment #14) > Upload the draft. Wayne, how is the review process normally done? Do we > communicate through email or the bug report? > Ideally, communication should occur through the bug report. I'd at least like to know that the review is underway. At the end of the day, as long as a review is underway, I'm very happy...
Very nice article, quite helpful at solving a few problems I was grappling with. One comment on your AwtDialogListener class though: In the handleAddedDialog method you return if the dialog is already contained in modalDialogs or if the dialog is not modal but you don't check the dialog's visibility. I have noticed that in some rare cases (occasionally reproducible in some of our code with a button mash), the AwtDialogListener can block SWT on an invisible AWT Dialog. Since the dialog is invisible, there is no way to close it so SWT stays locked and the application must be terminated. I added !awtDialog.isVisible to the statement to cancel adding the dialog to the modalDialog list and the problem seems to have cleared up. if (modalDialogs.contains(awtDialog) || !awtDialog.isVisible() || !awtDialog.isModal()) { return; } -James
This is a great article. The SWT_AWT bridge was always intended to be just the minimum glue to put the two toolkits together. Here are some comments: - remove reference for org.eclipse.swt.widgets.Composite.resizeEmbeddedHandle() (the method is on Windows only) - cheese was removed from wikipedia (delete the link or put back the wiki page) - is shell.setMinimumSize(0, 0) necessary (what does it do?) - "Synchronizing with System Settings" - is this just a bug in AWT (ie will the code break when Sun fixes it?) - Shift+F10 - in a native windows application, when there is no context menu, Shift+F10 goes to the menu bar. It's not really a bug but your code is needed. Silenio & Steve
(In reply to comment #17) > > I added !awtDialog.isVisible to the statement to cancel adding the dialog to > the modalDialog list and the problem seems to have cleared up. > > if (modalDialogs.contains(awtDialog) || !awtDialog.isVisible() || > !awtDialog.isModal()) { > return; > } Thanks, James. I've not seen the scenario you describe, but the code change makes perfect sense. And the consequences (locked app) are pretty severe. I will add the isVisible() check to the sample code.
(In reply to comment #18) Thanks for the comments! > > - remove reference for org.eclipse.swt.widgets.Composite.resizeEmbeddedHandle() > (the method is on Windows only) Ok. > - cheese was removed from wikipedia (delete the link or put back the wiki page) Bummer. So much for the pseudo-legitimacy that link added :-). I'll remove it. > - is shell.setMinimumSize(0, 0) necessary (what does it do?) Not necessary. I think this is left over from my attempts to make the dialog invisible on Linux/GTK. I'll remove the line. Thanks for pointing it out. > - "Synchronizing with System Settings" - is this just a bug in AWT (ie will the > code break when Sun fixes it?) I would consider it an AWT/Swing limitation. I see the same problem with standalone Swing applications. It just stands out more in the integrated environment. If it gets fixed, there should be no problem. The code will then be a no-op, as far as I know. > - Shift+F10 - in a native windows application, when there is no context menu, > Shift+F10 goes to the menu bar. It's not really a bug but your code is needed. Yeah, I was trying to say that, but apparently not so well. I shouldn't have used the word "workaround". I'll try to make it clearer. > > Silenio & Steve >
Created attachment 64317 [details] Third draft of the article New draft with changes to the article and example code based on the recent review comments. Wayne, what's next?
(In reply to comment #21) > New draft with changes to the article and example code based on the recent > review comments. Wayne, what's next? The next step is a +1 from Silenio on your recent changes. Then I'll do the final editing pass and publish.
The article is available for review here: http://local.eclipse.org/articles/article.php?file=Article-Swing-SWT-Integration/index.html It has not yet been added to the "articles" page. I have started my review. Other reviewer comments are still welcome.
Wayne, what's the status of your review?
I've done my final pass and it looks good. I got the URL wrong, it should be: http://www.eclipse.org/articles/article.php?file=Article-Swing-SWT-Integration/index.html Thanks for the kick.
I just noticed that I need to update my docbook XSL to include some missing sections of the document. I'll do that first thing tomorrow.
I've published the article. Gordon, can you send me (via email) your mailing address, phone number, and shirt size? I'll send you something nice to thank you for the article. http://www.eclipse.org/resources/resource.php?id=381
I have a few additional enhancements for the sample code. I do not have the option of using the Windows look and feel. The company-wide look and feel is metal based. I was going crazy dealing with cases where the SWT Shell was not properly passing the focus to the AWT Dialog until the user clicked on the dialog in the task bar (mentioned in the sample code comments). In a last-ditch act of desperation, I changed the way the blocker Shell was being constructed in the SwtInputBlocker's 'open' method to use Display.getCurrent() rather getParent() and everything started working. private Object open() { assert Display.getCurrent() != null; // On SWT event thread final Shell parent = getParent(); shell = new Shell(Display.getCurrent(), SWT.APPLICATION_MODAL); I'm not sure why it works. I would also love to hear about any possible negative side-effects of this. But for now I'm quite happy. Also, as a work around on the Linux Gtk side, I was having to deal with the AWT Dialog not properly being brought to the front. I added if (Platform.isGtk() && !awtDialog.isActive()) awtDialog.setAlwaysOnTop(true); to the request focus runnable and have found the results to be more acceptable. Any feedback?
James, First, in case you or others were not aware, there is now a proposed Eclipse Technology project called Albireo (http://www.eclipse.org/proposals/albireo/) that builds on the ideas in this article. There's also a newsgroup (eclipse.technology.albireo) which is a great place to discuss these issues. We're looking to build community for Albireo. If we can include you and your organization as an interested party, please let me know. (In reply to comment #29) > I have a few additional enhancements for the sample code. > > I do not have the option of using the Windows look and feel. The company-wide > look and feel is metal based. This is good to know. It probably means Albireo should make the look and feel setting configurable. But I am surprised that you can live with the mix of platform L&F for SWT and Metal L&F for Swing. > In a last-ditch act of desperation, I changed the way the blocker Shell was > being constructed in the SwtInputBlocker's 'open' method to use > Display.getCurrent() rather getParent() and everything started working. > > private Object open() { > assert Display.getCurrent() != null; // On SWT event thread > > final Shell parent = getParent(); > shell = new Shell(Display.getCurrent(), SWT.APPLICATION_MODAL); > > I'm not sure why it works. I would also love to hear about any possible > negative side-effects of this. But for now I'm quite happy. This was a good idea. I'm not exactly sure why it works either, but the original problem had to do with a missing focusGained event. I suspect that the original parent-child relationship was somehow suppressing the focusGained event that was needed to pass control back to AWT. By breaking that relationship, you've managed to work around the problem. I can't think of any harm from this approach and we should consider it for Albireo. > > > Also, as a work around on the Linux Gtk side, I was having to deal with the AWT > Dialog not properly being brought to the front. I added > > if (Platform.isGtk() && !awtDialog.isActive()) > awtDialog.setAlwaysOnTop(true); > > to the request focus runnable and have found the results to be more acceptable. My experience with setAlwaysOnTop() is that it forces the window to the top always... even when you activate some other application's window. Maybe this is a Windows-specific behavior? Or maybe I'm just not remembering correctly. My concern would be that even on GTK setAlwaysOnTop might work differently depending on the window manager in use.
Gordon, (In reply to comment #30) > First, in case you or others were not aware, there is now a proposed Eclipse > Technology project called Albireo (http://www.eclipse.org/proposals/albireo/) > that builds on the ideas in this article. There's also a newsgroup > (eclipse.technology.albireo) which is a great place to discuss these issues. > > We're looking to build community for Albireo. If we can include you and your > organization as an interested party, please let me know. Risking the danger of shameless self-advertising: Another alternative for combining SWT and Swing is "Eclipse on Swing" (EOS) and SWTSwing. In case you want to find out more you can download our article and the EclipseCon presentation at http://eos.sourceforge.net > > (In reply to comment #29) > > I have a few additional enhancements for the sample code. > > > > I do not have the option of using the Windows look and feel. The company-wide > > look and feel is metal based. > > This is good to know. It probably means Albireo should make the look and feel > setting configurable. But I am surprised that you can live with the mix of > platform L&F for SWT and Metal L&F for Swing. Next to SWT/Swing interaction one minor problem we solve is uniform company branding. For example with the EOS plug-in you can easily select your favorite Look&Feel which will then be used uniformly throughout your application.
