On Friday 04 February 2011, Martin Gräßlin wrote:
> My idea was going into the direction that the shadow is set on first time the 
> KStyle loads (probably during startkde) and updated by whatever UI is used to 
> change the shadow config.

The problem with this is that the style knows only that it's been
instantiated, not why. Without knowing if it happened in response
to a global style change it has no way of knowing if it should replace
the property if it's already been set.

Also if you switch from a style that supports the shadow hint to one
that doesn't, the desktop will continue to use the shadows defined by
the previous style since the root window property won't be unset.

If the desktop style doesn't support the hint, and the user starts
an application that uses a different style that does support it,
then suddenly all windows will get the shadows defined by the
style in that one application that stands out.

> Having a shadow daemon sounds like overkill for the situation and yes setting 
> properties for the decorated windows is kind of useless.

I think it's considered bad form to have root window properties that aren't
owned by anyone, since there is no way to know if they are valid or not.

Typically the the owner of a shared resource would set the property on a
window it has created (but not necessarily mapped), and use a manager
selection to negotiate ownership of the resource.
 
> Somehow the shadow system is way more complex than expected :-)

Yes, it definitely doesn't adhere to the KISS principle.

Regards,
Fredrik

_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin