Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Albireo » From the SWT/Swing artical proposal in Bugzilla
From the SWT/Swing artical proposal in Bugzilla [message #572261] Wed, 19 September 2007 12:39
James is currently offline JamesFriend
Messages: 272
Registered: July 2009
Senior Member
Hi Gordon,
I have copied your reply to my post at and added my responses.

We are very interested in seeing the difficulties between SWT and Swing
resolved. It would be quite nice to have both of them play well together.
Our focus is completely based on SWT working better with Swing.

We're looking to build community for Albireo. If we can include you and your
organization as an interested party, please let me know.

> I have a few additional enhancements for the sample code.
> I do not have the option of using the Windows look and feel. The
> look and feel is metal based.

This is good to know. It probably means Albireo should make the look and
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.

Our company uses primarily Swing-based applications and we are using an
Eclipse-based application to tie everything together. The company-wide look
and feel is actually a modified version of NimROD. Our convention is that
swing controls are pretty much limited to the editor area and, when they are
used, they fill the entire editor. I have also tweaked the eclipse tabs to
better integrate the two looks. The result isn't perfect but it works.

> In a last-ditch act of desperation, I changed the way the blocker Shell
> 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
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
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

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
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.

Yes, always on top does mean on top of everything and seems to mean the same
even with the window manager I am using in GTK. This is a less than ideal
solution to the problem but I felt an anoying on-top-of-everything approach
was still better for a modal dialog rather than the massive confusion caused
by a pop-under. I would be very interested in seeing a better work-around
for this problem.
Previous Topic:Layout Constraints
Next Topic:More tips for the sample code
Goto Forum:

Current Time: Thu Nov 15 01:37:03 GMT 2018

Powered by FUDForum. Page generated in 0.03478 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top