Bug 152030 - oxygen window decoration does not honor titlebar color
Summary: oxygen window decoration does not honor titlebar color
Status: RESOLVED INTENTIONAL
Alias: None
Product: Oxygen
Classification: Plasma
Component: win deco (show other bugs)
Version: 4.0
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Camilla Boemann
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-08 22:02 UTC by Martin Koller
Modified: 2008-08-17 12:54 UTC (History)
16 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
colored window decoration (711.86 KB, image/png)
2008-03-21 00:57 UTC, Huynh Huu Long
Details
patch for the oxygen window decoration (10.79 KB, patch)
2008-03-21 13:26 UTC, Huynh Huu Long
Details
kwin patch (11.29 KB, patch)
2008-03-21 14:38 UTC, Lubos Lunak
Details
screenshot with the patch (Wonton Soup colors) (283.31 KB, image/png)
2008-03-27 21:17 UTC, Matthew Woehlke
Details
kwin patch (11.66 KB, patch)
2008-04-09 17:40 UTC, Lubos Lunak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Koller 2007-11-08 22:02:46 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
OS:                Linux

The oxygen window decoration comes with an ugly grey-in-grey look of the window titlebar and borders.
I can not distinguish which window is active, which is inactive, neither is it simple possible to see where a window ends when I have 2 or more windows overlapping.
So I checked where I can change the color - and found that the Active Titlebar color is already set to blue and the Inactive Titlebar color is set to grey, but both colors are ignored (and also the text color for the titlebar)
Comment 1 Camilla Boemann 2007-11-09 05:21:01 UTC
That is work as designed. The oxygen windows are meant to blend in with the window contents. So if you want to change the window frame you need to change the window background and window text.

I suggest you turn on shadows, which is assumed/meant to be on. It makes it much more easy to tell one window from another.

If you truly want to have your frame in another color than the window background you are free to choose another window decoration.
Comment 2 Andreas Pakulat 2007-11-09 11:05:58 UTC
Sorry, but you're wrong. If the default oxygen setup should have the same color for widget contents as for the titlebar, then adjust the default oxygen color scheme to be that way. But _forcing_ the titlebar of the windows onto the user, even if they _explicitly_ changed it via a configuration dialog is plain broken. The oxygen designers are free to do whatever they want with the oxygen themes (windeco, style, colors), but if a user changes one of these that should be adhered to. We're not that other DE that doesn't allow users to change things.

Apart from that shadows, AFAIK, only work if you have composite available which is still not something you can depend on being there on all (or almost all) machines that run KDE. Even if its just XRender thats needed for shadows, it still is problematic in quite some "usual" setups (like a second screen).

So to clarify: The oxygen style and windeco shouldn't limit the configurability of the overall look. 
Comment 3 Lubos Lunak 2007-11-09 20:15:58 UTC
Casper: I support what Andreas says (everything, including the part about the [un]availability of shadows). As the KWin maintainer I find it unacceptable for the default decoration to not follow the color scheme. And, given the reasons above, I don't like the titlebar not standing out much either - assuming this wasn't your idea, where has this been decided, what's the person to talk to about this?
Comment 4 Andreas Pakulat 2007-11-09 21:06:22 UTC
The person who does most of the artistic stuff about windeco and style is Nuno Pinheiro. I don't genrally oppose the idea of having the titlebar and the widget background "merge", but I do oppose the current implementation of that design decision as it removes configurability for just 1 windeco. I instantly drop any new windeco in kde3 when I find I can't change the colors of some parts because the windeco (or style for that matter) hardcodes them.
Comment 5 Eike Hein 2007-11-09 21:46:11 UTC
I agree with Andres, too. What he's saying simply makes technical sense: It should be perfectly possible to achieve the merging effect just as well by having the title bar and window background colors be the same in the color scheme, rather than ignoring them. Granted, the extra work comes from the case in which they are not the same, of course, given how the code works atm :). But I'd say it's not acceptable to ship a default decoration that doesn't properly implement our color preferences.
Comment 6 Thibaut Cousin 2007-11-16 20:27:00 UTC
I voted for this bug. I worked for a whole day using KDE4, as a test and using Oxygen.

It went rather well, but the lack of contrast and the problem mentioned above made it a bit painful to the eye. Everything blends so well that it's hard to distinguish the outline of menus inside a window, it's hard to see quickly which is the active window, etc.

Another consequence of this "blend" thing in the window decoration: you don't know exactly where to click if you want to move the mouse. Several times I clicked a little too low, in the menu bar instead.
Comment 7 S. Burmeister 2007-11-21 18:43:37 UTC
Regarding the "I cannot see where a window ends". I suggested to introduce a setting to be able to change the colour of the outer 1 pixel border, i.e. one could have a 1 pixel black border around the window.

I was told to simply not use oxygen - because of one setting which would not even change the default look of oxygen.
Comment 8 Thibaut Cousin 2007-11-21 19:07:51 UTC
That would be useful indeed... I upgraded today to KDE 3.96 and I don't have any shadows, even with Composite enabled *and* the shadow option activated in System settings.

Back to the main topic of this bugreport, in KDE 3.96 the titlebar still can't be customized...
Comment 9 pinheiro 2007-11-21 20:58:21 UTC
that ahs been decide on kite a big thread in kde-devel mailing list its suposed to be made to look like http://www.nuno-icons.com/images/estilo/image4618nocoloring.png
Comment 10 Camilla Boemann 2007-11-21 21:20:33 UTC
Actually the "where one window ends when overlapping" is going to be solved so Sven I think we must have misunderstood each other if that is what you asked for.

I understood it as you wanted a frame around that changes color depending on the window being active or not
Comment 11 Martin Koller 2007-11-21 21:28:20 UTC
To have a colored border like in the Plastik style would indeed be a good solution.
Comment 12 Thomas Zander 2007-11-21 21:36:54 UTC
One (bevelled) line difference and a hardly noticeable difference in color is the outcome?
The bugreport clearly states configurability to be an issue and the reason for that is that the window decoration is not just some handle at the top, it is there to make clear where the window ends (and another begins). I.e. its there to give it a frame.  Many people need that visual feedback.
With the decision as stated in #9 you not only ignore the request to make it possible to notice the window boundaries, in the default setup; you actively refuse to allow people configure it to make the style usable for those that need the visual frame around a window.

