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

List:       kwin
Subject:    Re: making oxygen stylish when possible
From:       "Lucas Murray" <lmurray () undefinedfire ! com>
Date:       2009-01-14 4:56:17
Message-ID: f09827650901132056i40248878u1da7249a9f36f750 () mail ! gmail ! com
[Download RAW message or body]

It seems a lot has happened over the night both on the list and off so
I can't tell what's current and what's outdated information. Apologies
if I get mixed up in my replies.

On Wed, Jan 14, 2009 at 1:50 AM, Aaron J. Seigo <aseigo@kde.org> wrote:
> On Tuesday 13 January 2009, Lucas Murray wrote:
>> On Tue, Jan 13, 2009 at 8:09 PM, Martin Gräßlin
>> > I think that should be configurable. I have shadow effect enabled,
>> > nevertheless I want to have the stripes, because I am using two screens
>> > and on both screens there is most of the time a maximized window. So
>> > there are no shadows and I need the stripes again to see which one is the
>> > active.
>> >
>> > But configuration option would imply new strings and that makes it a 4.2
>> > impossible :-/
>
>> I too agree with this, configuration is a requirement for the shadow +
>> stripe mixing and so cannot be added to 4.2.
>
> what? no, this is already possible with the patch.

I completely forgot that there was a patch so I never looked at it.
Looking at the latest one I can find I still agree with my original
decision. If you want to add the feature either of these two
requirements MUST be met for usability purposes:

1) A description is added to the user knows WHY his stripes are disappearing, or
2) A combo box that has a list of all three options (Preferred).

As both require string changes there is no way this can be added to
4.2, I'm not barring it from 4.3 though.

>> Even in 4.3 I don't think
>> it's a good thing to disable the stripes when shadows are enabled, I
>
> just to repeat myself ; ) : please let the art team do their job. the best way
> to chase off our art team, who are getting us lots of praise from users btw,
> is to overrule their designs based on our hacker's eyes. it is immenseley
> frustrating for them and tend sot result in poorer results it the end for our
> users.

Just because a developer is not in the art team or the usability team
does not mean that they know nothing about those subjects. I used to
work as a website developer and I was required to study usability for
the entire time, I know what's usable and your/the art team's changes
are not. If the above condition is met I have no problems with it
being added but until then it's a strict "no" from me. I don't care
how it looks, I just don't want it to be confusing to users and be
completely customizable.

> to put it in another light: those stripes would *never* ship on a Mac OS
> release. they are, to be perfectly blunt, ugly as sin if one uses the Mac
> standards to measure by. they are useful in particular cases, but ugly.

I do not find the stripes "ugly" in any way--they are not a part of
the Oxygen design goal but that does not make them ugly, they don't
even look out of place.

> now, another way to make people happy would be to make the stripes *pretty*,
> or use something other than stripes that doesn't mess up the "solid window"
> look. personally i think that if we really tried we could do something nice
> with the buttons, but it's a bit too late for 4.2 for that.
>
> regardless, the artist vision for this is and was no stripes in the title for
> a solid window look and using shadows and window edge highlighting to
> determine the active window.
>
> we should be true to that.
>
>> think it would be better to just do it manually as there was an option
>> to disable automatically it will mean there are two checkboxes in the
>> settings for the stripes instead of just one. Two options that pretty
>> much do the same thing? No thanks.
>
> fortuantely that's all unecessary. see my second patch, it's all handled
> automagically, without 2 checkboxes, without any new strings, etc.

Looking at the patch I see it doesn't take into account that just
because the shadow effect is loaded does not mean that there is a
shadow applied to a decorated window (See "force" options in the
effect configuration). Also keep in mind that there might be more than
one shadow effect enabled at any one time. I would like to in the
future add "ambilight" shadows (I think it was called) which would be
enabled simultaneously as the current shadow effect and they would
work together to determine which one applies the shadow to the window
(Using custom hints maybe, or just use the window title string with a
white/blacklist).

The best way to take this into account is to have an
effects->displayingShadows( EffectWindow* ) effects call that the
effect will call when the window is added then have a decoration call
to determine whether this flag has been set to the client or not. This
is very shadow-specific code but along with window opacity they are
both exceptions to the rule due to the way the effects system was
added in KWin.

With all that being said decoration-specific shadows in 4.3 will be
painted with the rest of the decoration due to the introduction of
ARGB, meaning everything I mentioned in the previous two paragraphs
would be scrapped. It will be easier to add your feature as you will
have all your required data already there (Through internal Oxygen
calls), if an effect wants to disable the custom shadow it will do so
with an effect API call, otherwise it's already enabled when
compositing is used (Or however the decoration wants it to be used).
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin

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