[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: situation with window decorations
From:       Hugo Pereira Da Costa <hugo.pereira () free ! fr>
Date:       2009-09-02 0:25:25
Message-ID: 4A9DBB75.1040505 () free ! fr
[Download RAW message or body]

Hi Mattew,

> Hugo Pereira Da Costa wrote:
>> - I agree that having nitrogen into kde (as opposed to kde-look) put 
>> more requirement in terms of clarity of the options, simplicity of 
>> the configuration, and matching with the rest of the work. Open for 
>> suggestions.
>
> kde-usability is a good place to ask for UI design advice. Though I 
> see trunk is much better now than last week.

I agree with the kde-usability. In fact sending a long email there is on 
my todo lists. The issues I have:
- tabs (for the configuration) is not the best thing inside an already 
tabbed widget (for picking decoration and handling buttons)
- size-grip is a bit geek of a term.


>
> One thing I would still change; instead of "Exceptions", 
> "Window-Specific Settings" or "Window-Specific Overrides". I think 
> that would be more meaningful to end users.
That's a good one. Will do.
In fact "basic" and "advanced" also look a bit "dry" to me for a tab 
title. Any suggestion ?
>
> Oh, and I can't seem to set 'blend with window contents' as an 
> exception. If I check it, it doesn't apply, and is unchecked when I 
> re-edit the exception.
ok. That's a bug. I can reproduce. Will fix and commit _now_.

>
> Speaking of exceptions, is it possible to add exceptions based on the 
> window's host (i.e. remote X)? Ideally, even based on what user owns 
> the window? (So I can have a rule 'host matches "foo" and user matches 
> "bar" and window class matches "baz"'...) That, plus ability to change 
> the colors in an exception would let me make much more pretty windows 
> for stuff I frequently run remotely and/or as a different user.
>
>> In fact: bespin has a size grip too; some user on kde-look commented 
>> that they _really_ liked the "no-border + size grip" option;
>
> Ah, with no border I can see why you would want a (different) size 
> grip. Note that the Oxygen border already /has/ a size grip...
Yep. Thats correct. In fact, i have this plan in mind: (comments welcome).
Instead of having a "draw size-grip: yes/no ?" I'd like a "draw 
size-grip: yes/no/when needed", "when needed" being the default, an 
meaning: the size grip is automatically drawn for windows with no 
border, and no border only.

Now one might even want to remove this option entirely (provided the 
"when needed" behavior). But some applications (like firefox, or 
quassel) already provide a size grip. So that at least in the 
exceptions, (sorry: the " Window-Specific Settings" ;-)), you want the 
ability to turn off the one from nitrogen.

Does that make sense ? Any comment ?

>
>> - scratch line: no preference whether one should keep the option or 
>> not, but if we don't, I'd rather have the default be 'no scratch 
>> line' (notably because scratch lines and large buttons don't fit well 
>> together).
>
> Yes, please don't force scratches on us ;-).
>
>> - blue glow for active window. I don't like it (personally), although 
>> I understand the purpose. I'd be inclined to keep the option.
>
> Well it's Active Window Titlebar-colored, yes? ;-) But it needs to 
> stay, either as an option, or always-on, or we're back to why Ozone 
> got forked in the first place...
>
Some confusion here (I think): the glow is the colored _shadow_ in 
composite mode. It is in _oxygen_ without the title-bar coloring of 
ozone. In oxygen it is on by default (Intended I think as a compromize 
to ozone full painting, and I was asked multiple time on kde look to at 
least make an option to disable it.
I think, to some extend, it should be kept independent from the title 
bar coloring.
>> - title bar color: I have no opinion. I always used the 'window 
>> content' colors, so that I would have no objections against removing 
>> the option, but as far as I understand, a large number of people ask 
>> for it ...
>
> Actually, I think I would like to use it with non-Qt applications 
> (since those won't blend correctly anyway). For Qt applications it is 
> more ugly... IMHO ;-).
>

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]