Buttons in Eclipse not working correctly with GTK+ 2.18.1-1

Also when you try to install new software in eclipse 3.5 via Help > Install New Software The available plugins don't show up, they are there, cuz when you click on the blank table, the details tab changes.

duplicate bug #441905?

Just to confirm I'm also experiencing this with the 64bit PHP bundle from http://www.eclipse.org/downloads/ on Karmic with gtk2.18.1-1.

fixed with latest gtk+2.0 update

closing the bug

Looks like the bug happens too with libgtk2.0-0 version 2.18.1-1ubuntu1

(at least the buttons not working until "enter" key pressed, and the install new software screen bug)

The bug will need to be sent upstream by an eclipse user then

As explained in eclipse bug 291257 adding setting GDK_NATIVE_WINDOWS environment variable to "1" ("export GDK_NATIVE_WINDOWS=true") before running eclipse solves the problem.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=291257

As explained in eclipse bugzilla bug 291257, setting environment variable "GDK_NATIVE_WINDOWS" to true is a workarround for the problem, but looks like is a eclipse/swt bug.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=291257

did you get the issue using gtk 2.18.0 or did it start only with 2.18.1?

i was to fast to declare the bug fixed. i just saw that the problems with the buttons persists after the gtk+ update (2.18.1). Just closing editor windows (x) as described in an other bug report was fixed.

I do not know if it happens on 2.18.0 i only tested in 2.18.1 (when i installed 9.10 beta), but aparently from the original bug report it only happens in 2.18.1+.

Everything works fine for me with 2.18.0

This completely breaks Eclipse, how can it be priority LOW???

LosD

Just set
export GDK_NATIVE_WINDOWS=true

before launching eclipse and it works fine

Jaap

On Sun, Oct 11, 2009 at 13:01, LosD <email address hidden> wrote:
> This completely breaks Eclipse, how can it be priority LOW???
>
> --
> Buttons in Eclipse not working correctly with GTK+ 2.18.1-1
> https://bugs.launchpad.net/bugs/442078
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in gtk: New
> Status in “gtk+2.0” package in Ubuntu: New
>
> Bug description:
> I downloaded eclipse from eclipse.org. With gtk2.18.0-1 in Karmic it works fine. After upgrading to gtk2.18.1-1 I can't close tabs in the edit window anymore and also when a fire up a dialog to create a new class when I click on the button Finish nothing is happening
>
>
>

> how can it be priority LOW???

eclipse is not a software installed by default and the bug is easy to workaround by setting a variable

Wow, thanks for that variable setting! I've been silently suffering when a quick google search resulted in this bug report. I used to just click on the button with nothing happening (thankfully it did get focus, so I just got used to hitting the space bar to invoke the button's action)

Cheer!

The issue is not solved yet. Using Karmic 64bit.

Of course it might be possible to quickfix by using a env-variable.
At the end it harms the ubuntu-experience thou.
Especially as eclipse is used quite a bit in the community it
will be more then a LOW prio paper-cut.

The result is simply: "Eclipse does not work right in the new ubuntu version".
Not: "Of course, my mistake I did not set the variable"

cheers

It also diable a lot of buttons in views from plugins like the ADT (Android Development Tool).
This is NOT a LOW priority!

I agree with Cos Costa. It hurts the perception. I have a bunch of developers here that I'm trying to convince to switch to Ubuntu. The ones who have made the switch are running Jaunty at the moment and I'll have to "coach" them about this problem. It should work out of the box.

The issue is an eclipse one and the bug is trivial to workaround by exporting a variable can we move on there?

It looks as though JProfiler suffers from the same issue, probably several other Java apps too. Rather than launch all Java apps from the command-line, is there some way to set GDK_NATIVE_WINDOWS across-the-board so that apps run from shortcuts benefit from this work-around?

Adding "export GDK_NATIVE_WINDOWS=true" to ~/.profile seems to have no effect on my machine - could it be that the value is overridden subsequent to .profile being sourced?

The bug is still present in ubuntu and kubuntu 9.10 on eclipse 3.4 and 3.5 either installed from eclipse.org or zend.org.
zend studio even brings his own jre to run eclipse.

eclipse from the ubuntu repository works, but is unable to install any php dev extensions due to version problems of dependencies...

When I use the export statement then In can start eclipse in the shell without the problems

Ubuntu folks can't fix bugs in software that you download from eclipse.org or zend.org. It's up to them to fix the software they offer. The Eclipse package in the repo contains the workaround, and I don't see what else could possibly be done on Ubuntu's side.

Patrick, eclipse 3.5 works fine if you install eclipse from the ubuntu archives (sudo apt-get install eclipse). In that package /usr/bin/eclipse contains "export GDK_NATIVE_WINDOWS=true" so the buttons work

When the bug is in gtk that is provided by ubuntu 9.10, how should I get this bug fixed in this case?
The eclipse packages from the net work fine with older GTK versions for example from ubuntu 9.04. How du you expect the ubuntu users in the world to react? Abandon all software that is not from ubuntu repositories because there is a bug in gtk that has a workaround in some ubuntu packages?