I would like the artists to not assume everyone has as good equipment (or eyes!) as they do. 
Comment 13 Thibaut Cousin 2007-11-22 03:39:00 UTC
About comment #9: this looks nice, but that screenshot is a bit too convenient. In real use, it's much more confusing that the screenshot leads to believe, especially when you have overlapping windows... and sorry, my screen is only 1680x1050, so I can't avoid overlapping windows. 

When you have overlapping windows, the absence of shadows and the same color for inactive and active window decorations makes the whole thing tiring to the eye.

The only different between active and inactive window is the color of the text, right? One is light gray, the other is... less light gray. That's way too subtle for many people. Maybe an artist has the accurate perception of colors to find that nice, but many people haven't.

I'm really disappointed with comment #9. When an artist works on the *default* KDE style, I would expect him to be a least willing to listen to user feedback. After all, the style is meant to be used, right? And browsing through KDE mailing lists and KDE planet blogs, I get the impression that we aren't the only ones complaining here.
Comment 14 Kurt Pfeifle 2007-11-22 11:25:06 UTC
@ pinheiro, re. comment#9:
--------------------------

It the *very* subtle difference between active and inactive window in your mockup from http://www.nuno-icons.com/images/estilo/image4618nocoloring.png may look nice to *some* (or even many) people. I note that the two windows from this example do not overlap, but are separated. Can you please make a mockup that shows what is seen if the two windows overlap?

However, for *all* people who do work on 1024x768 screens (like I do), or even 1600x1200 (like my colleague does), it often happens that 2 (or more) windows do overlap. (It will also occur that there will be no shadows for windows.).

So how do I see where one window ends (there is no border!) and the next title bar starts??

This may be pretty, but it looks very disturbing, visually-wise. As soon as you have overlapping windows, it becomes a non-pretty, un-distinguishable mashup and mess of gray-ish areas pretending to be separate items on a computer screen.

So it seems to be completely usability-hostile to everybody who can't affort an extremely large screen to avoid frequently occuring window overlappings.

Please consider the default use-case of people with smallish screens and more than 4 windows open. Please provide a mockup of that to convince me it can be done.

Comment 15 David Jarvie 2007-11-22 13:03:25 UTC
And some windows automatically overlap. For a good example of an extremely confusing overlap, try running a fresh KOrganizer (i.e. without any data set up) and open the Settings dialog. The dialog (on my system, at least) appears in the middle of the KOrganizer window. It's very difficult to tell which visual elements are in the dialog and which are not, because they are all a nearly undifferentiated shade of grey without any border round the dialog. Switching to a non-oxygen style will be the only answer if that's the appearance of KDE 4.0 final.
Comment 16 Thibaut Cousin 2007-11-22 17:31:50 UTC
A little update: for some unknown reason, my KDE 3.96 started using compositing today... Admittedly, it makes the desktop more usable. But :

- The shadows drawn around each window makes overlapping windows a bit more distinguishable... except at the top. There is no shadow around the upper border of windows. This is physically normal, but it means it's hard to find the window decoration (if you want to move the window, for example) when it's over another. A thin border would solve the problem.

- The window decoration is still locked, and still grey on grey on grey, which makes a sorry combination with the above problem.
Comment 17 Camilla Boemann 2007-11-22 19:44:44 UTC
Just to repeat myself. The thin one pixel "shadow" border is being worked on and will be committed soon.
Comment 18 Thibaut Cousin 2007-11-22 22:48:40 UTC
OK, I got the message. :-) Thank you for your work and your patience, I'm eagerly awaiting the result.
Comment 19 Stanislav Visnovsky 2008-01-09 13:18:49 UTC
Being hit by this bug as well, voting.
Comment 20 CSights 2008-01-19 23:54:42 UTC
Installed KDE 4.0.0 from Debian experimental and notice the grey active title bar.  I don't think the 1 pixel border is a good fix.  At least have an option to have a differently colored title bar! (If you don't like options, just get rid of the grey on grey.  It isn't THAT pretty.)
Comment 21 Felix Möller 2008-02-23 12:28:50 UTC
This bug has been posted in the novell bugzilla too. (https://bugzilla.novell.com/show_bug.cgi?id=361262)

I do not have a problem with the default design beeing gray blend into gray. But not beeing able to change it is quiet disappointing.
Comment 22 premierSullivan 2008-03-13 20:22:17 UTC
This is only peripherally related to this bug report, but sometimes you might have to restart kwin (log off and log back on) to get color scheme changes to take effect.
Comment 23 Huynh Huu Long 2008-03-21 00:57:49 UTC
Created attachment 23984 [details]
colored window decoration
Comment 24 Huynh Huu Long 2008-03-21 01:00:08 UTC
Doing a patch is quite simple, even for me as a non C++ programmer (actually the last program i have written in that language was a "Hello World" program ...). Is anyone interested?
Comment 25 Thomas Zander 2008-03-21 10:41:51 UTC
Huynh huu long; a patch is indeed nice. I get the impression the oxygen programmers will just ignore this bug so people can then patch their own compiled version.
So, please attach that patch :)
Comment 26 Felix Möller 2008-03-21 10:46:28 UTC
Huynh Huu Long, that looks really great! Nice work!
Comment 27 Lubos Lunak 2008-03-21 12:25:35 UTC
I almost have a patch that handles this.
Comment 28 Huynh Huu Long 2008-03-21 13:26:09 UTC
Created attachment 23989 [details]
patch for the oxygen window decoration

Ok here it is. I hope you won't too many mistakes, this would be my first
contribution to the open source world anyway :)
Comment 29 Lubos Lunak 2008-03-21 14:38:24 UTC
Created attachment 23991 [details]
kwin patch

Hmm, funny, this has been open for quite a time and now there are two patches.
Here's mine.

Huynh Huu Long: You didn't not make any mistakes in the patch, it looks very
similar to mine. The only difference is that you made the change color oxygen
differently from me, I think that this way oxygen should fully follow the
global decoration colors and should not do any contract tricks e.g. in
OxygenClient::titlebarTextColor().

However, the currect color kcm does not fully support all decoration colors. I
will need to talk to Matthew about this.
Comment 30 Matthew Woehlke 2008-03-27 19:14:39 UTC
Lubos: you forgot the changes to client/oxygen/CMakeLists.txt :-). Other than that, the patch looks OK; please check in. (Now boemann and/or pinheiro get to yell at me, but I decided I like to be able to tell the titlebar apart from the menu and the window behind...)
Comment 31 Camilla Boemann 2008-03-27 19:58:19 UTC
Nope

