From the SWT/Swing artical proposal in Bugzilla [message #1393] |
Wed, 19 September 2007 12:39 |
Eclipse User |
|
|
|
Originally posted by: canadianguy.gmail.com
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.
|
|
|
|
Re: From the SWT/Swing artical proposal in Bugzilla [message #3272 is a reply to message #3208] |
Tue, 09 October 2007 12:13 |
Eclipse User |
|
|
|
Originally posted by: canadianguy.gmail.com
I had noticed the extra task bar entry but felt that it was less annoying
than pop-unders. The SWT.ON_TOP Style for removal of the entry is great
news.
Thanks,
James
"Gordon Hirsch" <gordon.hirsch@sas.com> wrote in message
news:fe8m4t$dc4$1@build.eclipse.org...
> James wrote:
> > ========================
> >> 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.
>
> I just noticed one negative side-effect. On my Windows XP, the SWT
> Blocker shell adds a button to my taskbar with no title. No real harm,
> but it looks bad. It looks like the task bar entry can be removed by
> adding the SWT.ON_TOP style to the blocker shell. I haven't seen bad
> side-effects so far from the new style bit.
|
|
|
Re: From the SWT/Swing artical proposal in Bugzilla [message #3304 is a reply to message #3272] |
Tue, 09 October 2007 19:14 |
Eclipse User |
|
|
|
Originally posted by: canadianguy.gmail.com
I have found an issue with the SWT.ON_TOP attribute being used under Windows
2000.
SWT.ON_TOP seems to cause the main SWT window to move under other
applications when the Swing dialog box is closed.
"James Peltzer" <canadianguy@gmail.com> wrote in message
news:fefr74$tlc$1@build.eclipse.org...
> I had noticed the extra task bar entry but felt that it was less annoying
> than pop-unders. The SWT.ON_TOP Style for removal of the entry is great
> news.
>
> Thanks,
>
> James
>
> "Gordon Hirsch" <gordon.hirsch@sas.com> wrote in message
> news:fe8m4t$dc4$1@build.eclipse.org...
> > James wrote:
> > > ========================
> > >> 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.
> >
> > I just noticed one negative side-effect. On my Windows XP, the SWT
> > Blocker shell adds a button to my taskbar with no title. No real harm,
> > but it looks bad. It looks like the task bar entry can be removed by
> > adding the SWT.ON_TOP style to the blocker shell. I haven't seen bad
> > side-effects so far from the new style bit.
>
>
|
|
|
|
Re: From the SWT/Swing artical proposal in Bugzilla [message #3370 is a reply to message #3337] |
Wed, 10 October 2007 16:47 |
Eclipse User |
|
|
|
Originally posted by: canadianguy.gmail.com
I put parent.forceActive() in the SwtInputBlocker's close method and it
seems to do the trick on Win2k.
It seems to be required any time that a modal dialog is opened from inside
of another modal dialog. When you are done and close the original modal
dialog, the application window needs to have activation forced upon it.
"Gordon Hirsch" <gordon.hirsch@sas.com> wrote in message
news:fegp4p$m2p$1@build.eclipse.org...
> James Peltzer wrote:
> > I have found an issue with the SWT.ON_TOP attribute being used under
Windows
> > 2000.
> >
> > SWT.ON_TOP seems to cause the main SWT window to move under other
> > applications when the Swing dialog box is closed.
> >
> >
>
> Just now, I noticed a similar problem on Windows XP. The main window is
> sometimes not activated after dismissing the AWT dialog, but this
> happens with or without the ON_TOP mask. I solved it by adding this line
> to the end of SwtDialogBlocker.
>
> parent.forceActive();
>
> I wonder if it would help in your case? I don't currently have a W2K box
> to test with.
>
> Otherwise, it sounds like the use of ON_TOP may need to be optional.
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.07157 seconds