Using eclipse from the repositories is not an option for me because you get dependency problems with many plugins from update sites.

It would be sad if this bug wouldn't be fixed. There are many eclipse users out there that use ubuntu, which now have trouble to run it properly.

> When the bug is in gtk that is provided by ubuntu 9.10, how should I get this bug fixed in this case?

GTK did change but the bug is not a gtk one but an eclipse issue, sometime software do things in a weird way which happens to work by chance that doesn't mean they do it correctly and that they will keep working

> There are many eclipse users out there that use ubuntu, which now have trouble to run it properly.

Then lobby to eclipse so they fix their software or set the variable, is it so hard to set an environment variable?

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.

The only possible workaround that could be done in Ubuntu was to set that variable globally by default. That may break (correctly working) apps, just in order to work around broken ups from 3rd party sources. Doesn't seem like a good idea to me.

Thanks Bernd, that explains the effekt of the environment variable.

You're right. I have assumed a bug in GTK.

I also have this problem with zend studio for eclipse 7.

will "export GDK_NATIVE_WINDOWS=true" solve the problems ?

>I also have this problem with zend studio for eclipse 7. will "export GDK_NATIVE_WINDOWS=true" solve the problems ?

not sure what about you try and tell us since you use that software, you could have tried in less time that you used to comment there...

Alex, it works here

@Sebastien, yes I probably would, but maybe I commented from work, where I dont use ubuntu 9.10 and now I got home.

I created a new file called Zend, chmod +x and added this:

#!/bin/sh
export GDK_NATIVE_WINDOWS=true
/home/alex/Zend/ZendStudio-7.0.2/ZendStudio

Now it works great.

Same problem than #458703 ?
The lastest release of eclipse in karmic fixed that.

The same problem occurs in Vuze as well. As far as I know, both Eclipse and Vuze use SWT GTK. The workaround of setting the GDK_NATIVE_WINDOWS variable also solves it in Vuze.

Seems the work-around of setting the GDK_NATIVE_WINDOWS environment variable is a bit uncertain. In my case, now I am getting a hard fault in the GTK library (not really an improvement).

This really needs to get fixed in GTK.

For those who would not like to use GDK_NATIVE_WINDOWS as a workaround consider using the hotkeys of those buttons instead of the mouse (which works just fine) until the eclipse team adjusted their software to the "new" GTK+ behaviour.

Thanks for your information. I'm using the hotkeys in Eclipse, yet it
happens in Vuze as well, and those buttons in Vuze that I need to click
don't have any hotkeys.

Ralf Oltmanns wrote:
> For those who would not like to use GDK_NATIVE_WINDOWS as a workaround
> consider using the hotkeys of those buttons instead of the mouse (which
> works just fine) until the eclipse team adjusted their software to the
> "new" GTK+ behaviour.
>
>

Try to mark a button with a left click and press space. Perhaps this will work :-)

Today I hit an issue that raises the severity for me - I've been running with GDK_NATIVE_WINDOWS=true happily, however today I wanted to launch self-hosted Plugin Development Environment (PDE), where under-development plugins are hosted in a new Workbench instance launched from the original Eclipse Workbench.

I couldn't see immediately how to set GDK_NATIVE_WINDOWS=true on the target PDE runtime Workbench launched - the setting does _not_ propagate automatically to the new process.

This is very similar to bug 410407. If it is really a gtk+2.0 bug, shouldn't it be marked as duplicate?

I appear to have "GDK_NATIVE_WINDOWS=true" in my "eclipse" script already, but I'm finding that I'm still having problems with buttons in Eclipse. If I use the keyboard accelerators for the buttons, they work fine, but if I click the button, it presses in, but nothing else happens. While inside the dialog, my mouse cursor is a pointer, but outside of the dialog, it's the rotating ball (I don't know what else to call it). My test case is the plugin installation dialog. I haven't tried to do anything else with this installation of Eclipse on Ubuntu yet. Considering my experience so far, I doubt I'll be able to do anything useful with this.

It appears I wasn't executing the script I thought I was. I'm now certain I'm setting that variable to '1", and it now appears to work. Pressing buttons no works.

Having just hit this, it's unfair to blame any particular group. You can't blame the eclipse team as "their code worked"; you can't blame the GTK team as "they followed the spec". Its just together, it makes the transition to Ubuntu 9:10 the most painful ubuntu upgrade for a while, certainly I'm not enjoying it much on the two machines I've upgraded.

If you ever have the opportunity to look at the windows OS code, you will see truckloads of compatbility flags that get set on an app-by-app basis; MS believe that backwards compatibility is the strength of their OS, though it adds to bloat, complicates testing, and hits performance (more code to pull in, more branch misprediction). Apple take a stricter view. I think here linux/ubuntu is taking the Apple view: you get it wrong, you deal with it. While it will be dealt with, it is causing a lot of short term pain.