This should not go in. Sorry.

I suggest that if you don't like the oxygen look that you create you own windec instead
Comment 32 Lubos Lunak 2008-03-27 20:20:08 UTC
I (and not just me, apparently) consider the undistinctive decoration a rather serious problem and this patch is the least I'm willing to allow for the default KWin decoration for 4.1 (and that is still being pretty benevolent given http://websvn.kde.org/*checkout*/trunk/KDE/kdebase/workspace/kwin/clients/REQUIREMENTS_FOR_CVS). I'd prefer to get this resolved in oxygen and not having to fall back to the other remaining option of KWin defaulting to a decoration that can follow basic rules. It's up to you and the artists to make the pick.
Comment 33 Matthew Woehlke 2008-03-27 21:17:30 UTC
Created attachment 24084 [details]
screenshot with the patch (Wonton Soup colors)

Screenshot with Wonton Soup color scheme, so folks can see what it looks like
presently. This needs work (it's too "in your face" right now), but it's a
start.
Comment 34 pinheiro 2008-03-28 11:21:15 UTC
Hey I made a new mock up with lots of windows. Personaly I dont see much of a problem. Any way we are going to redo the windeco butons for somthing with a bit more color. Think that will help.
http://www.nuno-icons.com/images/estilo/nocoloringlotsofwindows.png

Ok now for the (Im a stupid arrogant artist) part :)

I don't want to see coloring option on the windeco, sory its a rupture of concept, its not the the option itself makes me angry its the fact that the option makes it look very very bad. And I can see no way of fixing that problem. Again its a rupture of concept.
As it is righ now it does not make me totaly satisfied wich im not (think its mostly due to code limitations, and having a good dropshadow), but it will get beter, and beter and beter. IM curently working with other artist to come up with beter scrolbars progressbars, small improvments to butons, anf fine tuning allot of aspects in oxygen. 
 
Comment 35 Luciano Montanaro 2008-03-28 11:30:29 UTC
Pinheiro: Nobody forces you to use different colors for the decoration, for your personal use. So your aestethic sense can be preserved.

If you object that the colored borders do not look as good as they should, find a way to make the colored borders look better.

The different color roles are part of KWin decoration specifications, you should not ignore them when designing your decoration.
Comment 36 pinheiro 2008-03-28 11:39:29 UTC
Luciano Montanaro the ground idea was and is a slab of coerent material it was based on an original rendering made by Ken in time of the frist oxygen meeting,
How can a  coerent slab have a difrent colored non uniform border?
In my opininon it cant.
Unless you afect the intire window, but that was ruled out long time ago. 
Comment 37 Camilla Boemann 2008-03-28 11:59:28 UTC
Actually affecting the entire window is very possible

Just activate the state effect in the color kcm

It makes it very easy to tell apart the active from inactive windows
Comment 38 Luciano Montanaro 2008-03-28 12:07:55 UTC
That may be your idea on how things should be viewed, but it's not a technical limitation. Clearly there are users out there that have no strong urges to stick to that idea, and that prefer to have a stronger hint at what window has the focus.

If you think your original idea does not work well with the features KWin provides and its technical limitations, you can still change the bits that do not work.

The current patch may be a bit crude, but it fixes the issues until someone comes out with something better.

Actually, I think there are plenty of ways to improve the current patch -- you could have the titlebar color blend to the window color, for example. Or use border/titlebar colors as highlights...
Comment 39 Thomas Zander 2008-03-28 12:09:25 UTC
On Friday 28. March 2008 11:21:19 pinheiro wrote:
> Ok now for the (Im a stupid arrogant artist) part :)
>
> I don't want to see coloring option on the windeco, sory its a rupture of
> concept, its not the the option itself makes me angry its the fact that the
> option makes it look very very bad. And I can see no way of fixing that
> problem. Again its a rupture of concept.


I think its very selfish to force your view of the way things should look upon 
others.  Especially when those people find it stands in the way of actually 
being productive.
It might be good to be a little less arrogant so people want to use your 
stuff :)
Comment 40 Camilla Boemann 2008-03-28 12:22:14 UTC
Come on, we are not forcing anything. If you don't like a frameless windeco, then choose anther windeco that _does_ have a frame.

It is you (all) who are forcing, by saying we _should_ have a frame.
Comment 41 Sascha Hlusiak 2008-03-28 12:50:23 UTC
The Oxygen window decoration is the first thing I change when I log in to KDE4-svn. Isn't that sad? Not because it's ugly, but because it's unusable. And no, I don't use the desktop effects that might make it usable. Please design the decoration so that it looks good on non-composited desktops. 

I am forced to choose another decoration, so let's choose another default window decoration if Oxygen does not want to become more usable. Being unable to change the colours is unacceptable. How can having an option be a bad thing? I vote for freedom.
Comment 42 Lubos Lunak 2008-03-28 13:25:25 UTC
Let's see:

Comment #34 : Why do you create a mockup when you can simply do it for real? Some problems only show up when you actually try to use things. You actually do use it, don't you? And this specific issue shows up in many KDE4 reviews (http://arstechnica.com/reviews/os/kde-40-review.ars/2 , for example), so apparently there are many people who consider this to be a problem. And if the concept says that the decoration will be like this, then it's perhaps a problem in the concept.

