Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2b1pre) Gecko/20091002 Namoroka/3.6b1pre (.NET CLR 3.5.30729) FirePHP/0.3 Build Identifier: 20090920-1017 Eclipse does not work properly with GTK+ 2.18. For instance, when I use "Show view as fast view" in the left bottom corner, click "Other", select one and then click "OK", it remains clicked forever and does nothing... It has only hover effect when mouse is over the button. There is similar problem with other buttons, also "X" (close) buttons on tabs. Reproducible: Always Steps to Reproduce: 1. click on "Show view as fast view" in the left bottom corner 2. select "Other" 3. Choose one 4. Click "OK"
using "export GDK_NATIVE_WINDOWS=true" and then running eclipse from same terminal works, but I am not sure if it is the best way as it is not default in system.
I can confirm this bug including the "export GDK_NATIVE_WINDOWS=true" hack that restores normal behavior.
GTK 2.18 introduced a new way to interact with GdkWindows. This is what introduced the problems that you are seeing and why exporting GDK_NATIVE_WINDOWS fixes it (they added that flag to allow us to revert to the old behavior). It is not the final solution, we need to see what is broken and either fix it or have GTK fix it in the next 2.18.x release. Changing priority to major as there is a workaround.
*** Bug 292097 has been marked as a duplicate of this bug. ***
*** Bug 291984 has been marked as a duplicate of this bug. ***
*** Bug 291477 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > *** Bug 291477 has been marked as a duplicate of this bug. *** Thanks! Bug 291477 was definitely a duplicate of this bug, and workaround provided in comment #1 solved this.
Well launching eclipse from terminal with having to type "export GDK_NATIVE_WINDOWS=true" every time, and have to remember the command is not a workaround to me. I use a bash script to launch eclipse witch is mush more trivial (based on Ubuntu eclipse launch script): #!/bin/sh export GDK_NATIVE_WINDOWS=true xuldir=/usr/lib/xulrunner-$(/usr/bin/xulrunner --gre-version) LD_LIBRARY_PATH=$xuldir${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} <path_to_eclipse> "$@"
I've this: #!/bin/sh export GDK_NATIVE_WINDOWS=true /usr/local/eclipse/eclipse ---------- It's enough, but there is a problem with restarting eclipse. When it's restarted, the new instance does not work properly. So I need to shut it down and start again.
*** Bug 292211 has been marked as a duplicate of this bug. ***
Just to be clear: the "export GDK_NATIVE_WINDOWS=true" is just a workaround. We are aiming for a real solution for the 3.6 release.
*** Bug 292625 has been marked as a duplicate of this bug. ***
*** Bug 292824 has been marked as a duplicate of this bug. ***
I'm experiencing even worse problems with GEF/draw2d based editors. There are really bad repaint problems, diagram elements are often not repainted and displayed in the background color instead. And GTK_NATIVE_WINDOWS doesn't seem to cure that. On a related note, Lotus Notes is also affected by this -- it doesn't repaint its views at all, making it unusable. GTK_NATIVE_WINDOWS doesn't help there either.
I experience the same. Is this bug also reported? I could not find yet. (In reply to comment #14) > I'm experiencing even worse problems with GEF/draw2d based editors. There are > really bad repaint problems, diagram elements are often not repainted and > displayed in the background color instead. And GTK_NATIVE_WINDOWS doesn't seem > to cure that. > > On a related note, Lotus Notes is also affected by this -- it doesn't repaint > its views at all, making it unusable. GTK_NATIVE_WINDOWS doesn't help there > either.
*** Bug 293540 has been marked as a duplicate of this bug. ***
*** Bug 293611 has been marked as a duplicate of this bug. ***
*** Bug 293746 has been marked as a duplicate of this bug. ***
*** Bug 293804 has been marked as a duplicate of this bug. ***
*** Bug 293847 has been marked as a duplicate of this bug. ***
*** Bug 293881 has been marked as a duplicate of this bug. ***
Why does this work without a problem in 3.6? Couldn't the respective fix be backported to 3.5? If this is possible, isn't this 3.5.1.1-worthy?
I have to use Eclipse Europa (3.3) with Ubuntu 9.10 and it seems that the provided workaround doesn't work for this version of Eclipse. My startscript: #!/bin/bash export GDK_NATIVE_WINDOWS=true /home/blackfeet/programs/eclipse-europa/eclipse The buttons still don't work as expected. Has somebody Europa running successfully on GTK 2.18 or any further ideas for a workaround?
Even with the environment variable workaround, the problem reappears when the workspace is restarted (e.g. by changing from one workspace to another). Strange as it would seem that environment variables are wiped on restart.
Is this the same bug as I'm having? I upgraded Ubuntu to 9.10, but now a number of buttons don't work any more, like the "Find" button in an editor or the "submit" button in the "report bug" window. In an Ubuntu forum someone suggested to type export GDK_NATIVE_WINDOWS=1 before starting Eclipse, which works for me. The bug applies for Eclipse 3.5 and for 3.4.
Actually, the fix doesn't work well. There's other buttons that don't work. Currently, I'm stuck: I need to finish a project for a customer but Eclipse doesn't work, I can't finish the project.
(In reply to comment #26) > Currently, I'm stuck: I need to finish a project for a customer but Eclipse > doesn't work, I can't finish the project. You should downgrade back to GTK+ 2.16.x then.
(In reply to comment #27) > (In reply to comment #26) > > Currently, I'm stuck: I need to finish a project for a customer but Eclipse > > doesn't work, I can't finish the project. > > You should downgrade back to GTK+ 2.16.x then. This means, basically, that I should go back to Ubuntu 9.04. I am now looking for the "downgrade" button in my update manager.
This is really a GTK bug, but it is not clear to me exactly where such a bug should be reported. The 2.18 GTK library was meant to be compatible with existing applications, and is not. Fixing this in future versions of Eclipse will only help new and newly updated installations. Applications based on Eclipse will be fixed when (and if) the developers get around to updating those applications. (Do not under-estimate this cost, especially to in-house developers, where the making changes to actively used working applications always has a cost.) Fixing this in GTK will in one step remove the problem in *all* currently impacted applications. Other related bug reports: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550183 https://bugs.launchpad.net/ubuntu/+source/swt-gtk/+bug/463086 https://bugs.launchpad.net/gtk/+bug/442078 https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/458703
(In reply to comment #29) > This is really a GTK bug, but it is not clear to me exactly where such a bug > should be reported. > Well, if this is only a GTK bug, this should be deeply inspected as well https://bugs.eclipse.org/bugs/show_bug.cgi?id=291257#c22 Anyone using 3.6 can report this bug to be solved ?
If it's a gtk bug, shouldn't it affect all applications that use SWT? I just tested one of my apps that uses SWT and I see no issues there.
The buttons seem to work in 3.6, at least the ones that I found are not working in 3.5.1.
(In reply to comment #32) > The buttons seem to work in 3.6, at least the ones that I found are not working > in 3.5.1. This definitively has cleared the situation: https://bugs.launchpad.net/gtk/+bug/442078/comments/28 Anyway,changes in the native gtk break things seriously as in this case: I consider this as a major bug and the swt component changeset from 3.6 should be immediately merged back in 3.5 and released, at least the portion inherent this bug. thank you for your try anyway
Hey Guys, I'm a noob at this bug reporting thing so apologies if I'm not following best practice or something. I found this to be a problem too (Aptana Studio 2 and Eclipse) on Ubuntu 9.10. I've found a simple workaround for those, such as Christine, who need to move forward on a project... If you simply hover the mouse over the button in question (to highlight it) and then press enter, it works. I know it's not a solution but it's a temporary workaround. Hope it's useful :)
(In reply to comment #34) > Hey Guys, > > I'm a noob at this bug reporting thing so apologies if I'm not following best > practice or something. > > I found this to be a problem too (Aptana Studio 2 and Eclipse) on Ubuntu 9.10. > > I've found a simple workaround for those, such as Christine, who need to move > forward on a project... > > If you simply hover the mouse over the button in question (to highlight it) and > then press enter, it works. > > I know it's not a solution but it's a temporary workaround. > > Hope it's useful :) It also works with Space button I think.. ;)
*** Bug 294964 has been marked as a duplicate of this bug. ***
*** Bug 295173 has been marked as a duplicate of this bug. ***
Just a side note: While the GDK_NATIVE_WINDOWS seems to initially work, if I do a Switch Workspace, it stops working.
Even though setting -- export GDK_NATIVE_WINDOWS=true -- helps a restoring *some* of the functionality, I have noticed that: 1. The menu options are still missing icons 2. Update Manger will hang indefinitely if it comes across unsigned jar (very annoying, I can't install subclipse, and am stuck) It's just my guess that the above two issues are related to this bug, since I didn't see them in previous versions of Ubuntu. Please let me know if some one else is experiencing these problems as well.
(In reply to comment #39) > 1. The menu options are still missing icons See bug 293720. > 2. Update Manger will hang indefinitely if it comes across unsigned jar (very > annoying, I can't install subclipse, and am stuck) I've not heard of this one. You could run some Bugzilla queries and check if others have hit the problem (RT/Equinox/p2).
Just found out all our Eclipse-based RCP apps have this problem on Ubuntu Koala. Woah! I'm confused as to whether this is an Eclipse bug. If so, is there an imminent fix?
(In reply to comment #40) Thanks for your response. > (In reply to comment #39) > > 1. The menu options are still missing icons > > See bug 293720. I checked it out, and is what I am experiencing with the newer version of gtk > > > 2. Update Manger will hang indefinitely if it comes across unsigned jar (very > > annoying, I can't install subclipse, and am stuck) > > I've not heard of this one. You could run some Bugzilla queries and check if > others have hit the problem (RT/Equinox/p2). I haven't found anything yet, will keep looking.
(In reply to comment #3) > GTK 2.18 introduced a new way to interact with GdkWindows. This is what > introduced the problems that you are seeing and why exporting > GDK_NATIVE_WINDOWS fixes it (they added that flag to allow us to revert to the > old behavior). It is not the final solution, we need to see what is broken and > either fix it or have GTK fix it in the next 2.18.x release. > > Changing priority to major as there is a workaround. It might be a workaround if you are a Eclipse developer, but not if you are an end user / customer with an RCP application running on Ubuntu Koala. We are now getting this bug report in from our Linux users for our RCP apps. The ideal situation for us would be to put the fix into the 3.5.x stream so that we could do a rebuild against it, otherwise we will have to tell our users that the app is broke until June 2010. Or we could build against 3.6 M2, but that introduces all kinds of other problems for us.
(In reply to comment #43) > The ideal situation for us would be to put the fix into the 3.5.x stream so > that we could do a rebuild against it Some fixes have been backported to the 3.5.x stream, this may be resolved now. http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg08746.html Note that I say "may" because I'm not on the SWT team and don't know the details. ;)
As Remy noted, we've backported the fixes we've put in to 3.6 for 2.18 issues into the 3.5.x maintenance stream. The best thing to do is to try out your app using a recent 3.5.x build (either last week's or today's) and let us know if you are still having problems.
(In reply to comment #45) > As Remy noted, we've backported the fixes we've put in to 3.6 for 2.18 issues > into the 3.5.x maintenance stream. The best thing to do is to try out your app > using a recent 3.5.x build (either last week's or today's) and let us know if > you are still having problems. Thanks Bogdan and Remy for that information (I tried to find out if it had been backported before I posted on here but couldn't find anything.) Anyway, I tried it with the Eclipse build SDK-M20091118-0800 and it fixed the button problem, so I shall rebuild our RCP apps against that. Great stuff, thanks! BTW - I did notice in Eclipse's Update Manager window on Ubuntu that the Tree-table was not displaying properly. Is this related to this bug?
(In reply to comment #46) > Anyway, I tried > it with the Eclipse build SDK-M20091118-0800 and it fixed the button problem, > so I shall rebuild our RCP apps against that. Great stuff, thanks! Good to hear. > BTW - I did notice in Eclipse's Update Manager window on Ubuntu that the > Tree-table was not displaying properly. Is this related to this bug? You want bug 290395.
3.5.2 fixes the problem, but as Philip says, the update manager doesn't work, I can't install any plugins.
Sometimes my Eclipse "hangs". The cursor keeps the shape of the text edit cursor, regardless of whether it's in the Eclipse window or not. Buttons don't work, menu items don't work. I exit Eclipse with alt-f/x, but even then my mouse doesn't work. Only after a while, my Ubuntu gets back to normal. To me it seems like the issue is not just in Eclipse. I do use the workaround for this bug but apparently the workaround is not perfect. But then, nothing's perfect, is it?
*** Bug 296414 has been marked as a duplicate of this bug. ***
Hmm, we do need a 3.5.1.1. Anyone considering how we could get the fix out now? Other than patching the SRPM for your favorite distro?
When will 3.5.2 come out?
(In reply to comment #52) > When will 3.5.2 come out? Current target would be February 26, 2010. http://wiki.eclipse.org/Galileo#SR2
Doug, most distros shipping 3.5.1 are carrying a workaround AFAIK.
Andrew, Not all linux users of Eclipse do use the version that ship with the distro. That issue with GTK is actually a really big issue for both Eclipse and Linux. Using last week IBuild of 3.6 stream, I cannot install any new plugin (subclipse), making Eclipse useless for me on that computer right now. (same problem as comment 39) A warning on Eclipse download page is necessary IMHO.
Daniel, I wasn't trying to imply that everyone (or even lots of people :) do. I was just addressing Doug's comment about having to patch by saying that we already do.
What about the update issue?
(In reply to comment #57) > What about the update issue? I have no issues installing unsigned JARs.
Ok: the update issue is really a refresh problem. the panel is not refreshed properly so the plugins to install with the checkboxes do not appear after being retrieved from the internet. If I change to another virtual desktop and come back to the initial one, I can see the plugins and select them...
The problem I experienced was that the update manager, presents the user with a warning that the jar to be installed is an unsigned one. However, this warning is not presented to the user, and is only displayed after the user hits cancel on the current progress monitor. Until then it appears to hang indefinitely. So after I cancel update, it gives me the option to continue with the unsigned jar, which is pointless. Did you experience the same issue? (In reply to comment #59) > Ok: the update issue is really a refresh problem. the panel is not refreshed > properly so the plugins to install with the checkboxes do not appear after > being retrieved from the internet. > > If I change to another virtual desktop and come back to the initial one, I can > see the plugins and select them...
Not exactly, because I have the "run in background" option enabled. But I noticed the unsigned jar warning as well.
(In reply to comment #59) > Ok: the update issue is really a refresh problem. This is bug #290395.
(In reply to comment #53) > Current target would be February 26, 2010. > http://wiki.eclipse.org/Galileo#SR2 Three months from now, hmm. Backporting a fix to 3.5.1 requires a certain amount of work. Can 3.5.2 be released earlier if that time is spent on 3.5.2 instead of on the back port? Just curious..
(In reply to comment #63) > Backporting a fix to 3.5.1 requires a certain amount of work. You mean trying to make a 3.5.1.1 a reality? To be fair, there has been a 3.3.1.1 in the past. http://archive.eclipse.org/eclipse/downloads/drops/R-3.3.1.1-200710231652/index.php > Can 3.5.2 be > released earlier if that time is spent on 3.5.2 instead of on the back port? I believe those dates are defined by the Planning Council. http://wiki.eclipse.org/Planning_Council/Mar_22_2009 I presume the Eclipse SDK (which SWT is a part of) would want to align with the rest of the Galileo participants, but maybe not. So I would say your options are to a) convince the Eclipse PMC members to make a 3.5.1.1 happen or b) to release 3.5.2 before the Galileo SR2 date, or c) convince the Planning Council to move the SR2 dates up. Alternatively, you could build your Eclipse-based products on top of a current maintenance build like what Phillip seems to be doing based on comment 46. Some kind of patching mechanism flushed out by p2 might be possible though I'm unfamiliar with that space.
A heads up for people still dealing with this: if a button can't be clicked but has a hotkey attached to it (e.g. Alt+N for a Next button with an underlined 'N') then striking that key combination usually works.
(In reply to comment #64) > Alternatively, you could build your Eclipse-based products on top of a current > maintenance build like what Phillip seems to be doing based on comment 46. I don't have an Eclipse based product, I just use Eclipse for developing apps, so if needed I can live with the current version until 3.5.2. A problem arises if I want to install a new plugin or I want to install Eclipse on a new computer, but I guess that with some effort, Eclipse will still work. Is there anything I can do to help fix the problem?
(In reply to comment #66) > I don't have an Eclipse based product, I just use Eclipse for developing apps, > so if needed I can live with the current version until 3.5.2. If that's the case then it's not clear to me why you can't just grab one of the maintenance builds and use that for your work instead. I suppose your concern is that these weekly maintenance builds are not "stable". > A problem arises > if I want to install a new plugin or I want to install Eclipse on a new > computer, but I guess that with some effort, Eclipse will still work. > > Is there anything I can do to help fix the problem? For the p2 system not showing stuff (assuming you and I are talking about the same thing), there is, as aforementioned, bug 290395 for that. Bogdan has managed to release a fix for that into HEAD (see bug 290395 comment 26 and down), if everyone that's using GTK+ 2.18.x would be kind enough to try out one of the nightly 3.6 builds and provide feedback on that bug (not this bug, buttons problems goes here, p2 system tree not showing stuff goes there), it would be most helpful in assessing whether the fix that has been committed resolves the problem for the general populace or not. Thanks in advance for taking the time in helping make the Eclipse platform better.
*** Bug 296654 has been marked as a duplicate of this bug. ***
(In reply to comment #67) > If that's the case then it's not clear to me why you can't just grab one of the > maintenance builds and use that for your work instead. I suppose your concern > is that these weekly maintenance builds are not "stable". I did just that and found that adding plugins didn't work in the maintenance build. I'll try again with the latest maintenance build.
(In reply to comment #67) > it > would be most helpful in assessing whether the fix that has been committed > resolves the problem for the general populace or not. In 3.6 buttons work ok. Some other features don't work in 3.6.
Version: 3.6.0 Build id: N20091202-2000 Both button and refresh tree problems are fixed for me (Mandriva 2010).
All - please see if buttons are working on your distro in the N20091201-2000 or N20091202-2000 builds. Thanks!
Buttons work fine for me on Fedora 12 with N20091203-2044-linux-gtk-x86_64. gtk2-2.18.3-21.fc12.x86_64. *No* GDK_NATIVE_WINDOWS=true.
(In reply to comment #73) Same here on Debian unstable with GTK 2.18.4-1. Thanks!
I was able to install N20091202-2000, on Ubuntu 9.1. Seems to be working-- the buttons work fine, as well as the update manager didn't hang up on the unsigned jar. Thanks for the good work. Does anyone know of an easy way to take the eclipse SDK classic IDE and add all the JEE plug-ins? Thanks again! (In reply to comment #72) > All - please see if buttons are working on your distro in the N20091201-2000 or > N20091202-2000 builds. Thanks!
I meant to ask if there is an easy way to update the classic IDE with all the plugin needed for JEE development. Right now, I'm updating feature by feature i.e. EMF GEF WTP etc... (In reply to comment #75) > I was able to install N20091202-2000, on Ubuntu 9.1. Seems to be working-- > the buttons work fine, as well as the update manager didn't hang up on the > unsigned jar. Thanks for the good work. > > Does anyone know of an easy way to take the eclipse SDK classic IDE and add all > the JEE plug-ins? > > Thanks again! > > (In reply to comment #72) > > All - please see if buttons are working on your distro in the N20091201-2000 or > > N20091202-2000 builds. Thanks!
Failed. I am on OpenSuse 11.2. I downloaded the "platform SDK" about 98 mb, of N20091202-2000 Nothing works, it cannot find an editor and does not display any files. Should I have downloaded the "Eclipse SDK", full 160 mb? Meanwhile the bugs on my older Eclipse version have become worse. Almost whatever I do makes Eclipse crash. Unusable. Suggestions welcome.
If you want to edit java code, try the Eclipse SDK. You should be able to create a new project and open a text editor with the platform SDK but you won't get any Java editors if you open an existing workspace that contains java code.
Bogdan, Thanks, that works. It's that I never had to use the full-fledged Eclipse SDK and to restart from scratch by starting a new project (both were required here). I confirm that the "new project" "finish" button works, allowing creating a new project from buttons, as opposed to keyboard shortcuts. (Eclipse Helios from 2 December, intel 32bit, GTK, on openSuse 11.2 with Sun Java 1.6 jre). Thanks, also for replying so quickly. Ettore
(In reply to comment #72) > All - please see if buttons are working on your distro in the N20091201-2000 or > N20091202-2000 builds. Thanks! M20091202-0800 x86_64 works for Ubuntu 9.10 and libgtk2 2.18.3. Thanks!
*** Bug 297014 has been marked as a duplicate of this bug. ***
*** Bug 298225 has been marked as a duplicate of this bug. ***
Fedora 12 (i386) Eclipse SDK 3.5.1(32bit) (include springsource tool suite and jboss tools) Sun java 6 update 17 I did not know if "export GDK_NATIVE_WINDOWS=true" works. When I composed a shell script according to these comments, and started up eclipse, it frozen and had no response... and ate up all of my memory. So the option is no effects to me. If this is a gtk bug, why other gtk application does not produce this problem.
To solve the issue of restarting eclipse or switching the workspace, I prefer to put the variable in the "eclipse.ini" file: -DGDK_NATIVE_WINDOWS=1 It's better than a shell script in my opinion, and I guess it should work when restarting or switching workspaces. Please correct me if I am wrong.
(In reply to comment #84) > To solve the issue of restarting eclipse or switching the workspace, I prefer > to put the variable in the "eclipse.ini" file: > > -DGDK_NATIVE_WINDOWS=1 > > It's better than a shell script in my opinion, and I guess it should work when > restarting or switching workspaces. Please correct me if I am wrong. Sounds like a good, portable solution to me - if it works. Who reads this variable anyway? Is it SWT or gtk?
Interesting enough, eclipse 3.3 (Europa, 3.3.2 M20080221-1800) drops the GDK_NATIVE_WINDOWS, as seen running under strace: strace -e trace=execve -r -v -f ./eclipse -data $HOME_PLC/workspace ---- output ---- 0.000000 execve("./eclipse", ["./eclipse", "-data", "/home/test/jCompany/workspace"], ["ORBIT_SOCKETDIR=/tmp/orbit-test"..., "SSH_AGENT_PID=2879", "PLC_MEUS_PROJETOS=/meus_projetos", "TERM=xterm", "SHELL=/bin/bash", "CATALINA_HOME=/servers/tomcat", "ECLIPSE_HOME=/eclipse", "XDG_SESSION_COOKIE=a30e27254c439"..., "GTK_RC_FILES=/etc/gtk/gtkrc:/hom"..., "WINDOWID=41943044", "GDK_NATIVE_WINDOWS=1", "OLDPWD=/home/test/jCompany", "GTK_MODULES=canberra-gtk-module", "USER=test", "LS_COLORS=rs=0:di=01;34:ln=01;36"..., "GNOME_KEYRING_SOCKET=/tmp/keyrin"..., "SSH_AUTH_SOCK=/tmp/keyring-786ap"..., "SESSION_MANAGER=local/praga:@/tm"..., "USERNAME=test", "DESKTOP_SESSION=gnome", "PATH=/home/test/bin:/usr/loca"..., "LC_MESSAGES=en_US.UTF-8", "GDM_XSERVER_LOCATION=local", "PWD=/home/test/jCompany/eclip"..., "LANG=pt_BR.UTF-8", "GDM_LANG=pt_BR.UTF-8", "GDMSESSION=gnome", "HISTCONTROL=ignoreboth", "SHLVL=1", "HOME=/home/test", "GNOME_DESKTOP_SESSION_ID=this-is"..., "LOGNAME=test", "DBUS_SESSION_BUS_ADDRESS=unix:ab"..., "XDG_DATA_DIRS=/usr/share/gnome:/"..., "WINDOWPATH=7", "DISPLAY=:0.0", "HOME_PLC=/home/test/jCompany", "COLORTERM=gnome-terminal", "XAUTHORITY=/home/test/.Xautho"..., "_=/usr/bin/strace"]) = 0 0.106706 execve("./eclipse", ["./eclipse", "-data", "/home/test/jCompany/workspace"], ["ORBIT_SOCKETDIR=/tmp/orbit-test"..., "SSH_AGENT_PID=2879", "PLC_MEUS_PROJETOS=/meus_projetos", "TERM=xterm", "SHELL=/bin/bash", "CATALINA_HOME=/servers/tomcat", "ECLIPSE_HOME=/eclipse", "XDG_SESSION_COOKIE=a30e27254c439"..., "GTK_RC_FILES=/etc/gtk/gtkrc:/hom"..., "WINDOWID=41943044", "OLDPWD=/home/test/jCompany", "GTK_MODULES=canberra-gtk-module", "USER=test", "LS_COLORS=rs=0:di=01;34:ln=01;36"..., "GNOME_KEYRING_SOCKET=/tmp/keyrin"..., "SSH_AUTH_SOCK=/tmp/keyring-786ap"..., "SESSION_MANAGER=local/praga:@/tm"..., "USERNAME=test", "DESKTOP_SESSION=gnome", "PATH=/home/test/bin:/usr/loca"..., "LC_MESSAGES=en_US.UTF-8", "GDM_XSERVER_LOCATION=local", "PWD=/home/test/jCompany/eclip"..., "LANG=pt_BR.UTF-8", "GDM_LANG=pt_BR.UTF-8", "GDMSESSION=gnome", "HISTCONTROL=ignoreboth", "SHLVL=1", "HOME=/home/test", "GNOME_DESKTOP_SESSION_ID=this-is"..., "LOGNAME=test", "DBUS_SESSION_BUS_ADDRESS=unix:ab"..., "XDG_DATA_DIRS=/usr/share/gnome:/"..., "WINDOWPATH=7", "DISPLAY=:0.0", "HOME_PLC=/home/test/jCompany", "COLORTERM=gnome-terminal", "XAUTHORITY=/home/test/.Xautho"..., "_=/usr/bin/strace", "LD_LIBRARY_PATH=/usr/lib/jvm/jav"..., "MOZILLA_FIVE_HOME=/usr/lib/xulru"...]) = 0 ---- cut here ---- The first "execve" seems to be a normal one (shell execs to load eclipse). Eclipse then reexecs, dropping *JUST* GDK_NATIVE_WINDOWS. Eclipse 3.4 (Ganymede) under strace still exhibits the double execve, but this time does not fiddle arround with GDK_NATIVE_WINDOWS.
(In reply to comment #86) > > The first "execve" seems to be a normal one (shell execs to load eclipse). > Eclipse then reexecs, dropping *JUST* GDK_NATIVE_WINDOWS. > > > Eclipse 3.4 (Ganymede) under strace still exhibits the double execve, but this > time does not fiddle arround with GDK_NATIVE_WINDOWS. There seems to be a "workaround" for the GDK_NATIVE_WINDOWS workaround when spawning child processes in GTK. Not sure if this really makes much sense... Commit cf. http://osdir.com/ml/svn-commits-list/2009-08/msg09111.html
(In reply to comment #87) > (In reply to comment #86) > > > > The first "execve" seems to be a normal one (shell execs to load eclipse). > > Eclipse then reexecs, dropping *JUST* GDK_NATIVE_WINDOWS. > > > > > > Eclipse 3.4 (Ganymede) under strace still exhibits the double execve, but this > > time does not fiddle arround with GDK_NATIVE_WINDOWS. > > There seems to be a "workaround" for the GDK_NATIVE_WINDOWS workaround when > spawning child processes in GTK. Not sure if this really makes much sense... > > Commit cf. http://osdir.com/ml/svn-commits-list/2009-08/msg09111.html That leaves us two questions: 1. why this behavior does not occur in Ganymede? 2. how do we work around the workaround to the workaround? (and how to avoid a 4th order workaround for our 3rd order workaround?) I understand that the main issue may lie in gdk or swt, or whatever. But for the time of being I will be happy if I can use the GDK_NATIVE_WINDOWS hack in Eclipse Europa.
*** Bug 298899 has been marked as a duplicate of this bug. ***
(In reply to comment #88) > That leaves us two questions: > 1. why this behavior does not occur in Ganymede? > 2. how do we work around the workaround to the workaround? (and how to avoid a > 4th order workaround for our 3rd order workaround?) > > I understand that the main issue may lie in gdk or swt, or whatever. But for > the time of being I will be happy if I can use the GDK_NATIVE_WINDOWS hack in > Eclipse Europa. That commit about "Don't propagate GDK_NATIVE_WINDOWS to child processes" in the gdk.c file was submitted on 31st Aug 2009. Thus it cannot be part of Eclipse 3.3.2 (Europa). Can it?
*** Bug 299220 has been marked as a duplicate of this bug. ***
> That commit about "Don't propagate GDK_NATIVE_WINDOWS to child processes" in > the gdk.c file was submitted on 31st Aug 2009. Thus it cannot be part of > Eclipse 3.3.2 (Europa). Can it? This commit is in GTK, or GDK even, it is not part of Eclipse at all. GTK is a system library on your Linux installation. The commit ensures that child processes (e.g. processes that Eclipse launches) don't inherit the GDK_NATIVE_WINDOWS environment variable. Thus, Eclipse needs to explicitly pass that variable on whenever it launches another SWT application, e.g. a runtime workbench.
*** Bug 299590 has been marked as a duplicate of this bug. ***
I am closing this as FIXED as the original problem described here has been resolved as of 20091203. Fixed in HEAD > 20091203.
(In reply to comment #95) > I am closing this as FIXED as the original problem described here has been > resolved as of 20091203. > > Fixed in HEAD > 20091203. I assume this is only included in the 3.6 eclipse version (3.6M4), am I right? Or will there be some 3.5 version including this fix?
(In reply to comment #96) > (In reply to comment #95) > > I am closing this as FIXED as the original problem described here has been > > resolved as of 20091203. > > > > Fixed in HEAD > 20091203. > > I assume this is only included in the 3.6 eclipse version (3.6M4), am I right? > Or will there be some 3.5 version including this fix? See comment 45.
(In reply to comment #97) > (In reply to comment #96) > > (In reply to comment #95) > > > I am closing this as FIXED as the original problem described here has been > > > resolved as of 20091203. > > > > > > Fixed in HEAD > 20091203. > > > > I assume this is only included in the 3.6 eclipse version (3.6M4), am I right? > > Or will there be some 3.5 version including this fix? > > See comment 45. Just to be clear, this only "fixes" the problem for folk if and when they can use the currently-unreleased Eclipse code. For all the folk using current and older versions of Eclipse, and for all the folk using applications built on the Eclipse platform, the problem remains unresolved. I know that the above fix is all that can be done in the Eclipse code (and likely a good idea for the future), so nothing wrong with closing the bug recorded against Eclipse. But the fault was introduced by a backwards-incompatible change in GTK 2.18, not by a change in Eclipse (which is why previously-working applications suddenly had a problem). The proper place for a "fix" would be in GTK. The aim of this note is to make clear to later readers that the root problem is in the GTK, and that problem cannot be counted as solved.
(In reply to comment #98) > The aim of this note is to make clear to later readers that the root problem is > in the GTK, and that problem cannot be counted as solved. I thought: <quote> Patrick: Your assumption is wrong to start with. The bug is not in GTK+, but in Eclipse. Starting from 2.18 on, GTK+ changed some of its internal behaviour (google for "client side windows"). This change is intentional, and needed for other development. It doesn't make any difference to programs using GTK+ correctly, but it makes problems with programs that use GTK+ in weird ways, making wrong assumptions that only accidentally worked in the past. So, to ease the transition until those programs get fixed, an environment variable has been introduced to simulate the old behaviour. So it's really up to the eclipse guys to fix their code, and to make sure they set this variable as a workaround until then in their own distribution. Ubuntu doesn't have any influence on that. </quote> was that not true?
The 2.18 version of the GTK was intended and advertised as backwards compatible, but is not. Instead it broke a large number of long-in-use applications for a large number of users. The GTK folk had reason (and I assume good reason) for changing behavior. They believed the change would not have significant effect on applications, so they included the change in an incremental release meant to be compatible - and there is nothing wrong in that. But in reality, they were wrong. Yes, there is a theoretic argument (that I will assume is sound) that usage in the Eclipse platform (and possibly other applications) was not in some sense "proper". Building and releasing software is a practical exercise, not an exercise in theory. This is pretty much the entire reason we have major and minor releases. The community depends on stability and backwards compatibility in minor releases, and expects more disruptive change in major releases. When you break large numbers of stable, existing applications - that is not a backwards compatible change, and does not belong in a minor release. The GTK folk meant well, but they goofed. It happens. If you work on a shared library with a large number of users, odds are it will happen to you, eventually. (So this is not a general criticism of the GTK folk, as I am rather impressed with their work.) The best response is to limit the harm to the smallest number of users for the shortest period of time. That means finding a way to remove the impact. (Backing out the change is usually simplest.) In the long term, we likely want both the change in GTK and in Eclipse - but disruptive change is for major versions, not minor versions.
*** Bug 299896 has been marked as a duplicate of this bug. ***
(In reply to comment #100) > In the long term, we likely want both the change in GTK and in Eclipse - but > disruptive change is for major versions, not minor versions. Fair enough. I'm just trying to judge how likely getting a fix into GTK is given their statement that it was changed on purpose. It may be easier to influence the Platform team to back port this fix to earlier releases and respin them.
Yep. That is the big question.
*** Bug 301224 has been marked as a duplicate of this bug. ***
*** Bug 301225 has been marked as a duplicate of this bug. ***
*** Bug 295797 has been marked as a duplicate of this bug. ***
*** Bug 303320 has been marked as a duplicate of this bug. ***
I'm using Version: 3.5.2 Build id: M20100211-1343 and I'm still having this problem. I've read in a few places this is fixed both in the upcoming 3.6 and 3.5.2, but this doesn't seem to be the case.
*** Bug 293898 has been marked as a duplicate of this bug. ***
*** Bug 291736 has been marked as a duplicate of this bug. ***
*** Bug 329419 has been marked as a duplicate of this bug. ***
