| From the SWT/Swing artical proposal in Bugzilla [message #572261] |
Wed, 19 September 2007 12:39 |
 James
Messages: 272
Registered: July 2009 |
Senior Member |
|
|
Hi Gordon,
I have copied your reply to my post at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=154973 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
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.
========================
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
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.
========================
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.
|
|
|
Powered by
FUDForum. Page generated in 0.03304 seconds
] 
Search
Help
Register
Login
Home