If you want to fix the problem by some other ways, like more coloring of the buttons, ok (although I myself consider something like http://www.guidebookgallery.org/pics/gui/desktop/full/macosx103-1-1.png still poor enough to warrant the inclusion of patch from comment #29).

Comment #37 : As far as I undestand it, different coloring for active/inactive windows as a whole has several serious problem like extensive flicker, so that does not look like a realistic solution.

Comment #40 : You're not serious, are you? Oxygen is the default decoration, it doesn't have any possibility to actually follow the color settings, and you don't want to accept a patch that at least optionally allows that. You got it backwards, sorry. It's ok if people do strange things in their decos, but the default has to play by some rules.
Comment 43 pinheiro 2008-03-28 13:36:44 UTC
Lubos Lunak the problem is that acepting that alteration is not oxygen, sory its not, the idea is that oxygen is a ceramic slab a coerent one. 
Btw in inactive mode i want that the dividing line to fade out completly. thas the reson I show the mocks, the mocks are always alot closer to what we realy want than what we now have.
 
Comment 44 Alexandre Pereira 2008-03-28 13:39:41 UTC
the frame is completly ugly and breaks the whole concept.

to me the frame should not exist , not even if you have 1000 windows and that is the only way to diferenciate them.

about the colors of active and inactive, i dunno if the style should or not ignore the color scheme, but the colors should be the same.

the problem is that the thing that diferenciates windows from active or inactive shouldnt be the titlebar color , but the whole window.

that is just a concept of windows 3, that lived forever but must die ! my eyes always rest on the middle of the window , not on the titlebar to check if its active or not.

said that , i think that "trailfocus" ( on compiz ) and "dim inactive windows" are the way to go. the whole windows should be transformed.

the only idea that i can give to current state , is to put the active window text with a good strong glow that is noteceable.

other than that , its completly messing with a very good style ( and a style is just that , one style , one look ... you cant make a style that has all the styles and looks. dont like oxygen ? use another , theres nothing wrong with this. it doenst mean that oxygen is bad)
Comment 45 Alexandre Pereira 2008-03-28 13:41:04 UTC
by the way , by " the frame " i mean the top horizontal line between the titlebar and the style. ( i like how in inactive the toolkit and the windeco merge together )
Comment 46 Lubos Lunak 2008-03-28 14:00:25 UTC
Comment #43: I'm open to suggestions on how to solve this problem more in line with what Oxygen wants to be.

Comment #44: DimInactive is currently not a feasible solution for purely technical reasons. And, as far as coloring of whole windows goes, I think that's been rejected for the default, probably because of the IMHO rather unpleasant flicker.

Comment 47 Camilla Boemann 2008-03-28 14:20:48 UTC
comment #46 Ok that is a more positive attitude. When you (all) come out and say that a frame must be introduced then for sure we put our foot down. This doesn't mean we don't recognize that there is a problem.

Pinheiro have already commented about coloring the buttons. Pinheiro and I have also discussed making the icon of inactive windows grayscale, and making the active/inactive differencebigger on the dividing line.

But we don't have many options, though similar suggestions are naturally welcome Coloring a frame (even with a gradient) is not an option.

DimInactive is indeed not an option for default. Besides requiring composite it also dims images and movies indescriminately, which is not that nice if you are working with graphics.

Coloring whole windows doesn't require composite, but yes it was ruled out as default because some people thinks it flickers too much. Our "oxygen" vision for this whole windows coloring was always a very subtle (almost below visible) effect, that your subconsience would use to pick out the active window. I use it and find it very nice and nonflickering. But, sure, I accept that people are different.
Comment 48 Will Stephenson 2008-03-28 16:33:49 UTC
i understand the 'one piece marble slab' idea, but the problem is is that, it's required to differentiate the active slab.  if the only way to do this and keep 'one piece' is to change the entire slab, and that mechanism doesn't work, we have a problem.

maybe you could draw the active slab with some kind of lighting effect, like a highlight.  this might take the form of light reflecting off a polished bevel on the edge of the slab.   this way the active slab would keep its 'one piece' whole, and be distinctive.  

It could even be a thin, bright highlight at the top borders and between the top corners and the midpoints of the sides of the window, which would be consistent with the lighting on the buttons.
Comment 49 pinheiro 2008-03-28 16:52:59 UTC
Will Stephenson this is the type of thing im more than willing to try.
Coerent with the ground idea but still helps in the diferentiation.
Im gona do some rework on the butons so somthing might come out of that...
Ideas are welcome....
  
Comment 50 Matthew Woehlke 2008-03-28 18:06:20 UTC
> It could even be a thin, bright highlight at the top borders and between the top corners and the midpoints of the sides of the window, which would be consistent with the lighting on the buttons.

That's very similar to the idea I had for improving the patch (with perhaps more of the highlight color at top). But IMO the patch as-is should be committed first as a starting point (not least because I want the config option there).

Maybe as a compromise we could commit the un-fixed patch, so that the code is there but not accessible unless you modify CMakeLists.txt yourself and recompile, or else sic a text editor on oxygen's rc? (This wouldn't be wholly unprecedented; there are already such "hidden" options to change the checks to 'x's, and to pick between three styles of menu highlight.)
Comment 51 pinheiro 2008-03-28 18:31:42 UTC
Matthew Sorry but that patch starts on the wrong foot, visulay wise no colorosation please lights shadows ok, but colorization no.
Like I said that would not be oxygen, its an ok option but its not oxygen well oxygen as I thought it. 
Comment 52 airsnail 2008-03-28 18:50:22 UTC
There seems to be some miscommunication here, but maybe I'm confused.

The bug is originally about the unconfigurability of the windeco colors, but it has sparked a critique of the default "slab" look. Lubos' patch doesn't change the default look, it just makes it possible to do so using the normal color configurator.

Perhaps there needs to be a second bug to discuss ways of distinguishing between active and inactive by default, without breaking the slab.

Apologies is this was clear to everyone. It seemed like the resistance to the configurability patch might have stemmed from resistance to changing the unified default look.
Comment 53 Camilla Boemann 2008-03-28 19:21:05 UTC
#52 that is because it's the same thing effectively.

As the window is frameless there is nothing to paint with the colors, so we follow the colorsettings 100%.

using the windowframe colors would mean we would have to introduce a frame (as the patch does)
Comment 54 Matthew Woehlke 2008-03-28 19:34:00 UTC
> Matthew Sorry but that patch starts on the wrong foot

I disagree. Artistically, that may be true, but from a code perspective I still feel that 99% of the patch needs to go in. One we *have* 'do this to use color, otherwise do the original thing', we can start refining what "this" looks like. Meanwhile, at least the deco is usable, which at the moment it isn't.
Comment 55 pinheiro 2008-03-28 19:49:11 UTC
i made some chages and new options here, http://www.nuno-icons.com/images/estilo/nocoloringmoreoptions.png  take a look. There are 4 inactive difrent proposals and 2 active, comments are wellcome.  
Comment 56 Matthew Woehlke 2008-03-28 19:53:21 UTC
> comments are wellcome

