Image 01
profile-image

HugoPereira

Hugo Pereira Da Costa
QtCurve
test
oxygen-transparent

QtCurve 546 comments

Score 81.0%
Jan 08 2013
mmm. Not sure an editor would catch it.
the "^M" is supposed to be a single character.

Anyway, try download (not copy paste from file open in browser) the link:

http://hugo.pereira.free.fr/Misc/oxygen-setup.pl

That's the same script, hopefully uncorrupted.
- Sep 09 2010
This one is 'easy', I hope.

See the ^M in your error message ? Its an 'end of line' character.

Is it actually in the script itself ?
If yes, most likely it was added to every end of line when you copied the script to a text file. That would make your shell scream.

- Sep 09 2010
actually I do reproduce the bug,
except that for me only the dock widget title is transparent, not its contents.

Annoying thing is that other apps with dock widgets (e.g. dolphin) do not show the issue.

This must be related to how kdevelop heavily customize dock widgets.

I'll see what I can do.
- Sep 09 2010
that's 'interesting' ...

I cannot reproduce, but I'm using a more recent version of kdevelop (in which I made a couple of commits for it to look better with oxygen).

I think I know what the issue might be, though.

Will work on it.
Thanks for reporting.


- Sep 09 2010
Hello pepe,

Sorry we missed on irc (just waking up: living in New Mexico).

Indeed your log output looks good. So I don't have a clue whats going on. (especially since you are able to find the oxygen style as root).

I can pass you a very similar script that gets the sources for *normal* oxygen from svn. Maybe you'd have more success with this one.

And then play with one or the other.
But really, no clue ... (and I can't reproduce).

The script: http://pastebin.ca/1936500 - Sep 09 2010
Unfortunately not.
That is, not without modifying the code
(you basically need to give the style a different name, e.g. oxygen-transparent), and (more important) different library names (in the CMakeLists.txt), in order not to override existing deco.

I have been reluctant to do that so far because it makes merging with "normal" oxygen modifications more complicated.

I will see if I can find an elegant way to do that though. - Sep 01 2010
oh.
Emerald. (which would be compiz actually, right ? Emerald is just a window decorator). Then there is a chance that the workaround that we found for kwin actually breaks compiz window placement.

Thanks for the info. - Aug 31 2010
yes you are correct.
Its a fancy Qt/kwin bug.
When you set transparency on a main window, a different window is actually created by Qt in your back. And somehow that messes up the window placement with kwin. We (Thomas originaly, in bespin) thought we had a workaround around this, but apparently (from your test case) it does not work when you ask for centered window placement.

I'll investigate some more (its a quite serious issue as a matter of fact). - Aug 31 2010
Hello,
thanks for the list.
Most likely: kdevelop is not needed (totally unrelated).

The rest should be enough though.
I'll add it to the comments.
- Aug 31 2010
interesting.
I confirm that the compilation went fine.
The warnings are expected and harmless.
Only 'unusual' thing I notice is the path where your files are installed:

/usr/kde/4/bin and /usr/kde/4/lib/

Probably these does not match the path where kwin (and the rest of kde, including oxygen-settings) look for pluggins,


(my installation path is more standard: /usr/lib/kde4/)

Could you double check whether:
1/ other stuff are installed in /usr/kde/4 (and not only your freshly compiled oxygen)

2/ is there things in e.g. /usr/lib/kde4 ?

Possibly if 2/ is correct you'd need to make soft links of what's in /usr/kde/4/lib in the /usr/lib/kde4

or reconfigure the source code (using cmake) to have the proper installation path

- Aug 13 2010
yes. I'm still trying to work this out.
Some widgets in plasma land must be black-listed and some not and I haven't figured it all out yet. (previous updates were not restrictive enough, and the current one is too much). Still working on it. Sorry
- Aug 02 2010
It has 'some' bugs in the sense that when translucency is enabled, most video players won't work.
But they can be blacklisted.
Kwin is also blacklisted for other reasons.

In any case, if you disable translucency (meaning: set the opacity to maximum), the code falls back to "regular" and "stable" oxygen.

So in my opinion, its pretty safe.
- Jul 30 2010
Done. Sorry for the late answer, and thanks for providing this.
- Jul 29 2010
So: google chrome: entirely not oxygen's fault. Chrome application does not use oxygen (not Qt, in fact) for rendering itself (inside the deco area) and notably it handles the window dragging/moving itself, and bypass wobling.

Kopete: fair enough, I'll check on a more random basis :)
It might be that I miss some resize events and do not update the blur area accordingly. - Jul 27 2010
Its a "feature". Some animations are disabled (on purpose) when blur is enabled (notably the tab transitions), because there are technical conflicts between the two (with translucent background you cannot use the background to erase part of the existing painting anymore !!)

All hover effects should work though (with poorer performances on some graphic cards).
- Jul 27 2010
- screensavers: fixed (for most KDE screensavers) with r1155113.

- google-chrome: you sure the issue you report is there only with translucency enabled ? Do you have kwin window decoration "enabled" (its somewhere in google chrome config). When it is on, I have no problem here. When it is off, that's different and should be entirely oxygen unrelated.

- kopete: I can't reproduce: the entire window (main and chat) has blur behind. Is there any steps for you to do in order to generate or does the bottom part appears unblurred from the start ? Do you have latest svn ? - Jul 26 2010
and its a "windows effect". Unrelated to oxygen. sorry - Jul 26 2010
mm. but you do have oxygen-settings application, do you ? There must be smthing wrong with your installation.

1/ you sure you ran "make install" (as root or using sudo) (sorry for asking)
2/ what's your primary kde version (4.4? 4.5?)
3/ can you try type "which oxygen-settings" in a terminal ?

I'm afraid I can't help much here. Normally, installation should work. See all other comments. So I don't really have a clue about whats going wrong on your system.
- Jul 26 2010
Thanks for repporting. I'll investigate all three (Indeed I have not tested any of the above so far). - Jul 26 2010
you can type "oxygen-settings" in a konsole or krunner, and it should be "background opacity" in the first page.
Alternatively, in systemsettings->appearance->widgets, click configure next to the style selection (with oxygen selected)
Or in the window decoration configuration.
All three points to the same value. - Jul 26 2010
Antelmo is correct.
And more precisely here what you're missing is libxrender-dev
as indicated (vaguely) by

"X11_Xrender_LIB"

(I know cmake error messages can get quite confusing and need some getting use to ...) - Jul 26 2010
"ERROR: cmake/modules/FindKDE4Internal.cmake not found"

That's the important line.
You are missing kde4 development packages too.

Hugo - Jul 25 2010
np.
And there is really really nothing wrong with doubting my code :)
(you should see how broken I can get things every now and then) - Jul 24 2010
mmm. Interesting. My bad.
The dragon player application name is "dragon". Not dragonplayer. Could you try to manually add "dragon" as an exception ?

