Bug 282057

Created attachment 63657 [details]
screenshot

Oxygen-gtk is primarily designed for kde.
What happens is likely that oxygen-gtk, when called from xfce window manager (whichever it is) must force the kde color to be used (read from kde settings), which is either not present, or incorrect. If there is a way to identify the guilty xfce primitive call we should simply fallback to the default gtk implementation.

Ruslan ? You're using xfce, right ? Any clue ? Fixable ? 

Installing xfce now to try reproduce.

Note: oxygen-gtk will _not_ follow xfce's color settings by default, because in the current implementation it is incompatible with forcing it to follow kde's settings (for computer on which both are installed), though at least it should fallback on something "usable".

Yes, i can reproduce this (in gnome), though windeco isn't fully black on my system. It seems those colors which should be set by oxygen-gtk appear black for some reason.
If i now kill gnome-settings-daemon, which is the means by which oxygen-gtk is set in gnome, i get correct colors, though trying to open window menu leads to XFWM crash (likely because of bug 275366).
Restarting XFWM with GTK2_RC_FILES set to oxygen-gtk path makes the title bar black again.
The fact is that XFWM uses XPM files which contain some references to named colors which seem to be set by GTK. It might be that we have to set them in some extra way, not just how we do now.

@David Rosenstrauch
If you re-select the XFWM theme in xfwm4-settings, you should get correct colors (until you restart XFWM/relogin). Is it so for you?

@Ruslan
Correct.  If I go into xfwm4-settings -> Window Manager -> Theme, and select a different title bar theme, all the windows get repainted, and correctly use the new window decoration theme (not black).  But this goes away when I log out and log back in again.

By the way, FYI - the "all black" title bar is due to the specific title bar theme I'm using ("Ops").  If I use a different one, (e.g., "Stoneage") then the title bar displays a bit better (i.e., I can see title text and minimize/maximize/close icons) but everything is still displayed only as white text/decorations on a black background.


@Hugo:
Understood that oxygen-gtk is intended for KDE.  (i.e., to make your GTK apps look like KDE/Oxygen-themed while you're running KDE.)  My use case is a bit different though.  Although I run XFCE, I set it so that both my KDE and GTK apps all use the same theme, and in that way get a unified look to my XFCE desktop.  I've been using qtcurve-kde/qtcurve-gtk for this up till now, but after finding out about oxygen-gtk yesterday I'm trying to achieve the same unification using the Oxygen theme (which looks much nicer IMO).  Not sure if this is a use case that's important for you to address, but just wanted to at least make you aware of why I'm trying to do this (and that it's not completely insane).  :-)

@David

> By the way, FYI - the "all black" title bar is due to the specific title bar
theme I'm using ("Ops").
Yes. In fact, if you select a hard-coded-color-based theme, you'll not have this problem.
BTW, to get oxygen window decoration for XFWM try this: http://xfce-look.org/content/show.php?content=123744


I'm still not sure if this bug is in XFWM or in oxygen-gtk. Still investigating.

> In fact, if you select a hard-coded-color-based theme, you'll not have
this problem.

I'm not sure how I would go about finding out if a theme is "hard-coded-color-based".  XFCE only lists the names of the themes; it doesn't show any details about them.  Can you recommend a hard-coded-color-based one for me to try?

Also, thanks for the tip on "XFWM KDE4.7 Oxygen theme"!

> Can you recommend a hard-coded-color-based one for me to try?
The theme I suggested (well, its basic part) is based on hard-coded colors, so it doesn't become black on xfwm restarts.

OK, I'll try downloading it and give it a shot as a workaround.

Please do keep me posted though if you're able to figure out the core oxygen-gtk/xfwm error.  Tnx!

"Not sure if this is a use case that's important for you to address, but just wanted to at least make you aware of why I'm trying to do this (and that it's not completely insane)."

This is important use-case. The more people use oxygen the happier I am. I'm just mentionning that it is not the "primary" objective, thus not highest priority, but yes, issues with running oxygen-gtk on other DE's will be addressed eventually.

(I have installed XFCE now, and so far could not reproduce the issue, but maybe because I use a hard coded color scheme for the window decoration. Will investigate more and yes, will keep you posted.)

