Image 01
profile-image

HugoPereira

Hugo Pereira Da Costa
QtCurve
test
oxygen-transparent

QtCurve 546 comments

Score 81.0%
Jan 08 2013
I agree this looks quite related.
That would explain why some apps crash and some not. Why would it be triggered more often by oxygen-transparent I have no idea though. - Feb 01 2011
Thanks for the support !
Unfortunately, this will not become the default for oxygen, for several reasons:
1/ for designs reasons
2/ because anyway, kwin's blur (which is needed for this style to be truely usable) is not optimized enough yet
3/ and because having to blacklist applications is not acceptable for a default kde style ...

Quite on the contrary, I plan to make it a "separate" style, and deco, named "oxygen-transparent", that would share the same config as oxygen (except for the transparency of course), and which I will keep in sync (that's easy: they share 90% of the code).

This way, distributions should be able to package the style and the deco, and users wont have to compile (at their own risk) and overwrite oxygen's defaults.

I think that's an acceptable compromise.

As for porting to oxygen-gtk, yes we plan to do so, but this is somewhat faraway along the list of things to do.
Besides, many, many, applications would need to be blacklisted too because of impossible argb support.

I hope you are not too disappointed ;) - Feb 01 2011
Can't reproduce.
It seems the compiler does not understand some symbols that are supposed to be declared in some Qt headers ...

Which Qt version do you have installed ?
- Jan 20 2011
For the record: mscore's now fixed, for both oxygen and oxygen-transparent. - Jan 03 2011
Just checked mscore. Indeed window dragging interferes badly with the application. This is a serious bug, present fir both oxygen and oxygen-transparent.

I'd prefer fix (since it might also interfere with other applications) rather than enabling window-drag blacklisting.
- Jan 03 2011
No. Should not be the issue. If you've been able to compile and install, then it means you have the proper dev files.

Now for the first comment:
1/ uninstall, unfortunately you can't.

You can re-install kdebase and kdelibs (version 4.4) and that *should* erase your compiled code (but its not easy to force reinstall of packages)

