situation with window decorations
Matthew Woehlke
mw_triad at users.sourceforge.net
Tue Sep 8 20:05:39 BST 2009
Hugo Pereira Da Costa wrote:
> Matthew Woehlke wrote:
>> Hugo Pereira Da Costa wrote:
>>> in the meanwhile I've been working on coding Thomas idea for an ozone
>>> active window blue frame replacement
>>> (http://lists.kde.org/?l=kde-core-devel&m=125148666615682&q=p3)
>>> in my private version of the Nitrogen windeco.
>>>
>>> I put a bunch of screenshots here (with left/right and center title
>>> alignment, as well as with normal/tiny/no frame border).
>>> http://www.flickr.com/photos/42123798@N03/
>>> Comments would be highly appreciated.
>>
>>> You'll note that the original "radial" glow from Thomas is gone
>>
>> Do you mean on the colored portion of the title bar? I think of
>> "radial glow" as the thing that is done to the root window (style as
>> well as decoration), which needs to stay or else the title bar won't
>> blend with the window contents.
> No I meant the gradients (dark on the edge, light on the center) inside
> the blue title box.
> I kept the radial gradient of the title bar, and actually used the same
> one for the blue title box. Does that make sense ?
I think so. Dropping it for the blue part is fine with me.
>> Well... it's upside-down. The idea was that this part should be
>> *inset*, not raised, as if the window was made of two materials, one
>> (on the bottom) colored and one not (well, window colored). What we
>> have instead looks like an optical illusion.
>>
>> I like to think of it as a piece of ceramic; the clay is
>> window-colored, and the bottom half has been dipped in
>> decoration-colored glaze (that magically gets onto anything below
>> "window face" level). I find this much more consistent with my
>> impression of Nuno's vision.
> mmm, I'm confused. Most of oxygen pops out rather than sink in.
Well, not entirely, views are sunken. Mostly the idea of the window
frame being higher than everything else doesn't feel right to me. Oh,
and it's consistent with how the "scratches" were done.
Also... why *active* window? I had expected this would apply to *all*
windows, using the appropriate deco color. Otherwise it's like
adding/removing elements when the window changes states. (Come to think
of it, that's another reason I think the scratches were odd...)
That reminds me, can I ask for an option (or even just do it outright)
to not change the WM buttons on inactive windows?
One more thing I am noticing now that I have it running on my machine;
the window title text needs to be centered vertically in the inset space
(or at minimum, moved up 1-2px, maybe pick whichever is less from the
frame size). And is it me or has this made the title bar taller? It
would be best to avoid doing that if possible.
(I should note that my build is broken since Friday, so if any of the
above is changed since then, I wouldn't notice...)
>> Also the top corners need to be rounded :-).
> You mean, the top corners on both sides of the title 'tab' ?
Yes. ASCII-art illustration of the outline between deco color and window
color ('X' and 'O' are application icon and all-desktops button):
______ __________
/ \ /
| X O | Window Title |
| \______________/
> or in the corners of the window ? or both ?
The window corners are already rounded, are they not? (Or do you mean
because you are using 5px wide colored edge instead of the 2px? Btw,
stop that ;-). Otherwise those should be rounded also, but I'd make the
colored edge 2-3px, it looks better IMO. IOW don't change how the rest
of the edges are drawn for the 'title highlight'.)
>> The one thing I *don't* like is the entire frame being colored. I
>> prefer the current state, which is just the outer edge colored. Again
>> this goes with the concept of the bottom part being a different color.
>>
>> For larger border sizes I think it would be awesome to have a two-step
>> edge, like this (think of this as side cross-section):
>>
>> window color --> /------- [ · · · face of window · · · ]
>> /-----|
>> decoration color --> |
>>
> If I get it right, this is already the case when the border is >= Large
Not quite, it is missing the second lip (except at the top)... which IMO
should be there regardless if it is raised or sunken.
> (and for 'normal' size there is really not that much room: 4 pixels)
Right, for normal size, you kind-of fudge (read: ignore) the inner lip
and soften the transition from deco color to window color.
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Q: Why doesn't Fedora provides ponies? -- Benny Amorsen
A: Because they're too big to fit in the bikeshed. -- Mat Booth
More information about the kde-core-devel
mailing list