As for smplayer, well, that's strange.
It does work here ... mmm ... - Jul 24 2010
stupid question (sorry for asking): it does work if you disable transparency (meaning: slide it to most opaque value), or if you use another widget style. Right ? (it should)

If not that's not an issue caused by this code.

Also: make sure that the applications are actually "checked" in the black-list.
- Jul 24 2010
is the log you post the only thing cmake says ? It doesn't print anything wrong (well apart from the end). Any missing part ? - Jul 24 2010
for resetting the flags, sure. You must keep track (I guess) of the widgets for which you've played. And even that is not bullet proof cause some widgets might change their flags even after the style altered (or just checked) them ... oh well ... - Jul 24 2010
it appears as "oxygen"
you just change the opacity setting in the style's configuration dialog (configure button on the right of the combobox), and that should be it - Jul 24 2010
problem is: it really depends on your distribution. Besides, here I have all kde dev packages (and some sources too, for hacking), so I can't really tell which is really necessary for oxygen (I'd need a fresh clean install, and go add them one by one).

In Mandriva, there is a meta package called task-kde4-devel. This one definitely do the trick (and likely installs more than needed, but on the other hand, dev packages are small). - Jul 24 2010
Also (now it is turning technical),
I think the setPosition(10000,10000), you should not do it if the widget is already visible (e.g. when changing styles).
- Jul 24 2010
Thomas,
"once WA_TranslucentBackground is set it cannot be removed"
Is it true ?
One thing that annoyed me with ARGB styles (bespin, but also qtcurve and more recently oxygen), is that once you select them, when you change to another style afterwards, you end up with fully transparent, unblurred window, because of the WA_TranslucentBackground not being unset in unpolish (probably due to your statement above), and thus left to the other style (and breaking it).