Not one is acceptable; it still is not obvious enough where the titlebar ends and the menu/toolbar/whatever begins... which is why I found oxygen in its current state unusable. As Lubos said in comment #42, this needs to be addressed. I haven't seen a proposal yet that does so.
Comment 57 pinheiro 2008-03-28 20:03:01 UTC
So the solution is... anything goes as long as its colorable?
To that solution i say ok but dont call it oxygen, its somthing else. Unless some one can make me a mock/screenie of a colorable windeco that still looks like a uniform material. 
Comment 58 Celeste Lyn Paul 2008-03-28 20:28:03 UTC
Can someone explain (perhaps off the bug thread) the flickering problem with kcm and if/how it can be fixed?  I think changing the entire window color value (read: the amount of black or white in the color and not a different rgb value, with and without hardware acceleration) is the best solution but this solution can't be used because of flickering.
Comment 59 Riccardo Iaconelli 2008-03-28 21:04:55 UTC
Just FYI, on my hardware, and almost anywhere where I've seen this in action, it doesn't flicker.
It does (from what I've seen) just on setups where there's an X server on a remote machine (e.g. what Luciano does).
Comment 60 Andreas Pakulat 2008-03-28 22:22:33 UTC
#59: Then I suggest to try it on a 3 year old laptop. I don't see a flickering either, I can literally see each widget inside the color dialog redraw itself because its background color changed. Its not that visible in konsole, but thats because 90% of konsole are drawn without using the style. Also just flipping on that checkbox has nearly no visible effect wich makes it a useless option. Only after changing the intensity to something a bit darker the difference in color is visible enough to easily see which window has focus.

Maybe I don't have any subconciousness, but for me a almost not noticeable color change just doesn't cut it. Think about having your whole desktop cluttered up with various windows, then (with focus follows mouse) close your eyes move around the mouse wildly (so some random window has focus) and then try to find the window in less than 2 seconds.

Just my 2 cent.
Comment 61 Thomas Zander 2008-03-28 22:56:32 UTC
On Friday 28. March 2008 20:03:04 pinheiro wrote:
> So the solution is... anything goes as long as its colorable?


Creating a product that will be used by a lot of different people, of 
different ages and different levels of eyesight/hardware puts a lot of burden 
on which solutions work.
Over the last 20 years a lot of people have been working on this problem and 
the changing of the color has been unanimously chosen as a good solution for 
the wide cross section of our userbase.

I don't think its realistic to expect a concept that throws this knowledge out 
of the window to be usable. You can't expect to invent something better 
without any user research and in depth color knowledge.

> To that solution i say ok but dont call it oxygen, its somthing else.


Its a shame to hear you say that, a vision you guys had didn't stand the test 
of actual usage for a significant portion of users.  Those users want to be 
able to still use the oxygen windeco, as long as they can change the color, 
like they are used to.
I find it sad to hear that just because their usage violates your design, you 
don't want it. Or don't want to have anything to do with the result anymore. 
While in practice you probably will never have to see the result on your 
screen anyway.

It would be great if you guys could give in a *little*.  Some people want to 
be able to change the color.  Will the default be changed due to that to have 
different colors? Probably not.  So its just that significant portion of 
users (311 votes as I write this) that really want to use your work, but need 
to change the color to actually do so.  How can you argue against that?
We still love you! :)  Thats why there are this many posts on this bug in the 
first place!
Comment 62 Lubos Lunak 2008-03-28 23:41:21 UTC
I don't really care what the solution is as long as it is a solution. If a user has several windows open they should be very quickly able to tell the active window and not analyse them one by one like it's necessary now. Colorisation indeed looks like the simplest way, but if you come up with something else that's acceptable and improves the poor usability of the default look, ok (for example, highlighted widgets in the oxygen style have a blue outline, so maybe the active window could get something similar, which would actually both make it more consistent with the style and avoid many of the current visual problems).

That said, I really wonder why we need to discuss a patch that makes the oxygen windeco to actually follow color settings at least optionally. You probably fail to realize that the oxygen windeco right now is not just some personal toy of yours, but that it is the default KDE window decoration and there comes some responsibility with this. Many users are not even going to change the defaults, so some "if you don't like it, change it" does not hold, it needs to be generally acceptable by default or not to be a default at all.

You think I've really wanted to write all the code I've written because others were asking for it? I find it somewhat ridiculous that you'd prefer a complete fork of the decoration just because of few lines of code. Oxygen is not going to be exactly precisely the way you want it if it's to be the default KDE style, live with that. Besides, you have no full control over this anyway - openSUSE KDE4.0.x packages are soon going to ship with my patch and the option set to colorisation by default (to gather feedback, if nothing else), others may do that too if there is user demand (which it seems there is) and you can do nothing about that. Is it really asking that much to have the default decoration to at least optionally actually follow KDE settings?

#52: Yes, I agree this bugreport mixes problems with the default look and the configurability of it, but as you can see, solving this is in practice closely related.

#56: I think not having a clear distinction between the titlebar and window contents in it is not a big problem here, I wouldn't mind that in the default look if it doesn't pose any practical problems (are there any?). My main concerns are 1) poor visibility of which window is the active one, 2) poor visibility of window borders against windows in the background, 3) no way at all of following the configurability of colors.
Comment 63 Matthew Woehlke 2008-03-29 00:41:28 UTC
> You probably fail to realize that the oxygen windeco right now is not just some personal toy of yours

Welcome to the world of stubborn artists :-). To be honest, I can understand and sympathize with pinheiro's desire to maintain the integrity of his idea (and keep in mind there is a brand at stake here also), but at some point, something has to give, which is either pinheiro will accept that oxygen in it's current state doesn't work, or else there will be a fork that is not called "oxygen".

I much prefer committing the patch and working from there (the option available) to make the 'integrate with WM colors' look actually /nice/, as opposed to tolerable (but still a usability improvement) like it is now.

At this point, I intend to do just that next week. If there is not consensus, well then I'm going to do a fork, so that I can work on it incrementally.

(On an unrelated note, if KDE used git I'd have committed this locally a long time ago :-).)

> I think not having a clear distinction between the titlebar and window contents in it is not a big problem here, I wouldn't mind that in the default look if it doesn't pose any practical problems (are there any?).

Yes (there are practical problems, at least in my experience). I didn't apply the patch because I needed help telling active from inactive (honestly, I've always had trouble with that, even *with* the patch ;-), and with glow, which I used in KDE3). Maybe that's why others use it, but *I* applied it because I was constantly trying to drag windows and hitting the menubar instead of the titlebar, and I found that unacceptable. YMMV :-).

What confuses me about your confusion is that part of the problem is that neither the top nor bottom of the titlebar is obvious, which seems to be the same problem as "poor visibility of window borders against windows in the background".

> no way at all of following the configurability of colors

Honestly, except for the usability problem (can't find the titlebar/borders), I don't see this as a problem, or maybe I should say I disagree that there is a problem here. Hard-coded colors should absolutely be forbidden (in all of KDE, actually, if you ask me ;-)), but the oxygen deco doesn't have hard-coded colors. Following WM colors is nice, but I don't think it should be a requirement for its own sake as long as a deco follows the overall scheme.

