HugoPereira

- Did you change your setup for *both* the window decoration and the widget style ?

- Did you set a non-opaque transparency setting for the widget style ?

Finally, there is a chance transparency settings on the widget style will only apply to newly started applications (so you might as well logout/login) - Apr 21 2011

Definitly a kwin bug. Easiest way to convince yourself about it (and other possible bugs, like the "shading" windows bug) is to try with another style that supports transparency like bespin or qtcurve.

Fixing this is quite low priority at the moment because

- kwin devs have their hand full with other stuff

- blur + transparent styles needs serious refactoring and optimization on top of 'just' fixing this one issue.

So you'll have to wait. Sorry. - Apr 08 2011

I'm pretty clueless at this point.
I would have suggested to checkout even earlier in the git repository, but that would mean overwritting your oxygen theme.

I too would give up at this point, and try again whenever you have kde4.6. This *should* work. (well: it does here).

Sorry sorry.
Experimental code.
- Apr 07 2011

ok. Wait, I forgot the other question (the overwriting)

Only the first of the revisions above do not overwrite oxygen.

So your only choice is
Quote:
- Apr 07 2011

ok. So:

First, I just updated the setup script so that you can specify the revision directly there. It should take care of checking out the right revision, and recompiling the code properly.

Second: I confirm that the revision I passed to you the first time simply does not compile (sorry about that).

Now I did try the following two "neighbor" revisions, and they do compile.

Quote:

the first one is located some time after the bad revision I originally gave you (it is actually the first revision to compile after this one)

The second is the one just before the one I passed to you.

Either revision should work.
Don't hesitate to post other issues you might have.
- Apr 07 2011

