Image 01


Hugo Pereira Da Costa

QtCurve 546 comments

Score 81.0%
Jan 08 2013
Well, sorry to hear about the frustration.

Oxygen-transparent is definitely experimental and targets somewhat experimented users.

One of the reasons is notably that the code in question is not 100% robust, and that encountered problems might frustrate un-experienced user even more than the frustration they got while trying to install.

Some day, there will be properly released oxygen-transparent code, that linux distributions should be able to ship, and that would make your life easier.

This requires some serious issues to be fixed first. In the meanwhile, sorry, there is not much I can do to ease your frustration.

(note however, that everything you learned while going through the tutorials is not wasted, and you are less an unexperienced user today, than you were before trying to compile and use oxygen-transparent). - Dec 15 2011
for smplayer, you might need to re-update your "exceptions" (in oxygen-transparent-settings" - background opacity - exceptions button)

for filing bug reports:
select Oxygen as a product; widget style as component, and be sure to mention oxygen-transparent in the bug title.

Thanks ! - Dec 13 2011
no uninstall;
it will safely overwrite. - Dec 12 2011
ok. Done, I think. Please double check. - Dec 12 2011
Will do.
Requires some time though, since I need to modify the code so that user-set exceptions do not overwrite "hard-coded" exceptions. Will give it a shot and keep you posted.
Thanks for pointing this out ! - Dec 12 2011
PS: since this has occurred with quite a number of people already I'll probably commit an #ifdef to check on kde version in the near future. - Nov 28 2011
It is because your kde (more explicitely kdelibs) version is too "old" for oxygen-transparent.
Just comment out the guilty line in the oxygen code, namely:


and everything should be fine.

Hugo - Nov 28 2011
Transparent style should work (provided that you also selected oxygen-transparent for "application appearance") for newly started applications, or after re-login. Does it ? - Oct 21 2011
use oxygen-transparent-settings
(in order not overwrite the official one) - Oct 19 2011
you're missing a perl module, necessary for the setup script to run (and not for oxygen-transparent itself).
Most likely something like: perl-getopt
(see the "use Getopt::Long" line at the beginning of the script) - Oct 13 2011
Indeed this is a KDE/Qt widget theme (and window decoration). It will work only for KDE and Qt applications, not for gtk-based applications (such as libreoffice, firefox, nautilus, etc.)

There is an oxygen-gtk version of the oxygen widget style that works for gtk-based applications, but this one does not (yet) support transparency.

Besides, supporting transparency for gtk is quite a pain, because many (many) gtk apps crash in the process (we tried).

- Oct 07 2011
Just tried.
Yes transparency works with compiz.
For blur, does not seem to work, but I'm not sure my graphics card supports it (for compiz).
I guess you'd have to give it a shot ...
(I have no clue how compiz implements blur behind windows).
- Oct 07 2011
well, the commit you reverted was the one attempting to fix the issue reported by Jamel
(it actually did fix the issue on my laptop, without introducing regression). So I doubt that your patch version does fix it (right ?)

Now, I would encourage two things:

1/ Jamel and Homer: could you also try with bespin widget style (enabling translucency) and tell me if you have similar issues, and which ones. (with Homer's patched version, bespin and oxygen should have similar code and behave essentially the same).

2/ this issue should best be reported on (select oxygen as a product, widget style as a component, and mention oxygen-transparent in the title). This would make everybody's life easier to keep track of this bug, and result in having more feedback. My impression is that some fix for some configuraiton breaks other configurations and one can't make everybody's happy.

Also Homer: is your issue the same as Jamel, or different ?


Hugo - Oct 04 2011
you need to install git (get the relevant packages from your distribution).

You will likely need other packages, such as cmake, kde-workspace-devel, etc.
- Oct 01 2011
Can you double check that you are actually using oxygen-transparent (and not oxygen) also for the window decoration style ? - Sep 21 2011
Fixed now. One bad commit of mine. Sorry for the trouble. - Sep 20 2011
ok. I just tried to commit a fix to the issue.
at least it seems to work here. Please give it a shot (by fetching and compiling the latest git version) and report back.


Hugo - Sep 13 2011
I can reproduce the issue (with latest git also).
It is an issue "related" to what Homer mentioned, but slightly different ... and even harder to fix.
Will investigate more. - Sep 13 2011
soon soon. Will do.
Its mostly a manpower issue.
(keeping the code in sync with oxygen is already quite painful. Releasing is extra burden. Sorry).
- Sep 13 2011
Opera is not using Qt (as far as I know), but GTk. So no transparency there, until it is supported in Gtk. Besides, even then, I'm pretty sure it would still not work with Opera, since it only uses gtk as a wrapper and is not a "native" gtk application.

Same will be true for open/libreoffice, firefox, thunderbird, and some others.

Sorry. - Jul 25 2011
You are apparently missing qmake. It is included in some Qt4 devel package, provided by your distribution. You might then also miss other packages. See the text in the package description (above) for an indicative list of required packages.

Keep me posted,

Hugo - May 27 2011
Just looked at kwin bug report and mesa bug report, and I must say all threads are quite funny.

I guess it comes with using only bleeding-edge stuff. (nouveau from git, kwin, and oxygen-transparent).

I've much respect to that, and you taking the time to carefully report the issues you have to all interested parties.

I hope you're having fun :) - May 11 2011
Some of the black listed applications were done so because of direct conflict:
for most of them, video playing is broken.
This might actually have been fixed since then, so feel free to give it a new shot.

- May 10 2011
Non Qt applications use a different style (most of them gtk).

Oxygen-gtk does not support transparency yet, so no.

QtCurve does, I think, but does not have the same appearance.

Finally some apps will still not have it
(e.g. firefox, thunderbird, ooffice), because they use their own code, and gtk (or Qt) as a wrapper, not allowing transparency to be used at all. - May 10 2011
I think KDE 4.4 is unfortunately too old for recent oxygen-transparent, because of keeping it in sync with oxygen (from KDE trunk).

It should work with kde4.5 though. (last time I checked).

I guess I should update the description accordingly.

Sorry - May 09 2011
after setting a non opaque transparency, only newly started applications will be affected (I think). You might also need to restart kwin (or simply logout/login).

This assuming that you have selected oxygen-transparent for both the widget style and the window decoration.

You also need to have desktop effects enabled.

Other than the above, no clue :( - May 04 2011
I actually forgot to push the change to the repository. Its fixed now.
Next time you update (re-run the script, install, and then logout/login), the png's should be gone. - May 03 2011
Thanks for notifying ! - May 02 2011
argh sorry about that.
Will fix asap (like: now) - May 02 2011
yeah. Bogus driver was my best guess also based on what you describe.
Well ... no transparency for you it seems. Sorry. - Apr 27 2011
I'd need a crash report and/or back trace to investigate, since I can't reproduce here.

And some more precise diagnostic.
You mean plasma crashes when you resize any normal (non plasma) window ?

If yes that's weird cause they are two completly unrelated processes.

(normal window is kwin, and plasma is well plasma).

Does it happen if you use a different widget style ?

a different window decoration style ?
- Apr 25 2011
In fact, the window icon issue, is due to some code I commented for testing and forgot to de-comment. I'll re-implement. The positioning I'm still working on it.

Will keep you posted about when everything is committed. - Apr 21 2011
I 'think' this issue is related to windows also showing up at (0,0) reported on the page before.

What happens is intrinsically an issue in Qt. Whenever transparency is set on an application window, Qt creates a second window (with transparency), to which the first one is copied later on.

Problem is: it places such window in 0,0 and has icon uninitialized.

Now: there is some code in oxygen to copy the icon and move the window to its previous correct position, but the problem is: this code is sometime executed too late, and not caught by kwin. Hence both issues. Note that this does not *always* happen. Its basically a race condition between kwin and oxygen.

I intend to dig more into how to try workaround these issues, but haven't have the time yet (and besides, due to the above race condition, I can't actually reproduce the problem ...)

- Apr 21 2011
Oxygen Gtk

QtCurve 340 comments

Score 80.8%
Oct 23 2014
yes :) - Nov 23 2011
ok. error: ‘GDK_KEY_Q’ was not declared in this scope
is the bad guy.
Likely I have a header missing ...
In the meanwhile you might just comment out the compilation of the "demo" application (where the crash occurs).

Just comment
'add_subdirectory( demo )'
in CMakeLists.txt
- Nov 23 2011
the full output of the "make" command.
what's on your screen, that is. - Nov 23 2011
ok. Fixed now, I think.
You'd need to get the sources from git
(either 1.1 or master branches). See above.
- Nov 19 2011
that was easy. Gtk version 2.24
- Nov 19 2011
mmm. Likely due to too "old" version of gtk.
You'd have to stick to the earlier version of oxygen-gtk untill I figure to which version of gtk the missing function was added and include the relevant #ifdef.
- Nov 19 2011

That's what happens when running bleeding edge.
Its a cairo bug.
Either downgrade or try the patch.
Note: I'm actually interested in feedback/confirmation that the patch does work.
(though I won't commit it, cause cairo should be fixed, rather) - Nov 12 2011
What is your gtk version ?
So far I can't reproduce the problem (which suspiciously sound like a gtk bug).

Mine is: 2.24.5

Thx - Sep 19 2011
This screenshot is from unity. Right ?
If yes, I don't think we (as a gtk style) can change the top panel background color. I think the later is painted with its own methods, with no call to the gtk theme primitives. (although I could be proven wrong). Maybe Ruslan can comment.


Hugo - Sep 09 2011
Ralph's perfectly correct.
Problem is already reported in kde bugs. Its likely a combination of some Graphics driver + Firefox that causes the issues. It arrises only with new KWin's shadow system in combination with recent oxygen-gtk, that is the only Gtk style to support this new shadow system.

(which is why older gtk style, or other styles don't show shadows for any gtk apps).

Code is correct, as far as I know (notably since it is working just fine with other gtk apps, and also working fine with firefox on some systemes - notably: mine ).

I have no real clue how to fix, and would suggest people to report it upstream to graphics drivers/X

- Aug 08 2011
Well. Old kwin shadows is gone for good (it was buggy, non-optimized and unmaintained).

We could/should add fallback shadows to kwin in case it is not provided by the widget style, but due to lack of manpower it is unfortunately low priority. I guess a bug report or wish send to KWin @ can't hurt, though :) - Aug 01 2011
yes. I guess you're original libreoffice uses the "Qt" interface, which is even more broken than the gtk one. (and uses Oxyge-Qt and not oxygen-gtk).

libreoffice-gnome on the other hand uses the gtk interface, and therefore oxygen-gtk which should be less broken and (indeed) have the shadow back. It is the recommanded usage of libre-office (until libreoffice get rewritten to use Qt / or gtk, as a native toolkit, in place of the two ugly and incomplete wrappers it is using now)

Anyway, thanks for the feedback, and I'm glad I could help.

- Aug 01 2011
also, what's the gtk version you are using ? - Jun 29 2011
... weird. Never heard of such an issue.
Could you try downgrade to oxygen-gtk-1.0.5 and see whether the problem persists or disappear ? its easy to ensure that oxygen-gtk 1.0.x is used: the sliders are rendered differently.

If the problem does disappear, then you'd want to use git bisect to try identify the guilty commit.

You can contact me on IRC (#oxygen, ask for hugo), if you need help with git bisect.

Sorry for the trouble,

Hugo - Jun 28 2011
ok. The offending lines from gtkrc have been removed.
- Jun 28 2011
I've been unable to test gimp 2.7 yet (which I heard have had a major re-design).

Concerning the first crash, and the solution, I guess I'll remove the guilty gtkrc lines permanently. (this was gimp's design choice to use smaller fonts in tool panels, and the rc code was provided by them and intended to fix that. Probably is deprecated now ...)

For the second issue: seems to me that new widgets have been introduced. The "orange" I believe is the same as for "progress bars", which is actually what's intended here. (in kde land, krita has similar custom "editable progressbar" widgets).

Not much we can do about it ...
- Jun 28 2011
Smooth Tasks

Plasma 4 Widgets 842 comments

by panzi
Score 86.9%
Nov 05 2010
Hello, with the new shadow system introduced in kde for KDE4.7, the smoothtask tooltips get a new shadow (installed by the widget style) on top of the plasma one, when using oxygen as a style, and it does not look good.

See screenshot at:

To "fix" this, simply add:

setProperty( "_KDE_NET_WM_SKIP_SHADOW", true );

in TooltipWidget's constructor.
(... I know: there is no documentation for this)


Hugo - Oct 16 2011
Score 67.0%
Nov 14 2009