Comment 1 Bogdan Gheorghe 2009-08-21 16:31:50 EDT

Thanks for the info - we are definitely interested in having an API that allows widget ordering (widget ordering would be preferable to just window ordering but we could survive with just window ordering).

We have tried out a few scenarios that we thought might break with the new changes. We found that some things work OK and some things have issues. For example, setRedraw() is broken. We found a workaround (which is what makes setEnabled work) in calling gdk_x11_drawable_get_xid() to force a native window to be created. Is this an acceptable workaround or are we going to suffer performance problems?

Comment 2 Alexander Larsson 2009-08-24 09:31:37 EDT

I added a GDK_NATIVE_WINDOWS env var hack in:
http://git.gnome.org/cgit/gtk+/commit/?id=a79f929dd6c89fceeaf0d9039e5a10cad9d87d2f

Setting this allows eclipse to work as before. However, it would be nice to add the required APIs so that swt could avoid using X specific APIs, as there are several advantages with client side windows like nicer redrawing and resizing.

There is nothing that inherently doesn't work about setRedraw() when using client-side windows. However, in order to correctly emulate a window added like that requires gdk to know the correct stacking order of subwindows, and if SWT calls XReconfigureWMWindow directly then the gdk knowledge of this goes out of sync with reality and things behave differently.

Does SWT use NO_WINDOW widgets? Otherwise gdk_window_freeze/thaw_updates() may be a better approach to setRedraw(). Just an idea.

Comment 3 Bogdan Gheorghe 2009-08-24 17:41:53 EDT

Thanks for the workaround. I guess it will come out in the 2.17.9 release this week? I'll see if I can get some of our users to give it a try on their systems. 

Just to be clear, if you can provide an API for us to call that will let us set the z-order on widgets, we would definitely give it a try. 

I'll see if gdk_window_freeze/thaw_updates() will work for us. Thanks for the suggestion!

Comment 4 Alexander Larsson 2009-09-03 08:36:52 EDT

I added gdk_window_restack() in git master, which will be in the 2.17.11 release.
I made a simple test patch for swt to use this and verified that this does in fact solve the http://bugzilla.gnome.org/show_bug.cgi?id=591373 issue.

The patch is not acceptable as-is, as it requires some runtime hackery to detect when gdk_window_restack is availible, but i'm sure you guys can easily add it. I'm attaching the patch here and I'm considering the gtk+ bug closed as of this (it works with old swt versions when exporting GDK_NATIVE_WINDOWS, and without it when this patch is applied).

There is another swt bug open though, thats not even fixed by GDK_NATIVE_WINDOWS:
http://bugzilla.gnome.org/show_bug.cgi?id=589963 
I'll try to look at it, but would appreciate any input from you on possible causes of this.

Comment 5 Alexander Larsson 2009-09-03 08:37:46 EDT

Created attachment 146380 [details]
Sample patch using the new gdk API to fix the issue

Comment 6 Bogdan Gheorghe 2009-09-10 17:12:59 EDT

Thanks for the patch and the code - we will use gdk_window_restack whenever it is available.

Fixed in HEAD > 20090910

Comment 7 Andrew Overholt 2009-09-30 12:19:09 EDT

Created attachment 148442 [details]
proposed back-port patch for 3.5.1

I need to back-port this change to 3.5.1 for Fedora 12.  I used CVS timestamps to create the attached patch against 3.5.1.  Could one of the SWT committers please take a look and see if there's anything that looks incorrect?  I'm in the middle of running the tests both with and without it and will verify there are no regressions.

Thanks.

Comment 8 Bogdan Gheorghe 2009-10-02 12:06:51 EDT

Andrew, the patch looks good. We will most likely put this into the 3.5.2 release.

Comment 9 Andrew Overholt 2009-10-02 12:15:13 EDT