ok. Wait. Before you try more things.
Its probably just a bad revision (due to incorrect merging. which got fixed later.

Let me find a better revision and report back. - Apr 07 2011

mmm. Most likely its a graphics driver issue, though I can't tell for sure. Cannot reproduce here. What's your graphics card ? - Apr 07 2011

You need to clean your build area after the checkout and before recompiling
either "rm CMakeCache.txt" (in your_directory/build) or (if the above fails): "rm build/*"

- Apr 02 2011

you could try
Quote:

Thats the last revision before I moved oxygen-transparent to git.

See:

https://projects.kde.org/projects/playground/artwork/oxygen-transparent/repository/revisions/6ace8e6658afa88b77609cd6bb9941f13c40094b - Apr 02 2011

on fixing the crash, from TTY you can either:

- edit $HOME/.kde/share/config/kwinrc and change the decoration style (back to oxygen)

this corresponds to:
Quote:

- or edit $HOME/.kde/share/config/oxygenrc and change back the background opacity to 255. This corresponds to:
Quote:

(change both, if present, to make sure)

This should bring you back to working env, after re-login, without the need for uninstalling.

Note: in case this is the widget *style* and not the window deco that puts you into trouble, you can also edit
$HOME/.kde/share/config/kdeglobals

Quote:

As for your first question: the script installs you the entire revision tree of oxygen-gtk, so you have access to all versions.

The syntax would be

cd oxygen-transparent
git checkout XXXX
with XXX a revision name.

and then recompile the usual way.
(sorry to drag you into actually using git ...)

to get valid revision names, you can have a look at:

https://projects.kde.org/projects/playground/artwork/oxygen-transparent/repository

(right now the server looks down but it should be back online soon).

This gives you the history of all changes.

Finally, if you have time to try figure out the first commit that actually breaks your system, feel free to report here, that might help me to investigate further.

- Mar 31 2011

PS: is kwin crashing when you select the oxygen-transparent *window decoration* or *widget-style* ?

- Mar 31 2011

which KDE version are you using. Still 4.5 ? There is a tiny chance that latest code is actually not compatible anymore with 4.5 (kwin), though I can't test, having no 4.5 installed anymore.

Things work fine here with KDE4.6
Also: you should not need to uninstall. In principle just changing decoration style (e.g. using oxygen) should be enough, to get back your kwin, assuming that oxygen-transparent is indeed the issue ...

- Mar 31 2011

Well, as far as I can tell, its because WICD is _not_ a Qt application, but a gtk one.

Doesn't use oxygen-transparent as a style. - Mar 29 2011

it seems, to me that a couple of things are initialized "too early", with respect to Qt animation. maybe that's what corrupts things. I'll try to work on that.
- Mar 26 2011

It does ! Thanks for going through this !
(oh and I forgot, on your first message: no it is not your fault, I think!)
- Mar 26 2011

mmm. That looks bad indeed. Sorry about that.

Now, well, the crash info doesn't help much figuring out what goes wrong, unfortunately :(

(and I can't reproduce).

mmmm - Mar 25 2011

guys:
this is why posting things on kde-bugs is better than here.

Tabs animations being broken has been reported few pages ago here, and have been answered already:

they are disabled when using the transparent settings because there is no way to have them working there.

Basically tab animations is used by grabbing the old tab into a pixmap, painting it on the new tab and making it more and more transparent to mimick the fade-out effect.

This obviously can't work if the grabbed old tab is not opaque.

So there is no way to implement it with oxygen-transparent.
- Mar 25 2011

Seems from this report and others
- that there is interest (cool!)
- that I need some serious debug session on oxygen-transparent.

Please be patient, these days been quite busy with oxygen-gtk. - Mar 22 2011

Hello,

1/ is known and is a kwin bug, not oxygen.
Also happens with QtCurve and bespin

2/ is known issue with transparency and needs fix upstream. It also applies to most video viewer, and is one of the technical reasons why transparency will not go into kde's official sources.

There is already some comments about it in previous pages. (that's why its actually better to file bug reports on kde rather than post them here).

3/ definitely one bug of ours. Will see if I can fix. - Mar 13 2011

Hello,

Full window transparency is handled by kwin, not by oxygen (see how its working whatever style you use).

So it would need to handle blur itself, not us, since we know nothing about it. - Mar 13 2011

First, thanks for the support !
Second, answers:

1/ No. Not with oxygen-qt, and the qt to gtk conversion engine. There is now a gtk oxygen theme (that should work much better than the qt-to-gtk engine), at:

http://kde-look.org/content/show.php/?content=136216

But it does not support transparency yet.
It will, its on todo list, but there are more pressing issues.

Besides, many Gtk applications would simply just crash if you enable transparency. And many others (like firefox, openoffice, opera), won't simply allow it (you'd need to rewrite the application).

So: you might get it some day for "native" and well formed gtk applications (e.g. Gimp). But not today.

2/ for video players, same thing. This would work only if the player app fixes itself. So they should get bugged about it.

I recommend "vlc". Works just fine with transparency, and is one of the best player on the market anyway.

- Mar 08 2011

no. No merge with official kde. See comments above. There are technical reasons, and designers are not so enthusiastic about it anyway.

On the contrary I'll try to make it a standalone clone, provide timely based release and motivate some distribution to package the style, as an alternative to official oxygen. - Mar 05 2011

Thats helpful. Especially the fact that you found an identical bug reported already (which mentions that a more recent version of kontact should not have the problem. Right ?)

I asked about the widget style on the first bug report.

Note that the fact that it crashes for one style and not the other doesn't *have to* incriminate the style. Their can be some sort of race-condition that creates the crash and that one style triggers and not the other ...

I'll keep an eye on the bug reports to see what comes out. - Mar 05 2011

So using kontact 4.4.10 (which should not be too different from your version), latest oxygen-transparent, and raster engine, I don't have any crash with kontact (neither at startup nor whatsoever) So please give a shot at updating oxygen transparent and keep me posted :) - Mar 05 2011

Thanks for the info. I'll try run kontact with raster engine and see if I can reproduce with recent enough version.

Keep me posted if the bug 'happens' to dissapear by running a more recent version of the code (eheh. From git, now). - Mar 04 2011

Nope. Never of this. I'll try to reproduce but it will take some time (running kde from trunk I need to figure out which older version of kontact is usable and compiles with it).

For the record:
- which version of kde and kontact do you use ?
- does this happen with other styles (I guess answer is no) ?
- does it happen with other applications ? - Mar 03 2011

Hi,
I actually think its fixed (at least: should be).

See discussion above with Zephyr (which addresses the exact same crash).

Did you update oxygen-transparent recently ?

If no, please give it a shot, and close the bug if the crash is gone.

Hugo - Feb 24 2011

Ok. I tested, it works just fine apparently, and cant really creates regressions, so I committed your patch.

its in with r1219766.

Thanks again ! - Feb 10 2011

Whoa
Awesome ! Thanks a lot !
Testing it now and will commit.
(I have been able to reproduce the crash, with KMix only, when using raster only. Since it happens all the time, that should be easy enough to test)
- Feb 10 2011

ok. Fixed with r1219720.
my bad.

Thanks for reporting. - Feb 10 2011

yes I can confirm.
Investigating.
Sorry for the trouble. - Feb 10 2011

no clue.
Try "perl setup.pl"
- Feb 07 2011

Hello,

- concerning uninstallation of older version, you can't. Well in fact you can, with e.g. "sudo make uninstall", but since it wont restore the 'old' (non transparent) oxygen, it is not recomanded. I'd rather wait for the next update of your distribution (notably kde-workspace, or something like that), that would re-erase your "old" oxygen-transparent, with official non-transparent oxygen. (I hope it makes sense; and sorry for the mess, its precisely what the "new" version tries to address).

- new version, in contrast, has themes named "Oxygen Transparent" and do not overwrite any "official" version that you would get from your distribution. So you can install and uninstall at will.

Now, in principle you should not need to "make clean" before recompiling the new code, but it makes no harm anyway, so why not do it just to be sure ;) - Feb 07 2011

you need to find a gtk theme that supports transparency. Oxygen-gtk does not (not yet). Sorry. - Feb 07 2011

mmm. I don't know a single word of Italian, sorry. English ?

Oxygen Transparent (latest versions) will not appear (nor have any visible option) in oxygen-settings. (I'll fix that soon)

On the contrary you have to select it from systemsettings (standard kde configuration tool) in "workspace appearance" (for the decoration) and in "applications appearance" for the style.

In each, you can also select "configure" to change the "opacity".

Hoping this helps,

Hugo - Feb 05 2011

Its done. Just re-run the script, and things should compile now.

Sorry for the trouble; don't hesitate to report any other problem. - Feb 04 2011

Sorry about that.
My mistake. Should be fixed with r1218670. - Feb 03 2011

Not our fault.
Libreoffice comes with its own versions of libraries against which it links (notably libstdc++, if I remember correctly), that oxygen-gtk also needs.
However, these shiped version are incompatible with the ones against which the style was compiled, and therefore the style cannot load.

You should file a bug to libre-office.

(Note: this issue has already been raised in previous comments, and a solution might have been provided, if I remember right). - Apr 18 2011

Thanks for the info.
Case close then.
- Apr 13 2011

Wait. Now I'm really confused.
KWin has *no* resize grip.
The oxygen decoration (Qt based) has one, which is made visible only if you select "no border" for the border size. Is this the one you are referring too ? If yes, this one would obviously be independent from the theming engine (oxygen-gtk, QtCurve, or Raleigh).

Here neither Firefox, nor google chrome show any resize grip.

PS: a screenshot would really really help here.

But anyway: since it appears also when using Raleigh, which is built-in gtk, this is _not_ an issue related to oxygen-gtk, nor Qt Curve. So here is not the right place to discuss the issue.
- Apr 08 2011

This is certainly not a KDE bug: kde knows nothing about gtk, or gtk apps, and has no handle on the resize grip that applications paint or do not paint.

The fact that you also do see issues with QtCurve would tell me that this is not a theming style issue either, but since qtcurve and oxygen-gtk have some code in common, its not 100%.

Could you try with another simple (even if ugly) theme ? Like Raleigh ?
If this still shows issues, then its definitly not a theming issue. Either gtk, or the apps themeselves.

PS: like openoffice, firefox is not a pure gtk app (far from it in fact). As for google-chrome, it has a lot of custom code in there.


- Apr 08 2011

Which version of firefox and google chrome ? Mine show no resize grip at all, and hence no black triangles either.

In fact, would be best if you report this as a bug at https://bugs.kde.org, and possibly provide screenshots.

Thanks in advance !

Hugo

(oh and no, I was not aware of it) - Apr 07 2011

Hello

First, bugs (or issues) are better reported at https://bugs.kde.org.

Second: can't reproduce here.
Could you

- try use the sources provided here and compile, and see if the problem persists
(this would rule out whether this is a kubuntu problem or an oxygen-gtk proble)

- if the problem persists, try recompile the code in debug mode (see README for instructions); run an application, save the log output, and post it on the web (e.g. on http://pastebin.com/

That should help figuring out which icon theme is loaded, from which file, etc.

Thanks in adv,

Hugo - Mar 24 2011

mmm. That looks serious.
Basically you're having problem with us setting ARGB colormaps on menus.
Never heard of that before ...
I need to think.
- Mar 19 2011

you do need the 64 bits flag.
you also need to "make install" (which you did not mention)
and finally you need to select the oxygen-gtk theme either via KDE's systemsettings, or by editing your $HOME/.gtkrc-2.0 (or smthing similar)

See the README for details. - Mar 18 2011

Fixed.
That was a very stupid and recent bug of mine. Sorry for the trouble.

I assume you run from latest git (in master), since I could not reproduce the bug in any previous version. This is cool :)

You should have no pain updating. - Mar 07 2011

Ok. I can reproduce (with master etc).
Filed a bug report for you. See:

https://bugs.kde.org/show_bug.cgi?id=267881

I know where the problem comes from (our combobox list resize hook), but not sure yet how to fix.

Will keep updating the bug report. - Mar 07 2011

also, please note: bugs are better reported on https://bugs.kde.org. Makes everybody's life easier for book-keeping :)

Anyway. Trying to reproduce now. - Mar 07 2011

which version of oxygen-gtk are you using ? - Mar 07 2011

this is hopefully fixed with latest code (either from master or 1.0 branch). Could you double-check ?
(I, myself, have never been able to reproduce the crash).

I'm still trying to make the fix more user-friendly and less hard-coded, but there are issues. - Feb 22 2011