Created attachment 56028 [details] Screenshot of Emacs using the oxygen-gtk style Version: unspecified (using KDE 4.5.5) OS: Linux When using the oxygen-gtk style, menus and scroll bars are drawn completely wrong in the GTK version of Emacs. Please see the attached screenshot. Reproducible: Always Expected Results: Emacs should look like a native KDE program. If this is not possible for technical reasons, Emacs should at least work with ARGB disabled. Versions of relevant programs: - oxygen-gtk 1.0.1 - Emacs 23.2 - KDE 4.5.5
Emacs doesn't look like it has oxygen-gtk style applied. Does it print anything to terminal? If no, then does it work if you enable oxygen-gtk via gtk-chtheme or gtk2-theme-switch?
On startup, Emacs prints the following line twice: (emacs:5558): GLib-GObject-WARNING **: plugin 'oxygen-gtk' failed to register type 'OxygenStyle' Other GTK apps do not print such a warning.
I can't reproduce this problem. Did it work with oxygen 1.0.0?
No, Emacs looked the same with oxygen-gtk 1.0.0. Is there a way to get more verbose debug output from GTK without recompiling the application?
You'll have to install debug version of GTK (or compile it yourself if your distro doesn't provide one), i.e. using --enable-debug=yes for configure. Then you would use this: http://library.gnome.org/devel/gtk/unstable/gtk-running.html#GTK-Debug-Options
also, can you provide the content of your $HOME/.gtkrc* files ? And try with: ############################## # This file was written by KDE # You can edit it in the KDE control center, under "GTK Styles and Fonts" include "/usr/share/themes/oxygen-gtk/gtk-2.0/gtkrc" style "user-font" { font_name="Sans Serif" } widget_class "*" style "user-font" gtk-theme-name="oxygen-gtk" gtk-font-name="Sans Serif 8"
My .gtkrc-2.0-kde4 file looks exactly like yours. Ruslan, you said that you could not reproduce this problem. Do you mean that Emacs looks good with oxygen-gtk on your system? I will try to build debug versions of GLib and GTK, but this may take a few days.
Created attachment 56042 [details] emacs My emacs looks like this. Something I forgot to add: what's your version of gtk, gdk and cairo ? Versions I am using: GNU Emacs 23.1.1 GTK+ Version 2.20.0 I'll try see if I get the same with emacs 23.2
PS: how does your emacs look when you use a different gtk style (e.g. QtCurve) i have been able to reproduce your version with an *older* version of emacs (namely 22.3.2). But in this case it would not adopt any gtk style at all. That would make it an upstream (emacs) bug, not a Gtk one ... sorry.
Your Emacs looks great! Good to know that it _can_ work. My Emacs works with any other GTK style I have tried, which includes Clearlooks, Sonar, Gilouche, and Oxygen-Molecule. My package versions: - gtk2 2.20.2 (includes libgdk-x11) - cairo 1.8.10 - glib2 2.24.1
ok. So not an upstream bug :)
Btw., what does this GLib warning actually mean, "plugin 'oxygen-gtk' failed to register type 'OxygenStyle'"? Does it mean that 1. oxygen-gtk tried to register the type OxygenStyle, but this failed, or 2. oxygen-gtk should have registered this type, but it did not.
> failed to register type 'OxygenStyle'"? > > Does it mean that > 1. oxygen-gtk tried to register the type OxygenStyle, but this failed, or > 2. oxygen-gtk should have registered this type, but it did not. Probably means 1/ And thats probably what causes your problem. The reason why it fails to register the type is unknown to me, though ... especially since it does register well for other apps, and does register well for other styles. I'll try look for differences in the type registration with respect to e.g. QtCurve.
commit d9b00dcc687d720e8d17edf3c96d9dee3fab1262 branch 1.0 Author: Hugo Pereira Da Costa <hugo@oxygen-icons.org> Date: Sat Jan 15 12:26:44 2011 +0100 Try cleanup style registration: - uses NULL instead of 0L where needed - properly cast to expected type in GTypeInfo - removed typedef struct, since they are not needed in c++ - added check on passed pointer to ::merge method. CCBUG: 263182 diff --git a/src/oxygenrcstyle.cpp b/src/oxygenrcstyle.cpp index a8d4887..cb93941 100644 --- a/src/oxygenrcstyle.cpp +++ b/src/oxygenrcstyle.cpp @@ -32,14 +32,16 @@ #include <gtk/gtk.h> //______________________________________________________________________ -struct _OxygenRcStyle -{ GtkRcStyle parent; }; +struct OxygenRcStyle +{ + GtkRcStyle parent; +}; //______________________________________________________________________ -struct _OxygenRcStyleClass -{ GtkRcStyleClass parent; }; - -static GtkRcStyleClass *oxygen_rc_style_parent_class = 0L; +struct OxygenRcStyleClass +{ + GtkRcStyleClass parent; +}; //______________________________________________________________________ static GtkStyle* create_style( GtkRcStyle *rc_style ) @@ -74,8 +76,12 @@ static guint parse( } //______________________________________________________________________ +static GtkRcStyleClass *oxygen_rc_style_parent_class = 0L; static void merge( GtkRcStyle *dst, GtkRcStyle *src ) -{ oxygen_rc_style_parent_class->merge( dst, src ); } +{ + if( oxygen_rc_style_parent_class ) + { oxygen_rc_style_parent_class->merge( dst, src ); } +} //______________________________________________________________________ extern "C" void oxygen_rc_style_instance_init( OxygenRcStyle *self ) @@ -102,16 +108,16 @@ void oxygen_rc_style_register_type( GTypeModule *module ) { static const GTypeInfo info = { - sizeof(OxygenRcStyleClass ), - 0L, - 0L, + (guint16)sizeof(OxygenRcStyleClass ), + (GBaseInitFunc) NULL, + (GBaseFinalizeFunc) NULL, (GClassInitFunc) oxygen_rc_style_class_init, - 0L, /* class_finalize */ - 0L, /* class_data */ - sizeof( OxygenRcStyle ), - 0, /* n_preallocs */ + (GClassFinalizeFunc) NULL, + NULL, + (guint16)sizeof( OxygenRcStyle ), + 0, (GInstanceInitFunc) oxygen_rc_style_instance_init, - 0L + NULL }; oxygen_rc_style_type = g_type_module_register_type( module, GTK_TYPE_RC_STYLE, "OxygenRcStyle", &info, GTypeFlags(0 ) ); diff --git a/src/oxygenrcstyle.h b/src/oxygenrcstyle.h index 392bacd..33c5d0d 100644 --- a/src/oxygenrcstyle.h +++ b/src/oxygenrcstyle.h @@ -39,9 +39,6 @@ G_BEGIN_DECLS #define OXYGEN_IS_RC_STYLE_CLASS(klass) ( G_TYPE_CHECK_CLASS_TYPE(( klass ), OXYGEN_TYPE_RC_STYLE ) ) #define OXYGEN_RC_STYLE_GET_CLASS(obj) ( G_TYPE_INSTANCE_GET_CLASS(( obj ), OXYGEN_TYPE_RC_STYLE, OxygenRcStyleClass ) ) -typedef struct _OxygenRcStyle OxygenRcStyle; -typedef struct _OxygenRcStyleClass OxygenRcStyleClass; - void oxygen_rc_style_register_type( GTypeModule *module ); GType oxygen_rc_style_get_type( void ) G_GNUC_CONST; diff --git a/src/oxygenstylewrapper.cpp b/src/oxygenstylewrapper.cpp index 1b7dbca..9213d3c 100644 --- a/src/oxygenstylewrapper.cpp +++ b/src/oxygenstylewrapper.cpp @@ -43,11 +43,11 @@ #include <iostream> //_______________________________________________________________________________________________________________ -struct _OxygenStyle +struct OxygenStyle { GtkStyle parent; }; //_______________________________________________________________________________________________________________ -struct _OxygenStyleClass +struct OxygenStyleClass { GtkStyleClass parent; }; //_______________________________________________________________________________________________________________ @@ -2683,16 +2683,16 @@ void oxygen_style_register_type( GTypeModule* module ) static const GTypeInfo info = { - sizeof( OxygenStyleClass ), - 0L, - 0L, + (guint16)sizeof( OxygenStyleClass ), + (GBaseInitFunc) NULL, + (GBaseFinalizeFunc) NULL, (GClassInitFunc) oxygen_style_class_init, - 0L, /* class_finalize */ - 0L, /* class_data */ - sizeof( OxygenStyle ), - 0, /* n_preallocs */ + (GClassFinalizeFunc) NULL, + NULL, + (guint16)sizeof( OxygenStyle ), + 0, (GInstanceInitFunc) oxygen_style_instance_init, - 0L + NULL }; oxygen_style_type = g_type_module_register_type( module, GTK_TYPE_STYLE, "OxygenStyle", &info, GTypeFlags(0 ) ); diff --git a/src/oxygenstylewrapper.h b/src/oxygenstylewrapper.h index 901d3ed..93f5515 100644 --- a/src/oxygenstylewrapper.h +++ b/src/oxygenstylewrapper.h @@ -39,9 +39,6 @@ G_BEGIN_DECLS #define OXYGEN_IS_STYLE_CLASS(klass) ( G_TYPE_CHECK_CLASS_TYPE(( klass ), OXYGEN_TYPE_STYLE ) ) #define OXYGEN_STYLE_GET_CLASS(obj) ( G_TYPE_INSTANCE_GET_CLASS(( obj ), OXYGEN_TYPE_STYLE, OxygenStyleClass ) ) -typedef struct _OxygenStyle OxygenStyle; -typedef struct _OxygenStyleClass OxygenStyleClass; - void oxygen_style_register_type( GTypeModule *module ); GType oxygen_style_get_type( void ) G_GNUC_CONST;
If I am not missing something, the only real change that the previous patch does is to prevent dereferencing a null pointer when 'oxygen_rc_style_parent_class' is 0. 'NULL' expands to '0', and the casts in initializations are done implicitly anyway.
you're not misunderstanding. This is just clean-up. Won't fix anything.
In fact I'm stil unsure whether this is a problem with our code, or just if the library (.so) is just not loaded at startup on your side. I'm currently adding more debug info and will ask you to test when ready.
ok. So I just pushed (to both master and 1.0 branches), another number of cleanup commits. I also added some debugging information. What I would like you to try is: 1/ get the sources from git (either branch). See http://kde-look.org/content/show.php/Oxygen+Gtk?content=136216 for instructions. 2/ compile in DEBUG mode (change the value of OXYGEN_DEBUG to 1, in CMakeLists.txt). See INSTALL on how to compile and install. Notably, pay attention to the 64bits part if you have a 64 bit machine (do you ?) 3/ run emacs and report what's the output. Notably, look for these two lines at the beginning of the running: Oxygen::RCStyle::registerType Oxygen::StyleWrapper::registerType If they don't appear it means that the oxygenstyle is probably not even attended to get loaded, which means its a gtkrc issue, not something wrong with our code.
Thank you, Hugo, I will try it. Btw., I have built a debug-enabled GLib, but was not able to get any debug messages from it. At http://library.gnome.org/devel/glib/unstable/glib-running.html, it is stated that if GLib has been configured with "--enable-debug=yes" (which I did), the variable G_DEBUG "[...] can be set to a list of debug options, which cause GLib to print out different types of debugging information." But none of the listed options causes GLib to print anything. Moreover, the description of each option states that "this option is special in that it doesn't require GLib to be configured with debugging support." Am I supposed to understand this? Compiling a debug-enabled GTK is not possible for me at the moment because, surprisingly, the source RPMs provided by my distro (openSUSE 11.3) differ from the sources from which the binary packages on my system have been built. In other words: they don't compile. This means I would probably have to recompile the whole GTK stack. Maybe I can try this later in a VM.
Hey Hugo, the current git master version works with my Emacs. The menus even have properly rounded corners (I assumed that this would require ARGB support, which is disabled for Emacs?). Now Emacs looks even better than Firefox ;-) Thank you very much! It's a bit strange, though, that your Emacs already looked ok before your latest changes. Perhaps you had already fixed the problem in your branch after the 1.0.1 release.
> The menus even > have properly rounded corners (I assumed that this would require ARGB support, > which is disabled for Emacs?). ARGB support is used for smooth (antialiased) rounded corners. If it's not available, corners are rounded via XShape extension.
@Holger Honestly I'm not sure what fixed it. I just downloaded the oxygen-gtk-1.0.1 tarball and still can't reproduce the problem. Do you have a 64 bits machine ? If yes, there is a chance that your previous installation was messed up by that. Or that you actually need oxygen to be installed twice for 64bits and for applications that run in 32bits compatible mode. Thats the only explanation I have ... Anyway, closing the bug report then. Glad you like the style :)
No, I don't have a 64 machine. Maybe something was wrong with my installation. I had used the RPM provided at http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_11.3_KDE_Release_45/. The only difference I see to how I built the package is that the RPM version has been configured with "-DCMAKE_SKIP_RPATH=ON" and "-DCMAKE_BUILD_TYPE=release" (see the .spec file at https://build.opensuse.org/package/view_file?file=oxygen-gtk.spec&package=oxygen-gtk&project=KDE%3AExtra&srcmd5=14e3dd567d54d8a8c0399bd7deebeda0). Not setting an rpath should not cause problems. And it's a bit strange that only Emacs was affected.
well. Its a mystery then :) maybe indeed that was a packaging issue. Not sure. At least it forced me to clean-up all this style registration stuff (its been a long time since I was unhappy with it).
As Hugo suggested, the update to the new version wasn't what caused it to work. On another system, oxygen-gtk still doesn't work with emacs. Is there a way to trace what causes the "failed to register type 'OxygenStyle'" messages? Even if some bad behavior of Emacs causes this problem, there must also be a reason why Emacs has no problem with other GTK styles. What does oxygen-gtk do differently than the other engines?
Oxygen is written in C++ (while most other engines are written in C), and some apps link to their own versions of libstdc++.so, which is not the one against which oxygen-gtk is compiled. Maybe emacs is among them.
Emacs is not a C++ program; some other library must be the cause.
@holger yes it can be any library, and we have no way to find out which one (especially, not on *your* system, since again, there is no problem on *my* system). It can even be the gtk libs themselves (some symbols are defined in some gtk version, and not in older ones, and who knows ? maybe you're emacs is forcing the use of an older gtk version). Can be glib. gdk. Cairo. X11. Whatever. No clue, really. I would not even know how to figure it out if this was the case on my system, to be honest. I'd just give up on emacs ... I guess.
@Hugo Thanks for your answer. I have to admit that I still don't fully understand what is going on here. In what way can Emacs be "forcing" a certain library version, except by being linked against it (which I could check using ldd)? In a related bug report, you speculated that Emacs might be preloading some library. How could Emacs do this? The Emacs build uses only system libraries. If my Emacs was linked against a wrong library version, shouldn't this also cause other problems, independently of the GTK style? On an old system, the problem was gone after I compiled oxygen-gtk from git, instead of using a packaged version. My only guess is that to build oxygen-gtk, I had installed some package containing a library that oxygen-gtk depends on. If this is true, the problem would be caused by a *missing* library. Is this possible? But there *must* be some way to trace this. Btw., my system is not *that* exotic: install openSUSE 11.4 KDE (from the live CD) + Emacs, and you will have the same problem. (Giving up on Emacs? Hey, this is my operating system!)
@Harold, well again, if oxygen-gtk loads just fine with other gtk applications than emacs, it means it misses nothing on your system. So there has to be a problem/conflict between the libraries that emacs loads and the ones that oxygen-gtk needs, that is specific to emacs (and to what oxygen-gtk needs). Correct ? Also, since on my Mandriva 2010.2 I do not have the problem, this must be something distribution specific. You could try build emacs from sources on your system and see if the problem persists ... other than that, since I will not change distro, there is really nothing more I can do about it.
> My only guess is that to build > oxygen-gtk, I had installed some package containing a library that oxygen-gtk > depends on. Then try installing the libs you have installed on old system, one by one, checking which one would make emacs behave correctly.
You could also try post links of pastebins of the output of: ldd /usr/bin/emacs ldd /usr/lib/gtk-2.0/2.10.0/engines/liboxygen-gtk.so For comparison.
I have already checked the output of ldd on emacs vs. oxygen-gtk. Both seem to be linked against the same library versions. I still have to check whether these libraries are all available on my system (but if not, loading of Emacs should fail with a linker error, no?). In the RPM .spec file, I have seen that my Emacs has been compiled with GCC 4.3, while the rest of the system has been compiled with GCC 4.5. Could this be a possible cause of the problem? I will try to compile Emacs using GCC 4.5.
A locally compiled Emacs doesn't work with oxygen-gtk either. So the GCC version was not a problem. I also doubt that there is a library mismatch related to Emacs because the Emacs build simply does not use any internal libraries. The problem must have a different cause.
Got this bug on Arch x64 with oxygen-gtk 1.0.3 and Emacs 23.3. Maybe i can help to trace it?
@Holger Do you also have 64bit machine? I suspect this may be because of difference of C++(oxygen-gtk) and C(GTK+) binary code in 64 bit mode (and not always reappearing for different compiler versions).
@Ruslan No, this is a 32bit machine.
Question to all people having the issue. What is the "about emacs" window giving you ? Mine says: "GNU Emacs 23.1.1 (i386-mandrake-linux-gnu, GTK+ Version 2.20.0)" Which is weird, since I am using (and am sure about that) a manually compiled gtk+-2.24.3. This to me points to the fact that emacs is somehow using its own version of gtk, which may or may not be compatible with the one you compiled oxygen-gtk against, and may, or may not, cause problems.
*** Bug 268457 has been marked as a duplicate of this bug. ***
@Hugo I'd rather consider this message indicating version of GTK against which emacs was compiled, not the one it uses.
Possibly, you guys could also use "strace /usr/bin/emacs >& log", pastebin the result and post the link here. in the output of strace, look of oxygen-gtk (notably liboxygen-gtk) and which places the guy is looked after. Might give some clue of what's happening.
@Hugo, i think i know what must be the reason. See this: http://library.gnome.org/devel/gobject/stable/gobject-Type-Information.html#GTypeInfo GTypeInfo has some guint16 members which are likely padded in our oxygen compilation differently from emacs compilation. Of course, this will depend on compiler version. So, we have to determine how it should be padded on compile time (and figure out how to force it). Another way would be to move this to separate *.c file and compile as C source.
I'd like to have a clearer indication that this is the issue indeed before making any change. This *is* a wild guess and nothing more atm. we declare the relevant methods as extern "c" already and that should cover it. Besides all gtk apps are "c" apps, and compiled as such (gimp, nautilus, etc.), and oxygen-gtk registers just fine there. So this still would not explain why emacs would have a different behavior. I'd really hate to have to put some C code in oxygen-gtk, especially just for *one* app, that is working on some distros/configs and not on some others.
Those who are affected by the bug, please try using -m8-bit, -m16-bit, -m32-bit options for g++ (in src/CMakeLists.txt in CMAKE_CXX_FLAGS) when compiling oxygen-gtk, and let us know if any of them helps.
Created attachment 58140 [details] log of strace emacs (a bit bulky)
(In reply to comment #41) > Possibly, you guys could also use "strace /usr/bin/emacs >& log", pastebin the > result and post the link here. > > in the output of strace, look of oxygen-gtk (notably liboxygen-gtk) and which > places the guy is looked after. Might give some clue of what's happening. I attached a strace-log. (There are a lot of "no such file of directory" messages in the log, but, as this is also the case with other applications where oxygen is properly working, I'm in doubt that this is the reason.) Furthermore, I will try to use those c++ options, mentioned in comment #44.
(In reply to comment #38) > This to me points to the fact that emacs is somehow using its own version of > gtk, which may or may not be compatible with the one you compiled oxygen-gtk > against, and may, or may not, cause problems. No, at least on openSUSE, Emacs is compiled against the system GTK (and I'm pretty sure that the same holds for other distros).
(In reply to comment #42) > GTypeInfo has some guint16 members which are likely padded in our oxygen > compilation differently from emacs compilation. If there was a problem with inconsistent alignment, then either oxygen-gtk should not work with other GTK apps (wrong alignment in oxygen-gtk) or emacs should not work with other GTK styles (wrong alignment in emacs). Further, an alignment problem would likely crash the app as a result of calling invalid function pointers. But none of this happens. Nevertheless, I will also try the different alignment settings.
(In reply to comment #44) > Those who are affected by the bug, please try using -m8-bit, -m16-bit, -m32-bit > options for g++ (in src/CMakeLists.txt in CMAKE_CXX_FLAGS) when compiling > oxygen-gtk, and let us know if any of them helps. According to the GCC documentation, these options are specific to the CRIS architecture, which we probably don't have. On x86, there are '-m32' and '-m64'. Structure alignment is specified with '-fpack-struct[=n]' (and probably some other options).
Ah, you're right. My bad. But of course, i meant just this: -fpack-struct. Though, i'm no longer sure it could help. The only thing left is tracing through g_type_module_register_type(), looking where it fails, which might give us some idea of what's going on.
My about emacs: "GNU Emacs 23.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.1)" And 2.22.1 is system version which is used by other applications. I just noticed that gtk-chtheme also fails to register oxygen-gtk with the same message. GIMP registers it successfully.
Ok, I have found out what's going wrong: the use count of the module becomes 0. When GTK first accesses the "oxygen-gtk" module by calling g_type_module_use(), the module is loaded and the types "OxygenRcStyle" and "OxygenStype" are correctly registered. Then g_type_module_use() and g_type_module_unuse() are called several times until the use count of the module becomes 0. When g_type_module_use() is called with use count 0, the load function of the module is called again, which returns the still loaded module (modules are never unloaded). However, the "loaded" field in the ModuleTypeInfo of both types is FALSE, which causes the function to fail. With (my) Emacs, there seems to be a use count mismatch of at most 1. An easy workaround is to call g_type_module_use() once, immediately after registering the type in StyleWrapper::registerType(), which guarantees that the types remain accessible. Since the engine must be loaded for the whole lifetime of the program anyway (and modules are never unloaded), this shouldn't be a problem. As I don't know the rules for GTK engines, I don't know who's to blame for this problem, oxygen-gtk or Emacs. Since the calls to g_type_module_use() and g_type_module_unuse() are coming from GTK, however, I would assume that this is a bug in Emacs's GTK interface. Actually, I find it a bit strange that Emacs works with other GTK engines. For example, I have quickly compared the type initialization code of oxygen-gtk and murrine (which works perfectly with Emacs), and I haven't found any real difference (except that murrine uses macros provided by GLib/GObject to set-up the types). In particular, murrine does not explicitly increases the use count. This suggests that there is a subtle difference in the initialization order of the two engines. Perhaps some GTK guru can explain this?
Created attachment 58237 [details] Workaround for Emacs problem Increment the use count of the type module after registration
(Above patch applies to the current master branch.)
Well, we'll have to reduce oxygen-gtk code to minimum which triggers the problem (stripped oxygentheme.cpp and oxygenstylewrapper.cpp), and then, if we still don't figure out why the problem appears, we should send a bug report with this test case to GTK. In fact, the best approach might be to incrementally change (after stripping both) oxygen-gtk or murrine so that their code gets more alike, and see what leads to the problem. I still think it might be our bug.
mmm. This does not explain why - emacs did somehow work in your previous install - emacs works just fine here Now looking into QtCurve, (I did not check murrine) The difference I can see (see qtcurve.c, qtcurve_rc_style_register_type/qtcurve_style_register_type): the types are re-registered at every call to theme_init (from gtk), where as for us, we only register on first call (due to the check on "if( !_type )" Maybe that explains it. I'll send an alternative patch. Holger: would you be kind to test it ?
Created attachment 58243 [details] alternative patch to hopefully fix the emacs loading of oxygen-gtk
... and I renamed the bug report to smthing more appropriate :)
(In reply to comment #56) > I'll send an alternative patch. Holger: would you be kind to test it ? Yes, this patch works. Thanks! Your patch is also the right way to do it -- if GTK requests oxygen-gtk to initialize again, it should do so. I don't know why Emacs causes GTK to call theme_init() twice; other GTK apps call it only once. It may have something to do with Emacs not being a "real" GTK app. > mmm. This does not explain why > - emacs did somehow work in your previous install > - emacs works just fine here I can only speculate that different Emacs sub-versions behave differently (mine is 23.2.1). Distribution-specific patches to Emacs or GTK are also a possible cause. That I got it working on my old system might have been a side-effect of installing an Emacs or GTK update.
Git commit b0e33d143c68a1737c8f283c457aea898a4c6766 by Hugo Pereira Da Costa. Committed on 22/03/2011 at 12:23. Pushed by hpereiradacosta into branch '1.0'. Removed check on _type value when registering new type in StyleWrapper::registerType and RCStyle::registerType CCBUG: 263182 M +19 -22 src/oxygenrcstyle.cpp M +20 -22 src/oxygenstylewrapper.cpp http://commits.kde.org/oxygen-gtk/b0e33d143c68a1737c8f283c457aea898a4c6766
ok. Pushed to 1.0 and master. Closing the bug report. Thanks (a lot) for the careful debugging.