Re: Proposal for a Shadow extension

[Owen Taylor <otaylor redhat com>]

I guess I don't quite understand this proposal. Obviously, to get an
optimally consistent desktop, the toolkit theme, the manner in which
window decorations are drawn, and the window shadows all have to be
designed together, but the consistency between the window contents and
the shadow for a window doesn't seem like the most interesting part of
that.

And in fact, it seems like the worst possible thing would be to have
different windows on the desktop with different shadow lighting.

>From the GNOME perspective, we see the shadows as something that the
window manager controls ... because we do want consistency between all
the different windows. We actually use a different, larger shadow for
the active window - so it would be confusing to the user if that hint
varied.

Do you really want different windows to have different shadows? If not,
then why don't you just configure the shadows in KWin to match the
widget theme you expect?

There are some questions that are on my mind about shadows and the
compositor / client interaction:

 - Is there some way for a client to explicitly disable the shadow for
   an overrride-redirect window instead of just the hints given by
   _NET_WM_WINDOW_TYPE.

 - How to handle the shadows for ARGB windows that are shaped with
   transparency? - how do you distinguish ARGB for shape vs. ARGB
   for for translucency? Do you just use the input shape?

 - How do you handle the shadow for windows that have translucent
   areas like a transparent terminal? (A shadow that is drawn only
   outside the outer bounds of the window looks pretty good even
   if is physically unrealistic.)

 - How are shadows handled with respect to client-side decorations if
   we are moving in that direction? Do we do the shadow as part of the
   client pixmap or separately? If part of the client pixmap, how does
   the window manager communicate the desired (focuse/unfocused) shadow
    to the client?

Having the client pass pre-rendered shadows to the compositor just
doesn't seem relevant to anything we want to do in GNOME.

- Owen

On Sun, 2011-05-08 at 10:32 +0200, Martin Gräßlin wrote:
> Hi all,
> 
> at KDE we designed a new system to allow clients to specify the shadow to be rendered by 
> the compositor. It is our belief that only the client can know how the shadow has to look like 
> (e.g. consistent light model). We think that this system is not only useful for KDE, but for all 
> compositors/Desktop Shells and therefore I propose it here as an idea for addition to the 
> NetWM spec.
> 
> The general idea of our system is that the client specifies a hint and passes eight pixmap ids 
> (four corners and four sides) and the offset in all directions to the compositor through the 
> hint. The compositor then can decide to render the shadow based on the hint. A full 
> description can be found in [1].
> 
> We currently have three parties implementing the system: 
> * Oxygen Qt style
> * Oxygen GTK style
> * Plasma Desktop Shell
> 
> And there has already been further interest by other application with a custom style such as 
> Yakuake. For such applications it would be of most interest to have a cross-desktop solution. 
> [2]
> 
> If there is interest in such a system in a standardized way, I would draft an addition to the 
> NetWM spec. Of course we are willing to change the code and have not yet added new 
> methods to our public API in order to be able to integrate feedback from the broader 
> community.
> 
> Kind Regards
> 
> Martin Gräßlin
> KWin Maintainer
> 
> [1]: http://community.kde.org/KWin/Shadow
> [2]: Yes I know that this would improve CSD and that this sounds like being a hypocrite. But I 
> prefer having a proper system instead of clients starting to extend their window size to get 
> custom drop shadows and causing major breakage.
> _______________________________________________ wm-spec-list mailing list wm-spec-list gnome org http://mail.gnome.org/mailman/listinfo/wm-spec-list