Tnx, Hugo.  If you need help reproducing the issue, email me offlist and I can provide more details.  (Basic details are:  Arch Linux, XFCE4.8.0, KDE4.7.1.  KDE configured to use custom (dark) color scheme of my own, Oxygen windecos, and Oxygen widget theme.  XFCE configured to use oxygen-gtk theme, and "Ops" windecos.

Ruslan:  Tried using the windeco theme you recommended.  And while it does work in conjunction with oxygen-gtk (i.e., doesn't paint as black when I log in again) the windecos/titlebar paints itself in a very light grey color (as in the screenshot on http://xfce-look.org/content/show.php?content=123744).  This is quite jarring when used with the dark theme I prefer.  Is there any way to override the color scheme used by that titlebar theme?

> Is there any way to override the color scheme used by that titlebar theme?
Of course - just use the xfwm patch given on that page. The basic theme part is made of screenshots, just as a fallback when patch isn't applied.

Oh didn't realize I needed to do an XFCE patch to get that behavior.  That's kinda a non-starter with me.  I think I'll have to stick with qtcurve for now and wait and see if you guys are able to find a fix to this underlying issue before I can switch over to oxygen-gtk.  Thanks for the quick responses, btw!

Just wondering:  were either of you guys able to make any progress on the cause and/or a fix for this issue?  Thanks -- DR

No progress here.
In fact I have not been able to reproduce the issue with any xfce4 decoration theme I have tried.

oh ok, sorry, I take it back.
if I start xfwm4 inplace of kwin inside my kde session, I get the bug you mention.
should help debugging.

ok. Fix is "easy". Just need to 

1/ not generate gtkrc colors for xfwm4 application.
2/ disable widget named "xfwm" from window background painting (::draw_flat_box()).

Will try to find a clean way to do so.

mmm. In fact, only item2 is needed.

I don't think blacklisting is a proper solution here. It seems to me that we are having something more than just single application incompatibility.
If someone knows how (and where in the code) the named colors (active_color_1, etc.) in XPM files get translated into GTK colors, this would greatly help understanding the issue.

@ruslan:

no clue. Could not find any mention of "active_color" in either gtk nor gdk_pixbuf.

I'm also puzzled that disabling our own implementation of draw_flat_box for the widget restores the right background, if this where only a color assignment issue. (namely: whatever color we pick, our own painting should not over-write what the application paints in this case.). 

Anyway, I'll investigate some more before committing anything.

Thanks much to the both of you for spending time to look in this.  Much appreciated!  Would be great if it would be possible to get a fix for this.  I'm looking forward to spiffing up my desktop a bit.  Qtcurve, while nice, is getting a bit boring for me.

@Ruslan: 
progress. Apparently the colors are fubared when we call gtk_widget_get_modifier_style( widget ) in draw_flat_box
(line 155)

if I comment the whole block, things look nice.
if I add a single line of type 
gtk_widget_get_modifier_style( widget );
(with the block commented), things are bad again.

So, the idea of the fix is to first check whether there is an RC style set for the widget, and call the check above only if yes (to prevent explicit creation of this style). 

That fixes the issue in a non-blacklisting way, and should actually be better in terms of optimization for all other widgets.

I'll push to master and will let people (you, me, David) test for a while before backporting.

Cheers,

Hugo

Git commit 4baba17da78eed43d63e472bd5aa146aef02c21d by Hugo Pereira Da Costa.
Committed on 26/09/2011 at 16:55.
Pushed by hpereiradacosta into branch 'master'.

added check on RCStyle creation before calling gtk_widget_get_modifier_style()

CCBUG: 282057

M  +4    -1    src/oxygenstylewrapper.cpp
M  +7    -0    src/oxygenstylewrapper.h

http://commits.kde.org/oxygen-gtk/4baba17da78eed43d63e472bd5aa146aef02c21d

Git commit 41e8e7f56dc5c90080b937155ddb36125ae4cd64 by Hugo Pereira Da Costa.
Committed on 26/09/2011 at 16:58.
Pushed by hpereiradacosta into branch 'master'.

more checks on gtk_widget_get_modifier_style.
CCBUG: 282057

M  +7    -4    src/oxygenstylewrapper.cpp

http://commits.kde.org/oxygen-gtk/41e8e7f56dc5c90080b937155ddb36125ae4cd64

This sounds reasonable. (I can't even imagine how you've guessed to check this call :) )

I'm happy to test.  Just let me know what code I should pull.  Is there a tarball I should d/l, or should I pull it straight from git?

straight from git :)

git clone git://anongit.kde.org/oxygen-gtk

then 
cd oxygen-gtk
mkdir build
cd build
cmake ..
make
sudo make install

(there is an INSTALL file also that says basically the same)

OK, well I have some (mostly) good news to report.

I installed the new code from git, and it does seem to correctly pick up the window decos after re-login.  (i.e., change them to oxygen, log out, log back in again.)  See screen shot for example:

http://www.darose.net/oxygen-gtk-xfce-window-decorations-fixed.png

One (possibly related) little bit of bad news though:  for some reason, now when xfrun4 displays a pull-down list (i.e., to choose from a list of previously used app names) all the app names are displayed all in black.  Screen shot:

http://www.darose.net/oxygen-gtk-xfce-run-dialog-broken.png

It didn't used to look like that.  Previously, when I was using qtcurve, it displayed correctly:

http://www.darose.net/oxygen-gtk-xfce-run-dialog-previously-working.png

Related?

> Related?
Doesn't look like. Has it been OK before you installed this new version?

@Hugo
I confirm that the original bug report is fixed.

>> Related?
>Doesn't look like. Has it been OK before you installed this new version?

Don't know.  I've only just started using oxygen-gtk.

Should I file a separate bug report?

> Should I file a separate bug report?
Yes, this is another bug.

Marking this one as fixed.

Git commit defd9b6d1b4090946bb878b65632c3fd3cf8675e by Hugo Pereira Da Costa.
Committed on 26/09/2011 at 16:55.
Pushed by hpereiradacosta into branch '1.1'.

added check on RCStyle creation before calling gtk_widget_get_modifier_style()

CCBUG: 282057

M  +4    -1    src/oxygenstylewrapper.cpp
M  +7    -0    src/oxygenstylewrapper.h

http://commits.kde.org/oxygen-gtk/defd9b6d1b4090946bb878b65632c3fd3cf8675e

Git commit a9b4e80c50edc21f6e405253889938fc7973222e by Hugo Pereira Da Costa.
Committed on 26/09/2011 at 16:58.
Pushed by hpereiradacosta into branch '1.1'.

more checks on gtk_widget_get_modifier_style.
CCBUG: 282057

M  +7    -4    src/oxygenstylewrapper.cpp

http://commits.kde.org/oxygen-gtk/a9b4e80c50edc21f6e405253889938fc7973222e