Now yesterday, reading the doc, I found "Setting this flag causes WA_NoSystemBackground to be set"

It turns out that if in unpolish I reset both NoSystemBackground, TranslucentBackground, (and I also added WA_PaintOnScreen for safety. Not sure It is needed), then the other style is happy.

So ... back to the "is it true ?"
- Jul 24 2010
Yep. This is what is meant in the description above by "this will erase your oxygen previous installation".

I am not familiar with 'checkInstall', but yes: the restriction above makes it basically impossible to create a usable rpm from this experimental branch (in fact: this is because this is a branch, and not a new piece of code).

You should still be able to install using the 'usual' way (cmake, make and make install). - Jul 24 2010
I fully agree.
Besides, blacklisting is not very welcome for things being committed inside kde (as opposed to kde-look). Bit too hackish.
I'll see if I can find a decent workaround.

- Jul 24 2010
You're missing some dev packages (something like kdebase-workspace).
Hence the missing "kdecoration.h"
- Jul 24 2010
Glad you like the follow-mouse animations (in principle they should actually work better than the ones in nitrogen, cause my math were not so correct there).

Not everybody does though, which is why they did not make it to the default. Oh well. No big deal. - Jul 23 2010
hehe. You're correct. I'll grey-list it. (meaning: its in the list of apps, but unchecked).
- Jul 23 2010
you're missing kde dev packages.
I'm sure kubuntu provide them. But not installed by default. - Jul 23 2010
because ... I was lazy. This is the same code, same style name, same everything, as oxygen, enhanced with transparency.

Now if you install this branch, and set the transparency to opaque, you basically get the 'old' oxygen.

So its hopefully pretty harmless. - Jul 23 2010
working on it.
Will commit application blacklisting tomorrow - Jul 23 2010
Well.

My fear is that adding plasma like white shade behind labels will clutter _a lot_ many applications. After all, some User Interfaces are quite complex and have _many_ labels.

In my opinion, I'd rather recommend _not_ to use full transparency, but rather something more subtle. I use an opacity of 80%. Windows are largely solid, everything is readable, and the hint of blurred background behind is subtle, non intrusive, and just in the spirit of the rest of oxygen's effects.

Just my two cents. - Jul 22 2010
argh. kaffeines broken also. Basically everything Qt based that embeds video. - Jul 22 2010
Actually, I can reproduce (sorry) in some cases. Its because sometimes the repaint (after the new area has been created) has occured before the blur area has been updated. I'll fix. - Jul 22 2010
I can't reproduce here.
Could you try "svn up" in oxygen-transparent/src/style
and then "make" and "make install" (as root or using sudo) in oxygen-transparent/build/style

This is the kind of bugs that r1152806 should have fixed. (make sure after svn up that it gives a revision number larger than the above).
- Jul 22 2010
I can't reproduce here.
Can you try "svn up" in oxygen-transparent/src/style

and then "make" (and "sudo make install", or "make install as root) in transparent/build/style ?

This is supposed to be the kind of bugs that r1152806 fixes. - Jul 22 2010
clear enough. Some other styles with similar feature (on which I based my code, e.g. bespin) have blacked-listed applications, namely smplayer; vlc, and a couple of others. Will add.
- Jul 22 2010
It means your missing some "development" packages (that includes the files needed for the code to compile against existing library). This depends on you distribution.

In my case (oxygen), that would be:
libxrender1-devel-0.9.6-1mdv2011.0.rpm

(and you probably need others, such as:
kdelibs4-devel-4.4.92-1mdv2010.1.rpm
) - Jul 22 2010
and style.
At least, that's the idea - Jul 21 2010
yes
you'd then get the native kde4.5 oxygen decoration. - Jul 21 2010
I agree that deriving the glow from the color scheme would be better than setting it manually in the decoration config.

Now the problem is: we actually use _two_ colors for the glow, and haven't found a way yet to derive the second from the first (which would then be picked from the color scheme).

But thats definitely on the todo list.
(I must say: I'm not so good at color handling). - Jul 21 2010
1/ you should not need to run the script as root.

2/ did you try to make the script executable ?
(chmod u+x oxygen-settings.pl)

Or to run it via perl directly ?
(e.g: perl oxygen-settings.pl)

If none of the above works, please tell me what exactly is the output when you try run it - Jul 21 2010
Score 67.0%
Nov 14 2009