You only experience such problem if you use packages from outside the package archive. We maintainer try hard to keep all packages from the archive be compatible to each other. We have applied the workaround to the Ubuntu package.

This is a GTK bug, and should have a priority considerably higher than the present "low". (I do not know who can change priority, or where/how GTK bugs should be tracked.)

The GTK folk released an iteration of a shared library. The iteration was advertised as backwards compatible, but contained a change that broke compatibility with the Eclipse platform. A minor release (2.18?) should have no or minor effect on compatibility.

The GTK folk blew it. No doubt the change was well intentioned, and meant to be minor (as the release notes indicate) - but it turned out to have a large impact. (If you maintain shared libraries for any length of time, odds are good this will happen to you too, eventually.) The proper response is to remove the problem, which may also mean deferring the troublesome change to a major release.

The Eclipse folk are being helpful, and changing their code - but this only helps slowly and in future. For all the applications out there based on the Eclipse platform, the development and distribution practices are going to vary quite a lot. Not all are going to be based on the current version of Eclipse, and the cost to update those applications is not small.

The fact that Ubuntu package maintainer(s) are proactive in applying the Eclipse fix is great! ... but largely irrelevant. Not all the software in the world is going to be part of the package archive. (In my own case I have three - or more? - Eclipse-platform applications installed, none from the package archive, and all effected.)

The cost to fix this in GTK is small and coherent. The cost to "fix" this on the Eclipse side is going to be many times larger in time and trouble. In usual practice, a minor release of a widely-used shared library should not cause this sort of grief.

The GTK folk made a perfectly human goof - and need to deal with it.

you can argue upstream on that, gtk didn't strictly break compatibility, it's just some assumptions other people did which turned to be wrong in the new version, ie the matching between x11 and gtk windows used to work by luck if you want but it's not something softwares writer should rely on

I understand the upstream argument. (Been there, done that.) The GTK folk did not *intend* to break compatibility (at least in a theoretic sense), but did in fact break compatibility (in an actual sense). Their intent was to introduce useful new behaviors into a release meant to preserve old behaviors. Nothing wrong with that. But when it goes wrong, and you *break* applications for thousands of users, you fix it.

Pragmatism wins, or should. Sort of a variant on "the customer is always right" meme. Writing software is not a theoretic exercise. Practical considerations trump.

FWIW, I see this in other java applications. Specifically, it happens with CrashPlan (http://www.crashplan.com). Clicking buttons doesn't work until I press the space bar along with it.

The same seems to happen with flash on Ubuntu (Gnome) 64bit systems. See bug 410407.

The "workaround" GDK_NATIVE_WINDOWS=true does not work for me. I have been using eclipse for years without any issues. More then very annoying. So far I have wasted 5 hours simply trying to find out why my find and replace buttons don't work in Eclipse anymore.

Cos Costa's comment was correct (2009-10-19). This does completely damage the Ubuntu experience. I have been an Ubuntu user for years but since upgrading to 9.10 a month ago I have had no end of problems. I'm a web developer by profession. I use Eclipse each and every day. It now doesn't work. The "warkaround" doesn't work. I am over 5 hours behind a piece of development now because of this problem. I am very much more than annoyed at this latest 9.10 "issue". I will not repeat here the words that I am current shouting at my PC. Low priority bug, my a***e. I am even considering dumping the whole Ubuntu thing and switching back to Windows. No Joke.

Seeing as it seems to work for everyone else (me included), chances are that you are doing something wrong.

Could you quickly open a terminal and issue the command:

GDK_NATIVE_WINDOWS=1 eclipse

If you aren't using the Ubuntu-provided eclipse, substitute the path to the eclipse executable for "eclipse".

If it works that way, you definitely were doing something wrong before. If not, you have stumbled across a different bug and should report that separately.

@reini - be careful before you count "everyone else". For me, the environment variable hack made buttons work, but added occasional crashes in libpango (reported elsewhere). You can work around the flaky buttons with the keyboard (tedious). But you cannot work around Eclipse crashing and losing work and/or context.

FYI, if you are a web developer, and use Aptana (based on Eclipse), note the recent 2.0.4 update used an updated Eclipse platform, that has a workaround for the GTK bug(s).

Am Sonntag 14 März 2010 schrieben Sie:
> @reini - be careful before you count "everyone else". For me, the
> environment variable hack made buttons work, but added occasional
> crashes in libpango (reported elsewhere).

Yes, I also got the crashing - the buttons problem is fixed,
however... ;-)
I managed to decrease the frequency of the crashes by forbidding
libgtk version "2.18.3-1ubuntu2.1" and by removing the KDE bespin
style.

Is this still a problem? Since GTK+ already entered 3.0 era.

Not relevant to me anymore. I would suggest closing it

Le vendredi 12 avril 2013 à 08:06 +0000, Ma Xiaojun a écrit :

> Is this still a problem? Since GTK+ already entered 3.0 era.
>
> ** Changed in: gtk+2.0 (Ubuntu)
> Status: New => Incomplete
>