You can try compile and install the native oxygen from sources (though I'm not sure it would work since the script is very similar to the one from oxygen-transparent.

You can get the script at:
http://hugo-kde.blogspot.com/2010/09/performance-issues-one-script-and-call.html, and run it with option --branch 4.5
(the script will not work with the 4.4 version, but the resulting code *should* work with kde4.4)

2/ repair: can't really say what went wrong with your install. It does work here, and does work (apparently) for many other people.
The only suspicion I have is some mismatch in the various installation area so that you get a mixture of libs/plugins from native kde4.4 oxygen and oxygen-transparent.

Did you re-compile oxygen-transparent *after* your latest update of kde/kwin and otheres ?

What I'm confused about is that
1/ your kwin would not crash
2/ the issues you seem to mention are related to the oxygen *style* (not the window decoration), which in turn, is completely independent from the window manager (kwin or compiz).

Is there any chance that you get a backtrace of the crashing applications when using kwin ?

Finally, after installing oxygen-transparent, could you double check the presence (and timestamp) of the following files:

-- Up-to-date: /usr/lib/liboxygenstyle.so.4.5.0
-- Up-to-date: /usr/lib/liboxygenstyle.so.4
-- Up-to-date: /usr/lib/liboxygenstyle.so
-- Up-to-date: /usr/lib/kde4/kwin3_oxygen.so
-- Up-to-date: /usr/share/apps/kwin/oxygenclient.desktop
-- Up-to-date: /usr/lib/kde4/kwin_oxygen_config.so
-- Up-to-date: /usr/lib/kde4/plugins/styles/oxygen.so
-- Up-to-date: /usr/share/apps/kstyle/themes/oxygen.themerc
-- Up-to-date: /usr/lib/kde4/kstyle_oxygen_config.so


Keep me posted. And sorry for the trouble (as I said in the preample above: "experimental"). - Dec 29 2010
Nothing in the crash-report connects to oxygen.
Does it also occurs with other styles ?
I would suspect an issue with Qt or with drivers.

Can't reproduce here. (with kde4.5 and Qt 4.7.1) - Dec 29 2010
Svn not found: means that well ... you need to install a svn package (kubuntu must provide one, but I don't know its name since I don't use kubuntu).

You'll probably need a number of other packages installed (which are not by default). Look at the section "Needed packages for installation/compilation"

(it mentions 'subversion', which is 'svn', in fact).

Then try again (when all is installed)
good luck! - Dec 10 2010
PS:
one thing I will add, based on your experience, is to gray-out the "opacity" options in oxygen-transparent configuration dialogs, when desktop effects are disabled, to make it clear that they can't be used.

Stay tuned. - Dec 08 2010
Hello,
Normally, with desktop effects (compositing) disabled, oxygen-transparent "should" behave just like the non transparent, so that you "should not" need to revert. Is it not the case ? What exactly is not working ?

If you see differences (with respect to latest non-transparent oxygen version), this is a bug and should be fixed (by me). As far as I could test here, I see no difference between oxygen and oxygen-transparent, when I disable desktop effects.

Reverting would be quite a pain, I must say: you would need to remove and re-install the package(s) (rpm or deb) that contain oxygen, to re-overwrite the compile code, but because of the many dependencies between packages, that might be quite painful (and dangerous).

Alternatively you could get and compile the latest non-transparent oxygen sources.

There is a script to do that (similar to the "oxygen-transparent" script), described at:

http://hugo-kde.blogspot.com/2010/09/performance-issues-one-script-and-call.html - Dec 08 2010
You're correct with vlc. As for your question, to be honest, I'm not 100% sure, (except from the fact that it cannot be fixed inside the style and requires some changes either in the application or in the xembed mechanism that is used to embed video in widgets).

My understanding is that you must carefully watch which colormap is passed to which widget/window. If you use the default one provided by the app or the framework (and which is RGBA when using oxygen-transparent) to an XWindow that does not support it, you end up with either a crash or a black display. - Nov 23 2010
which version of kde are you using ? - Nov 12 2010
unfortunately there is not much I can do about it :(
There is a problem with embedding video in any application, and dolphin is one.
kaffeine is another (and is therefore blacklisted). You would have to blacklist dolpĥin also to give up on transparency for it, and get back the video preview.

Blacklisting can be achieved by typing 'oxygen-settings' in konsole or krunner; clicking on 'Exceptions' in the first page, and manually adding 'dolphin' as a new entry.

- Nov 12 2010
mmm. What did you change between the moment where it was working and the moment where it was not ?

I have not committed any code change since quite some time now, namely september 12, and this commit actually had nothing to do with transparency. Last transparency related commit dates July 28)

Besides it does work here.

I suspect problem with driver, or kwin (which primarily handles the blur effect)

What is your
- graphics card
- kde version
- qt version

Finally; if you have a chance to test with e.g either QtCurve or BeSpin, that might help deciding whether it is oxygen's fault or upstream.

Cheers

- Nov 09 2010
Can reproduce and will fix. Right now I'm busy merging the transparency with latest oxygen from trunk (which I have been pretty much entirely rewritten after kde4.5, for optimization and in the hope of making a standalone Qt style out of it) - Nov 09 2010
this is a problem with the svn anonymous server. Happens every now and then.
You have to try again, like 5 minutes later. Nothing I can do about it (and sorry for the late answer ... been busy) - Oct 22 2010
yes. Its a conflict between blur and the line-edit animation (is it line-edit ? Or simple label) ? As of today I have no idea how to fix :(
basically the animation works as follow: - the line-edit/label is copy into a pixmap just before updating the widget
- it is painted on top of the widget
- the widget is updated
- the pixmap is painted over and over, every time with an smaller opacity until it gets totally transparent, at which point it is hidden, and the animation is finished.

Now, it does not work with a semi-transparent background: whatever opactity you choose, the pixmap + the editor will always look more opaque than the pixmap itself.

Only way around is to not use a superimposed pixmap but alter the lineEdit drawing directly (and not touching the background). I don't know how to do that with Qt :(

Hope the explanations are clear enough (though a fix would just have been better).
- Oct 22 2010
Hey,
First,
I didn't know about this digikam feature (!!), and I personally think it is not such a good idea since the whole point of having styles and colorscheme is to have consistent applications all over your desktop ... but hey. That was not really your question :)

On your question, no I can't, at least not easily. The reason is that applications don't talk to the decoration (at least not easily).

I might be able to do something by passing X properties to X11 when a different palette is detected by the style though.

Since it is an interesting request, and not directly related to oxygen-transparent, I suggest you file a bug/wish report at: https://bugs.kde.org

(makes my life easier to keep track on requests).

Please do mention oxygen in the bug/wish title.


- Sep 29 2010
This has to be a different issue.
Oxygen (widget style) is _not_ loaded at X server start.

(even KDE is not).

What did you do ? How did you get the right version of Qt in the end.
My suspission is that you ended up updating other things together with Qt, notably X and Graphics Card drivers, and something went wrong ...
- Sep 25 2010
Cool. I'm happy you're happy.
Yes I believe Plasma is a different issue.
To make sure, for some time you could use plasma (and plasma only) with a different 'widget style' (I know it sounds strange), by doing:

kquitapp plasma-desktop
plasma-desktop -style plastique

(or whatever style you like), and see if the same happens.
(first line kills plasma - don't be scared about the black screen).
- Sep 24 2010
Hello,

So the issue with the first post was that you were missing "svn" package (which I guess you figured out since then).

The issue with the second post is that you are missing the Qt 'devel' packages, or you are using a too old version of Qt (< 4.6). since the compiler complains about not being able to find some headers from Qt's animation framework (QPropertyAnimation).

You need at least Qt 4.6 (I think) to have this working. - Sep 23 2010
ahah. Interesting. must be a perl issue (or rather, an issue of me with perl). Will look. Thanks ! - Sep 20 2010
Hi,

Did you update (and recompiled) recently ?
The revision

"r1174508;
Backported changes to oxygen trunk and 4.5 branch that fix poor performances when oxygen is used together with NVIDIA"

is supposed to address this issue (for oxygen-transparent).

For the non-transparent version, see:

http://hugo-kde.blogspot.com/2010/09/performance-issues-one-script-and-call.html

It gives instruction how to get "native" oxygen, with the same patches (for both kde4.5 branch and trunk).

From the posted comments, it seems it is working (thought there might be other issues).

I'm actually very interested in getting your feedback on this.

Hugo
- Sep 20 2010
Hello pepe,
there is definitely something 'strange' with your system. The symptoms you mention points to some inconsistent libraries installed, and depending what you run (and from where) one library or the other would get loaded.

Could you post the result of
"ls /usr/lib/liboxygenstyle*" - Sep 10 2010
Oxygen Gtk

QtCurve 340 comments

Score 80.8%
Oct 23 2014
Some feedback on the inkscape crash.
Its actually a problem with "some" versions of gtk, that crash when an icon is not found. It should at least show a dummy (default) icon when this happens.

This was a known issue and has been fixed I think, with more recent versions of gtk.

The reason what it crashes when you uses oxygen-gtk or qtcurve is that it sets the icon theme to oxygen (to match kde), which results in the "icon-not-found" crash.

Sorry for the annoyance. - Jan 25 2011
mmm. That helps.
It might be that we are hit by a Cairo + graphics acceleration issue.
There was a similar problem with nvidia before. I'll try investigate.

Do you have any slowness with other gtk apps ? (with compositing enabled).
e.g. Gimp ? Nautilus ?

My best guess is that it is due to our 'fancy' background gradient. - Jan 24 2011
PS: I can't seem to reproduce the issue with bezier curves with inkscape.
Maybe, when you file a bug, you could also attach an svg file for which you do have the problem, and explain briefly how to reproduce ?

That'd be super helpful.

Thanks in advance ! - Jan 24 2011
Thanks for reporting !
indeed both are bugs that we should fix.
Actually could you post them on https://bugs.kde.org/ to make sure we don't forget about them ?

In fact you could rather post two separate bug reports.

The second is likely due to our icon "remapping" which is very similar to what QtCurve does, and which no other gtk style does.

- Jan 24 2011
could you try remove:

include "/etc/gtk-2.0/gtkrc",

or put it before:
include "/usr/share/themes/oxygen-gtk/gtk-2.0/gtkrc"

(though remove should be better)

This line definitely differs from the .gtkrc file mentionned above, and from mine.

Just a shot in the dark though. - Jan 21 2011
Done. Thanks for reporting.

Good new is, we are working on an experimental branch that does not require blacklisting (or at least: does not require any of the currently black-listed applications to be black-listed anymore).

git clone -b argb git://anongit.kde.org/oxygen-gtk - Jan 21 2011
PS: what happens if other styles (e.g. QtCurve) are used. Does libreoffice also use it ? - Jan 12 2011
yes it does. So that means its likely a problem with libreoffice (which I don't have installed here. I have openoffice, and things are working).

- Jan 12 2011
Does it (oxygen-gtk) work with other applications ? (like e.g. gimp) ?

- Jan 12 2011
yes there is, for recent enough version of kde.
Type "oxygen-demo" (eheh) from konsole.
It actually tests much more (I think) that twf.
- Jan 05 2011
Hi,

First: thanks.

Probably an issue with argb support.
See the README file for instruction on how to "blacklist" the application, and report back so that we blacklist it in the official source.

You would need to figure out the exact name of the program. - Dec 31 2010
No problem. (trust me: these are easy bugs to fix :))

I just changed to the right name in 1.0 and master.
- Dec 28 2010
Added (to both 1.0 branch and master).
Thanks ! - Dec 28 2010
Please send (detailed) bug reports at the link mentioned above, so that we get a chance to fix (otherwise, statements like this or that is unusable are not very useful to us).

Also, if you're not already, you might want to give a shot at the git repository, rather than the 1.0.0 tarball, since we did fix a number of bugs precisely with that respect already (in both inkscape and gimp).

Finally, you can disable (either partially or fully) the window-drag option using "oxygen-settings" (the Qt+Gtk oxygen configuration tool).
- Dec 25 2010
thanks!
Truth is: there are quite some bugs we are working on, and we have plans for new features, so yes: we keep on working.

Glad you like it already :) - Dec 20 2010
You can't really fix it.

Eclipse forces painting of a flat background on many of its widgets without letting us (the style) draw our background's gradient. Ecclipse fault really.

You can make things look nice
1/ by updating the code (using the git repository - see above). You would still get a flat background but with less contrast

2/ by setting the "shading" option to zero in systemsettings -> application appearance -> colors -> options, but you would then loose all gradients in all application (I don't think you want that).

Sorry.
- Dec 15 2010
you'd need to build cairo locally (it is quite easy), and patch it.
Same happened to me.
- Dec 15 2010
See:
https://bugs.kde.or/show_bug.cgi?id=259822

Not our fault. - Dec 15 2010
Actually the current list can be either black or white (see the argb-apps.conf comments for details).

For dev purposes we keep it black, because there is also a good 50% of apps that work just fine under ARGB and that you would never discover, nor test, if you use a white list.
(who would try to add an already working app there ?).

For instance: gimp, google-chrome (as far as I can tell), the complete mandriva control-center (which looks beautiful IMO), pavucontrol, ccsm, etc.

For packagers, that might want to ship oxygen-gtk into distros, we'll recommend to patch the file into a white list (for stability).

Well, at least that's the idea so far.

Also: it is quite frustrating that soo many applications just don't work. Providing a loong list of applications that can't support argb might convince people that things need fixing
- Dec 15 2010
Whats the exact name of the application you blacklisted, so that we add it to official sources ?
- Dec 15 2010
Actually, you two (Craig and Steveke) are probably correct. Thinking about it, since cairo allows you to overwrite background with fully transparent (aka, a hole), one might be able to have matching semi-transparent background gradient everywhere. (in Qt, for overlapping area, you would end-up with 50% transparency on top of the already semi-transparent background, which would not work, but cairo is different with that respect).

We'll look into it (likely for version 1.2.0 though, since 1.1.0 will be all about animations).

This might require some serious blacklisting though (about half the apps that have been tested so far can't handle an argb colormap).

- Dec 14 2010
unfortunately no.
There are limitations in gtk which forces us to paint the window background (with gradient) multiple times, and which in turn, would not work when using a transparent background.

So no oxygen-gtk-transparent.

Maybe Gtk-3.0 will make that possible (though I have my doubts). - Dec 14 2010
you're right, no uninstall.
I actually don't know how to tell cmake to uninstall stuff.

Concerning your question, I think it is safe (meaning you wont erase any source by compiling in the source directory), but not a good idea.

Creating a build directory inside the source directory and compiling from there should not be too big a deal :) - Dec 14 2010
I fixed by adding a compile-time #if that checks on Gtk version.

You would need to get the sources from git and recompile.

Either

git clone git://git.kde.org/oxygen-gtk
(to get the bleeding-edge and possibly buggy version)

or

git clone -b 1.0 git://git.kde.org/oxygen-gtk

(to get the 1.0 version, for which we fix bugs until 1.0.1)
- Dec 13 2010
Thanks ! I'm adding it now
- Dec 13 2010
Its probably related to Argb support.
You'd have to figure out the name of the application, and add it to argb-apps.conf

See the README file for instructions.
If it does fix it, please report back, in order for us to officially blacklist the file. - Dec 13 2010
Score 67.0%
Nov 14 2009