On Monday 16 May 2011 12:07:09 you wrote: > 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. full agree and we actually achieved that with this shadow hint :-) Let me explain a little bit: the new shadow system was designed and implemented in a collaborative effort between the developers of the Oxygen toolkit theme (I cc'ed Hugo in case he wants to add further info) with feedback from other toolkit theme developers and the KWin team. In KDE Plasma the complete look'n'feel is implemented by Oxygen. They provide the Qt and GTK toolkit theme, the window decorations theme and the shadow. In case of decorated windows the shadow is actually part of the window decoration. This means we only use the new shadow system for undecorated windows like comboboxes and menus. > > And in fact, it seems like the worst possible thing would be to have > different windows on the desktop with different shadow lighting. Agreed but unlikely to happen as the shadow hint is being set by the toolkit theme. > > 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. We do the same but think that it is not the task of the window manager to define the look'n'feel. This is the task of the primary toolkit theme. So we absolutely want the same, but tackle it from a different perspective. More to that on your next question. > > 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 various reasons: * That's what we did till 4.6 and as you can see it didn't really work out or we would not have changed it ;-) * There is not the "one shadow to rule them all". We experienced that windows have different shapes with different toolkits. Even with the same toolkit windows can have different shapes. A prominent example is Firefox not allowing round corners. With the new system we are able to provide a specially adjusted shadow for the square corners of Firefox. * We do not want to force users to a window manager. If we implement the default shadow in KWin, users would no longer be able to switch the window manager without losing functionality. That's the reason why I brought the issue to this list for discussion at all and also why we included Sam from Compiz in our internal discussions before we even started to implement it * Our desktop shell wants to provide custom shadows. The shadows are part of the desktop shell theme and generic shadows do not fit at all * We still want to allow users to change the widget style, decoration style or anything other theme element. We don't want to force them to use a specific widget style or window manager to get shadows. With the provided system each combination of style and decoration (which is common in case of KDE: e.g. Oxygen, Bespin, QtCurve) can implement their own matching shadow. * We have requests from special windows like Yakuake which want to provide custom shadows. * Probably many more things I just forgot :-) We have evaluated the options quite long and discussed various implementation approaches. > > 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. As the window has to opt-in by setting the shadow property, I think this is a no-issue. > > - 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? Here we come to the point why we implemented it that way: by allowing the window itself to specify the shadow we don't run into any issues with ARGB windows. Only the window knows it shape and therefore it has to define the shadow so that it matches. > > - 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.) Same as above: if the window provides the shadow, there is no problem. In fact for translucent terminals we do not use these shadows as those are decorated and get the decoration shadow. With the very old system (KDE < 4.3) we had exactly the issue you just described. > > - How are shadows handled with respect to client-side decorations if > we are moving in that direction? KDE won't ever move in the direction of CSD. In fact I'm currently evaluating how to force Chromium to get normal decorations. (Yes even with Wayland we will stick to decorations!) > 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? As we currently only use the shadow hint for undecorated windows there was no need for us to implement it. I think it is a non-issue to just add a second hint for the activated window. > > Having the client pass pre-rendered shadows to the compositor just > doesn't seem relevant to anything we want to do in GNOME. which is totally fine. I think there is no window manager implementing everything of EWMH ;-) Nevertheless I think after this mail you might reconsider. Just see it as some feedback from someone having worked on shadow issues for three years now :-) Cheers Martin > > - 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 > >
Attachment:
signature.asc
Description: This is a digitally signed message part.