If others feel that the *default* deco must use at least a minimum set of the WM colors (for the sake of doing so), I won't object to that. And of course we have arguments (including one from me) why oxygen should follow some WM colors for usability reasons...
Comment 64 premierSullivan 2008-03-29 01:16:21 UTC
Theres a button on KDE that advertises it does something (changes the color of window decorations).  When the user clicks the button, he expects it to do what it advertises.  By default in the current version of KDE, it doesn't, which means that the button is broken.

Why is this under discussion?  Lol...
Comment 65 pinheiro 2008-03-29 01:54:01 UTC
Can we make a compromise ??? never ever have that defoult? not here and not on any distro? It may heven help in usability but it looks terrably bad, (remember usabilaty is also good looks)
I would be ok with the option if I was not totaly sure its the very next step to be defoult some were in some distro, maybe here.
And that would be the end of oxygen as I frist designed it, one slab one cerrent holle. 
So fork please make it defoult if you will but dont brand it Oxygen.

Im not mad or anything, working for so long in kde makes one quite acustumed to this decisions. But you guys have a opinion please let me have mine and respect my work, as I respect yours. respect that having this option in oxygen is totaly contra nature of oxygen and in all my possybble honesty with my creative work i can not alow it.

Imagine it like this, you are an hard c++ coder and some one decides that you should include a patch that is not on by defout in mono. Well some of you might not acept that.
This is a bit what is going on here somthing that as the potential of fundamently vialoate the ground principles of the theme. I'm a bit sad with Matthew couse he knows this very very well and he knows that im not that starburn but I would not budge on this... "remeber slabs and holles"... But im happy he will do the fork he is the right man for the joob.  

Comment 66 Matthew Woehlke 2008-03-29 02:13:17 UTC
> When the user clicks the button, he expects it to do what it advertises.

Actually the WM colors should be hidden when oxygen-deco is being used (and some other WM colors should be *shown* for other decos, which support more colors). That didn't get done for 4.0, hopefully I'll find some time before 4.1 to get to it. (And thanks go to Lubos that the kwin side is basically done, so nobody go blaming him ;-).)

> I would be ok with the option if I was not totaly sure its the very next step to be defoult some were in some distro, maybe here.

You missed Lubos' point, which is, distros are free to pick up the patch (and I think, *will*), regardless of if it gets into trunk. So you might be better off letting us have our way and making it look decent; else distros are going to have http://bugs.kde.org/attachment.cgi?id=24084.