(In reply to comment #8)
> Andrew, the patch looks good. We will most likely put this into the 3.5.2
> release.

Thanks, Bogdan!  Are you tagging SWT + GTK 2.18 issues in bugzilla somehow?  I'd like to follow all of these issues and backport all fixes to 3.5.1 for Fedora.

Comment 10 Bogdan Gheorghe 2009-10-02 14:48:14 EDT

Sounds like a good idea - I'll mark them with [GTK2.18].

Comment 11 Michael Spector 2009-11-11 06:26:23 EST

Is there a chance to get build towards 3.5.2 that includes this patch?

Comment 12 Hiroki Kondo 2009-11-11 20:24:40 EST

+1, I'd like to get one before next major release.(and hopefully,the patch feature  will be released before 3.5.2 release.Because my RCP App can't run well on major linux near future.)
(In reply to comment #11)
> Is there a chance to get build towards 3.5.2 that includes this patch?

Comment 13 Bogdan Gheorghe 2009-11-12 16:54:47 EST

Backported fix to 3.5.x stream - will be available in next week's M build.

Fixed > 20091112

Comment 14 Andrew Overholt 2009-11-13 09:36:47 EST

Is the patch I posted here still sufficient for the 3.5.x stream, Bogdan?

Comment 15 kuznesov_yury 2009-11-18 23:32:03 EST

Created attachment 152549 [details]
error was produced by 3.5.2 M20091118

has the problem been fixed in 3.5.2 M20091118?

Comment 16 Bogdan Gheorghe 2009-11-19 18:01:40 EST

Andrew, the path you posted is fine.

Yury, the patch for this particular bug went in to the build that you tried. I'm not sure your bug is the same.

Comment 17 kuznesov_yury 2009-11-19 23:01:32 EST

sorry, my comment describes problem caused by 291128

Comment 18 Santiago Basulto 2009-12-10 19:41:58 EST

Solución en Español: http://blogs.xingular.net/santiago/sistemas-operativos/problemas-con-botones-de-eclipse-en-ubuntu-9-10/

Comment 19 Benjamin Pasero 2009-12-24 09:11:33 EST

Any chance to get this into the 3.4.2 Maintenance branch in CVS?

Comment 20 Bogdan Gheorghe 2010-01-18 14:15:10 EST

*** Bug 288909 has been marked as a duplicate of this bug. ***

Comment 21 Eleanor Joslin 2010-03-10 05:43:59 EST

*** Bug 305176 has been marked as a duplicate of this bug. ***

Comment 22 2011-04-08 16:43:56 EDT

Hello,

did this fix for this cause a regression in GEF? See Bug 321560

Comment 23 Silenio Quarti 2011-04-11 11:10:04 EDT

(In reply to comment #22)
> Hello,
> did this fix for this cause a regression in GEF? See Bug 321560

The changes for this bug are the only changes in SWT between 3.5.1 and 3.5.2 that could cause this problem.

Do you have the GDK_NATIVE_WINDOWS env var set when running with 3.5.1?

What do we need to load (GEF, etc) to reproduce bug#321560?

Comment 24 2011-04-12 14:56:28 EDT

(In reply to comment #23)
> (In reply to comment #22)
> > Hello,
> > did this fix for this cause a regression in GEF? See Bug 321560
> 
> The changes for this bug are the only changes in SWT between 3.5.1 and 3.5.2
> that could cause this problem.
> 
> Do you have the GDK_NATIVE_WINDOWS env var set when running with 3.5.1?
> 
> What do we need to load (GEF, etc) to reproduce bug#321560?

Take a look at comment in Bug 321560 for steps to reproduce.

Comment 25 Andrew Overholt 2011-04-12 15:58:10 EDT

(In reply to comment #24)
> (In reply to comment #23)
> > (In reply to comment #22)
> > > Hello,
> > > did this fix for this cause a regression in GEF? See Bug 321560
> > 
> > The changes for this bug are the only changes in SWT between 3.5.1 and 3.5.2
> > that could cause this problem.
> > 
> > Do you have the GDK_NATIVE_WINDOWS env var set when running with 3.5.1?
> > 
> > What do we need to load (GEF, etc) to reproduce bug#321560?
> 
> Take a look at comment in Bug 321560 for steps to reproduce.

I was curious so I tried the steps outlined in that bug:

> 1. On Eclipse Linux 3.6.x (try Ubuntu) create a GEF Shapes Example.
> 2. Attempt to Resize the Palette in the GEF Shapes Editor.
> 3. Now try to type on the keyboard in an Editor - no keyboard input.

I can reproduce on Fedora 15.  I actually lose keyboard input in dialogues, too (not just editors) ex. new file dialogue.  I tried with a Helios SR2 EPP package.

Comment 26 Andrew Overholt 2011-04-12 16:02:38 EDT

(In reply to comment #25)
> (In reply to comment #24)
> > (In reply to comment #23)
> > > (In reply to comment #22)
> > > > Hello,
> > > > did this fix for this cause a regression in GEF? See Bug 321560
> > > 
> > > The changes for this bug are the only changes in SWT between 3.5.1 and 3.5.2
> > > that could cause this problem.
> > > 
> > > Do you have the GDK_NATIVE_WINDOWS env var set when running with 3.5.1?
> > > 
> > > What do we need to load (GEF, etc) to reproduce bug#321560?
> > 
> > Take a look at comment in Bug 321560 for steps to reproduce.
> 
> I was curious so I tried the steps outlined in that bug:
> 
> > 1. On Eclipse Linux 3.6.x (try Ubuntu) create a GEF Shapes Example.
> > 2. Attempt to Resize the Palette in the GEF Shapes Editor.
> > 3. Now try to type on the keyboard in an Editor - no keyboard input.
> 
> I can reproduce on Fedora 15.  I actually lose keyboard input in dialogues, too
> (not just editors) ex. new file dialogue.  I tried with a Helios SR2 EPP
> package.

I can now type into the Tasks view find entrybox and other places.  I'm not sure what fixed it (I tried Alt-Tab'ing before and it didn't seem to make a difference).

Comment 27 Alexander Nyßen 2011-04-13 05:26:29 EDT

(In reply to comment #23)
> (In reply to comment #22)
> > Hello,
> > did this fix for this cause a regression in GEF? See Bug 321560
> 
> The changes for this bug are the only changes in SWT between 3.5.1 and 3.5.2
> that could cause this problem.
> 
> Do you have the GDK_NATIVE_WINDOWS env var set when running with 3.5.1?
> 
> What do we need to load (GEF, etc) to reproduce bug#321560?

Silenio, I can reproduce it on Ubuntu 10.04 LTS, as outlined in bug #321560, i.e.:

1. On Eclipse Linux 3.6.x (try Ubuntu) create a GEF Shapes Example.
2. Attempt to Resize the Palette in the GEF Shapes Editor.
3. Now try to type on the keyboard in an Editor - no keyboard input.

GDK_NATIVE_WINDOWS is not set in my environment. Is that sufficient for you to investigate? 

Due to your comment #23, re-opening this one because of the regression being introduced. It would be nice if you could deal with the problem for 3.7, as its a quite nasty thing from a GEF viewpoint (while it seems to have been in place for quite some while now).

Comment 28 Bogdan Gheorghe 2011-04-13 15:28:59 EDT

The bug that caused the GEF regression was not this one but rather Bug 290395. We have opened Bug 342755 to track this.

Closing this bug again.