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

List:       kwin
Subject:    Re: New Shadow System
From:       Martin =?iso-8859-15?q?Gr=E4=DFlin?= <kde () martin-graesslin ! com>
Date:       2011-02-04 16:39:35
Message-ID: 201102041739.42948.kde () martin-graesslin ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 04 February 2011 16:08:49 Fredrik Höglund wrote:
> On Friday 04 February 2011, Hugo Pereira Da Costa wrote:
> > On Friday 04 February 2011 14:41:27 Fredrik Höglund wrote:
> > > On Tuesday 01 February 2011, Hugo Pereira Da Costa wrote:
> > > > I think the plan is to have the *decoration* not the *style* set the
> > > > shadows. I think that answers all your questions above at once.
> > > 
> > > If the decoration provides the shadows you don't need this new hint
> > > at at all. It doesn't make sense for KWin to use X properties to
> > > communicate with itself.
> > 
> > Well, on the other hand it does not make sense for the style to provide
> > shadows for the decorations. So I'm a bit at a loss here, I must say.
> > 
> > (and in fact, to some extend it does not make much sense either for the
> > style to write anything on the root window either: should this be
> > done/overwritten for every new app you start ?, including kwin itself,
> > actually)
> 
> No, because the application that was started last will define the shadows
> for all other applications. This is undesirable when you consider what
> happens when you start an application that uses a different toolkit.
> 
> For this scheme to work, the desktop must provide a shadow daemon.
> But if a single application is to define the shadows for all other
> applications, we're back to the question of why that application shouldn't
> be the compositing manager.
> 
> If you'd rather have each application define the shadows for its own
> (undecorated) windows, then the most efficient way to do that is to
> enlarge the windows to accomodate the shadows.
> 
> At any rate, the only scenario where it's desireable to use a shared
> X property is the scenario where you have a shadow daemon, and this
> daemon isn't the compositing manager.
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.

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

Somehow the shadow system is way more complex than expected :-)

Cheers
Martin

["signature.asc" (application/pgp-signature)]

_______________________________________________
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]