I understand and respect your desire to maintain the integrity of your vision, but I'm worried it will result in no one using the "oxygen windeco", which IMO would be too bad :-(...
Comment 67 xtmccn 2008-03-29 03:12:06 UTC
Though I prefer the unified grey appearance that Oxygen currently offers, I believe the inclusion of this patch would greatly enhance KDE for users who cannot enable compositing. As long as the standard settings remain unchanged, the default look could be preserved while helping Oxygen satisfy a wider spectrum of users.
Comment 68 pinheiro 2008-03-29 09:20:56 UTC
I truly respect your opinion, but you see it will never look good its a impossibility IMHO, if I know and I beleve that, and if I have respect for what we have done I can't alow that a given user his given that as a defoult by some distro and to the user preception the oxygen and kde look.
Remember the "does it blends" comercial? 
Well in this case it dosent. Its a oxygen problem limitation etc. sory.
So yeah if there is a major problem is with oxygen as a holle not just the windeco.
And matthew I dont Agrea with you wen you say that the title bar area is not preceptible enough it might not be on your face type of thing but its clear enough IMHO can be beter but dosent need to be painted pink to do so. 
And also think that for most uzers this active inactive thing is overrated since most users interact with windows with the mouse, and the window you click is allways the active one (note #most users I know not all of them).  
Comment 69 Lubos Lunak 2008-03-30 19:48:30 UTC
Ok, I think I've tried hard enough to be nice about this for enough time and I'm disappointed by the outcome, so I guess it's time for a less popular solution.

I've split off the 'Active window is too difficult to recognize from inactive windows' problem to bug #160117, this bugreport is now purely about the original issue of Oxygen decoration not following configured decoration colors. Please redistribute your votes and CC's or report other problems as separate reports as appropriate.
Comment 70 Lubos Lunak 2008-03-30 20:12:16 UTC
As for solving this specific issue: Configurability of decoration colors has been in KDE for a very long time and as far as I remember all decorations ever shipped with KDE followed them, even the kwmtheme decoration which was actually pixmap-based. I find it unacceptable that a default decoration would not have this possibility, simply because it's the decoration every user will use the first time they run KDE, especially given that the patch implementing this is trivial.

I personally don't consider any of the reasons against very convincing. The 'would not accept Mono patch' is off the mark, using Mono is certainly not a standard KDE feature. Also, 'never will look good', I expect users changing the decoration in some way will actually think rather the opposite.

The only thing I'm willing to accept is not branding such thing as Oxygen, as much as I find that ridiculous. I don't see why users changing the titlebar to e.g. red would think anything else about it than that it is Oxygen with a red titlebar, and don't get me started on the technical parts.

Therefore, if this bugreport is not handled within a reasonable time, say, by the end of the next week, Oxygen will be forked and synced, patch from comment #29 applied and it will be the default KWin decoration. I may also consider using the fork for solving bug #160117 as seen appropriate if it is not resolved acceptably for KDE4.1.

That is my decision as the KWin maintainer. If you think there is something that still needs to be said, say something new instead of repeating what has been already said.
Comment 71 Riccardo Iaconelli 2008-03-30 21:39:51 UTC
Please don't hurry things, there's no need for it.
Personally, I'm trying to experiment to find a solution that works AND looks good. As far as my knowledge goes, pinheiro is doing the same, see also his blog entry for example.
I don't really see why trying to piss off people while everyone here seems collaborative (at least with facts).
I'll post a mockup as soon as I find something that works.
Comment 72 Lubos Lunak 2008-03-30 22:08:36 UTC
You are aware of the fact that this bugreport is now purely about the configurability of colors? I haven't seen any seeming of collaborativity on that issue, asking to fork is certainly not that. The plan is merely to do what has been asked for.
Comment 73 pinheiro 2008-03-30 22:27:41 UTC
Lubus sory if you missundrstod my mono comment. It was a comparison that to me seemed correct, if its not, sory.

Think its great that that patch is not tossed away, in fact I' willig to give my help has I can.

Please undrstand my positon as chief artist of oxygen theme, and boemann as  oxygen style maintainer, to be honest with our work and to the fundamental guidlines we set in the beguining.

Im also sory if I ofended you in any way. Or the remaing people that voted for this bug. 
Comment 74 Lubos Lunak 2008-03-30 23:05:04 UTC
I'm not offended, even though I can't say I like this either. I'm merely trying to resolve a problem that as the KWin maintainer I'm ultimately responsible for. And, speaking of understanding, I think these are things that you should understand:
- This is Free Software, which means you've given people the permission to adjust your work as they see fit, they will do it and they will judge whether it looks good or not. Even more if it is the default, used by many people. Ignoring user feedback like in this case will have only one practical result, making it more complicated and more annoying, nothing else. People will even presumably still call it oxygen, regarding of any rebranding. You win nothing.
- You should be open to the possibility of finding out that even your basic design may have flaws and may need correcting, or simply that it needs to evolve. Evolution takes care of those that don't adapt and evolve, whether they like it or not. It will find a solution for oxygen problems too, so you should try to make sure you like the solution. And I personally don't think that a fork of oxygen that has a different label on it and less problems is a solution you will eventually like.
Comment 75 pinheiro 2008-03-30 23:44:17 UTC
Lubus this is art mostly its has guidlines and I like to belive soul. Its not perfect like nothing is. And its not for ever like nothing is. Its not like im not listening to the bug, I might agrea with some of the coments here, but acepting this would be to create somthing else somthing that is not oxygen.
I will repeat the ground idea is one coerent slab. 
you might disagrea with this idea, and its ok but doing so you dont agrea with oxygen, and that ok 2 but again its not oxygen its somthing else.
I'm obviusly not here to win anything, (if so I have long lost) I'm here couse I love kde and have fun working in kde and love puting my experties at the service of kde.
But like I do for paid works I must have respect for my work, if I dont no one will, this is such a case, if some one missinterperts that new thing for oxygen well, what can I do?
Make that new thing beter? Yes sure I said I would help if you guys want to.
But accepting it as oxygen is a lack of respect for myself and our work!
Comment 76 Laurence 2008-03-31 04:19:57 UTC
What about using a gradient for the titlebar, going from the window-color to the titlebar color? That way, it uses the titlebar-color, people can see which window is the active one, and it still looks like it's part of the complete window. Make the default titlebar-colors to look like you want it, and everybody's happy again.
Comment 77 Riccardo Iaconelli 2008-03-31 07:11:08 UTC
Gradienting the whole window background was a bit my idea too (but with radial gradients), anyways, if I won't come up with any solution, please please please include this patch but do it in an optional way, and turned off by default, so that I can keep my oxygen windeco fully oxygen.
Comment 78 Luciano Montanaro 2008-03-31 10:28:11 UTC
#77: we are talking of the decoration here, not the style. And for a default decoration, having a gradient in the background is not the smartest idea -- resizing a window with a gradient over a network connection with the oxygen theme is much worse than with plastique. The same can be noticed on the local display if the x11 driver does not have good render acceleration, by the way.
Comment 79 Matthew Woehlke 2008-03-31 18:13:07 UTC
@ruphy: please check the patch, it *is* optional, and it *is not* enabled by default.

@Luciano: well, we never claimed oxygen was optimized for low-bandwidth connections :-). That's always going to be a tradeoff between complicated styles and X performance.
Comment 80 Laurence 2008-03-31 18:42:55 UTC
I wasn't talking about (changing the) gradienting (of) the whole window, but just the window decoration...
I also don't think doing those things on the whole window is a good thing. Apart from perfomance issues, it's kde4-only, and may be configured completely differently for other users or on remote machines(with a window in the current x-session): ie will not be good enough, not for the default style anyway. 
Granted, they're not that big a deal, but the default style should be fully functional and workable in all circumstances.
Comment 81 Lubos Lunak 2008-04-09 17:33:30 UTC
SVN commit 795243 by lunakl:

Welcome ... er ... Ozone, the new default KWin decoration, that will
be a fork of the Oxygen decoration with additional features that
the Oxygen developers don't want to have in Oxygen. See README
or #152030 for why they prefer it this way.
CCBUG: 152030



 M  +1 -0      clients/CMakeLists.txt  
 A             clients/ozone (directory)   clients/oxygen#795240
 M  +5 -5      clients/ozone/CMakeLists.txt  
 A             clients/ozone/README  
 M  +5 -2      clients/ozone/oxygen.cpp  
 M  +4 -1      clients/ozone/oxygen.h  
 M  +4 -1      clients/ozone/oxygenbutton.cpp  
 M  +5 -1      clients/ozone/oxygenbutton.h  
 M  +5 -2      clients/ozone/oxygenclient.cpp  
 D             clients/ozone/oxygenclient.desktop  
 M  +4 -1      clients/ozone/oxygenclient.h  
 A             clients/ozone/ozoneclient.desktop  
 M  +1 -1      clients/ozone/snippet.cpp  
 M  +1 -1      kcmkwin/kwindecoration/kwindecoration.cpp  
 M  +1 -1      plugins.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=795243
Comment 82 Lubos Lunak 2008-04-09 17:40:23 UTC
Created attachment 24281 [details]
kwin patch

Just for completeness, this is a fixed patch from comment #29 for the 4.0
branch, also removing any visible strings referring to Oxygen.
Comment 83 Lubos Lunak 2008-04-09 17:41:50 UTC
Reassigning back to oxygen maintainer. As far as I'm concerned, feel free to WONTFIX it now.
Comment 84 Camilla Boemann 2008-04-09 18:09:47 UTC
As previously stated, we don't concider this a bug and now lubos have created another windec that does what is requested
Comment 85 Thibaut Cousin 2008-04-09 22:02:05 UTC
Well, I don't know about the philosophical debate going on here, but I'm happy that finally a solution has been found. Going around windows with the current color behavior was really tiring after a few hours, creating hundreds of little hesitations every day.

Thanks, Lubos. :)
Comment 86 jorge salgueiro 2008-04-23 10:30:37 UTC
 obstinatemen, always keep their fork in the hand...
Comment 87 Iuri Fiedoruk 2008-04-23 14:40:11 UTC
I vote for colors in windeco.
Why?
Consistency for the user.

We do have an option in systemsettings to set the window decoration color, and oxygen simply ignores it.
Now think about a new user tha does not know that oxygen ignores the window title color option, he will go to systemsettings, will see that yes, there is a color set in the window title, confused will try to change it click apply... and nothing happens!
I would go beyond the proposed patch, and make it default to have colors for the sake of the user sanity :-P
Comment 88 jorge salgueiro 2008-04-23 17:08:06 UTC
I vote for no windeco. Windeco is in fact creating a static window... we need a mutant window that changes depending on what has inside... Does your house windows have a colour top?

Windeco is win 3.1... If you want that...  
Comment 89 Eric Stith 2008-04-23 20:35:09 UTC
Just wanted to add one thought.  The notion of a single slab, which is the primary argument against color configurability, is untenable anyway, since the user can configure the opacity of the window decorations, which creates a clear border between the window contents and decoration.  Oxygen has no control over this.  As a result, the whole notion of a single-slab is mute.
Comment 90 pinheiro 2008-04-23 21:06:24 UTC
Eric that is obviusly out of the oxygen scope of intervention, and ofcourse if it was it would not work just on the windec, but in the intire window.
BTW this way I would not mind at all to make the color difrence, by payinting the intire window, and using some hardware aceleration to fade the difrences in and out.
 
Comment 91 Lubos Lunak 2008-04-23 22:26:06 UTC
Sure, why do things the simple way when one can make it so much more complicated? What is the _real_ difference between KWin changing the color using compositing and the style doing it directly?
Comment 92 pinheiro 2008-04-24 00:37:59 UTC
Couse if kwin would rennder a fade in animation of a totaly recolored new window on top of the old one it would give a way beter transition efect, and no fliquering at all.
I hate instant on screen changes. Dont you hate them 2?
Comment 93 Martin Koller 2008-04-24 09:12:13 UTC
On Thursday 24 April 2008, pinheiro wrote:
> I hate instant on
> screen changes. Dont you hate them 2?


No, really, absolutely, no.
I hate fancy fading effects just being there to look fancy.
I want to _work_ with my desktop and not simply look at it because it's 
so fancy.
Comment 94 pinheiro 2008-04-24 10:15:33 UTC
:) Ok can't beat that, I wonder what we have been working on and what for.
yes lets keep on the 80's lets have the best desktop in the world for the 80's
lets not heven think about somthing else its worthless.
Lubus stop working the animations for minimize and so on, we dont need it. O wow, I feal the sounds of disco.

Any way jokes apart, I think its prety obvius it would be a rather fast transition efect like 250 ms or something like that, the cool bonus would be that everthing would look alot more smooth wthout flikering etc. And so the precived quality would be vastly supirior.
(I know we cant have this now. but we should start thinking about it, not just cuting ideas couse we cant have this now, if we dont do it we will never have it, and ence not know if it works or not).
The normal user can't precive te quality of the code just the outcome of that quality, visual polish is a great part off that.
     
Comment 95 Thomas Zander 2008-04-24 11:00:26 UTC
> I know we cant have this now. but we should start thinking about it,
> not just cutting ideas becouse we can't have this now, if we dont do
> it we will never have it, and hence not know if it works or not

This reads like you don't want to fix this in a less-then-optimal way because you feel that this will mean the technical problems will not be fixed.

If that is the case let me point out that this is incorrect.  Those technical issues will be looked into and refusing to provide something that people are asking for is not a smart in an open source setting.
Comment 96 pinheiro 2008-04-24 11:24:56 UTC
Thomas no, that was just my anser, to a "no way" comment i explaind quite well that is not the anser for right now, but having some goals is nice 2.
As for the bug itself. being that the bug is "I cant tell active from inactive". We are working on it, think today a commit into the oxygen windeco will go in to further help there.
As for the "i cant paint my windeco in color" Until we dont see a visual representation of that that dosent break Oxygen, we are going to keep on saying that is cool but that is not Oxygen.  
Comment 97 Lubos Lunak 2008-04-24 12:19:54 UTC
I thought only Americans did lame jokes about disco. Nobody's forcing 80's on anybody, however it looks like some people here are claiming that nobody would like the 80's (and I do like 80's).

Anyway, the "I cant tell active from inactive" bug is bug #160117. This bug is "i cant paint my windeco in color". And, especially given the circumstances, that is (I mean, would be) a valid bug for the default decoration. And this bug has been already fixed, and it will remain so.
Comment 98 pinheiro 2008-04-24 12:37:32 UTC
O but I do like disco :). But you wont be seeing me using flashy tight pants :) .

Any way I agrea with lubus, this bug has been closed. 

In the famous Bee Gees words coloring your windeco is "Stayin Alive". 
Sorry I had to make that comment :P .
Comment 99 Martin Steigerwald 2008-04-24 23:01:38 UTC
Adaptability to different color schemes is important to me. I use pumpkin color scheme in KDE 3 as I do not like the mostly greyish default color scheme of KDE 3. I do like to be able to try different color schemes with Oxygen if possible. Even when a possible pumpkin color schemes is oxygenized before.

Anyway I prefer friendly and warm colors and if I couldn't have that with Oxygen I will likely switch to a different deco. Will see whats there when KDE 4.1 is released and have a look at the current version in Debian Experimental now.
Comment 100 pinheiro 2008-04-25 13:29:55 UTC
Martin oxygen theme is very kcm friendly so pumpking should work very very well, that one of the main reson I opose coloring just the windeco, oxygen was made so the almost any color skeam would work very well.
Comment 101 Martin Steigerwald 2008-04-25 15:05:17 UTC
Am Freitag 25 April 2008 schrieb pinheiro:
> ------- Additional Comments From nuno oxygen-icons org  2008-04-25
> 13:29 ------- Martin oxygen theme is very kcm friendly so pumpking
> should work very very well, that one of the main reson I opose coloring
> just the windeco, oxygen was made so the almost any color skeam would
> work very well.


Nuno, thanks for the information, I will see how it goes. Tried KDE 4.1pre 
experimental packages yesterday but was not yet able to get it t work (to 
login into KDE 4 at all, while with 4.0.2 experimental packages it 
works). I will see how it goes when I have it working again.
Comment 102 Dotan Cohen 2008-08-17 12:54:08 UTC
For all those who want a distinctive BORDER for the active window in the default style, please see this bug:
http://bugs.kde.org/show_bug.cgi?id=169319

It seems that this is the feature most commenters here want, but this bug is not the place for it. Thanks.