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 #1393] Wed, 19 September 2007 12:39 Go to next message
Eclipse UserFriend
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 #3208 is a reply to message #1393] Sat, 06 October 2007 19:02 Go to previous messageGo to next message
Gordon Hirsch is currently offline Gordon HirschFriend
Messages: 100
Registered: July 2009
Senior Member
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 #3272 is a reply to message #3208] Tue, 09 October 2007 12:13 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Eclipse UserFriend
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 #3337 is a reply to message #3304] Tue, 09 October 2007 20:43 Go to previous messageGo to next message
Gordon Hirsch is currently offline Gordon HirschFriend
Messages: 100
Registered: July 2009
Senior Member
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.
Re: From the SWT/Swing artical proposal in Bugzilla [message #3370 is a reply to message #3337] Wed, 10 October 2007 16:47 Go to previous message
Eclipse UserFriend
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.
Re: From the SWT/Swing artical proposal in Bugzilla [message #572745 is a reply to message #1393] Sat, 06 October 2007 19:02 Go to previous message
Gordon Hirsch is currently offline Gordon HirschFriend
Messages: 100
Registered: July 2009
Senior Member
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 #572793 is a reply to message #3208] Tue, 09 October 2007 12:13 Go to previous message
James Peltzer is currently offline James PeltzerFriend
Messages: 43
Registered: July 2009
Member
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 #572826 is a reply to message #3272] Tue, 09 October 2007 19:14 Go to previous message
James Peltzer is currently offline James PeltzerFriend
Messages: 43
Registered: July 2009
Member
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 #572848 is a reply to message #3304] Tue, 09 October 2007 20:43 Go to previous message
Gordon Hirsch is currently offline Gordon HirschFriend
Messages: 100
Registered: July 2009
Senior Member
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.
Re: From the SWT/Swing artical proposal in Bugzilla [message #572885 is a reply to message #3337] Wed, 10 October 2007 16:47 Go to previous message
James Peltzer is currently offline James PeltzerFriend
Messages: 43
Registered: July 2009
Member
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.
Previous Topic:Creation Review Date?
Next Topic:CTRL-C stack overflow
Goto Forum:
  


Current Time: Fri Nov 16 14:51:52 GMT 2018

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

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

Back to the top