On Friday 15 November 2013 07:50:55 Jasper St. Pierre wrote: > Ah, whoops, I read your email wrong. It sounds like you're also in favor of > requiring CSD support from the client. Yep, I'm fine with ensuring that CSD is the required fallback. As said: I don't want to force anybody to SSD :-) > > That said, I'm curious about cases like Nautilus under SSD. Should we hide > the close button, or do anything like that to make it adapt to an SSD > environment? I think that depends on whether the Nautilus developers want to have it integrate in other desktop shells than GNOME Shell. If you consider Nautilus to be a GNOME Shell only solution, then it certainly is not needed to adjust. If you on the other hand want to have Nautilus for as many users as possible I would recommend to adjust to the environment and remove the custom close button. After all it would be quite out of place in an environment where no other window has a close button like that. In an environment like Plasma Active it would certainly break the intended work flow to have such a button. Also for tiling concepts I would say it's better to hide. Also from experience I can tell that at least our users care about having windows behave the same way.
Cheers Martin > > On Fri, Nov 15, 2013 at 7:14 AM, Jasper St. Pierre <jstpie...@mecheye.net>wrote: > > On Fri, Nov 15, 2013 at 6:17 AM, Martin Gräßlin <mgraess...@kde.org>wrote: > >> Hi all, > >> > >> this is a reply to the topic of whether to have information about > >> decorations > >> in the xdg_shell at all (see [1]). Sorry that I don't reply to the right > >> message, had not been subscribed to the list. > >> > >> I want to outline why we in the KDE Plasma team would prefer to have the > >> possibility to tell clients whether to draw decorations or not. In Plasma > >> we > >> have multiple shells and will be able to switch at runtime. From the > >> window > >> manager perspective the main difference is currently the handling of > >> window > >> decorations. Our touch oriented shell doesn't have decorated windows, our > >> netbook shell only has decorated windows for dialogs and our desktop > >> shell has > >> a typical window decorated style, but not enforcing SSD (there are valid > >> use > >> cases like yakuake). > >> > >> This gives us quite some flexibility to adjust at runtime (add keyboard > >> to > >> tablet to get a desktop). An application doesn't need to know what the > >> shell > >> currently looks like. The shell takes care of handling all of that. > >> > >> If we don't have information about whether the window should be decorated > >> or > >> not in the xdg_shell we would need to adjust all applications to know > >> about > >> our various shells. Otherwise a consistent user experience would not be > >> possible. Also it removes all possibilities to take this further in the > >> future. > >> > >> Now I don't want to force SSD to anybody nor do I want to be forced to > >> CSD. > >> Therefore I want to have a very simple spec, which allows the compositor > >> to > >> tell the clients whether they are expected to render decos themselves > >> (enforce > >> CSD, e.g. GNOME Shell), whether the compositor doesn't care, but prefer > >> them > >> to not render themselves (e.g. Plasma Desktop case) or whether the > >> compositor > >> wants the client to not render any handles at all (enforce SSD, Plasma > >> Active > >> case). > >> > >> In addition the client should tell the compositor whether it draws > >> handles or > >> not. So that the SSD-supporting compositor doesn't add a decoration > >> around a > >> CSD client. > >> > >> I think this would be a good solution. It would require clients to > >> support > >> CSD, but also to not render them in shells, which prefer to not have > >> them. > >> Also it doesn't force CSD applications to support it. They could just > >> announce > >> that they do CSD no matter what. > >> > >> Opinions? Would that be acceptable for everybody? > > > > I think the trap that I personally don't want to run into is the case > > where we have a compositor that doesn't support SSD coupled to a client > > that doesn't support CSD. Nobody can draw the decorations, and at this > > point we've engineered the user into a corner. > > > > For me, the debate about window decorations and Wayland is that we need > > *something* to be mandated to be supported. GNOME wants that to be CSD, > > and > > KDE wants that to be SSD. > > > > From the GNOME side, we're heavily using CSD features in our apps [0] > > (such that we'd probably even ignore the Wayland hint to ignore CSD, > > actually), and SSD code in mutter is a large pile of code I would not like > > to maintain, as it's quite complicated, so it's natural for us to want to > > encourage CSD. > > > > I also think that CSD has technical advantages for complex server effects: > > if we simply paint surfaces around the window, if we put the window into > > e.g. Coverflow Alt-Tab, we won't see seams around the window. (And > > personally, I'm of the opinion that any design changes you'd need to make > > to apps to make them usable on a touch device vs. regular device stem far > > beyond the window decorations they use in the end.) > > > > I'm fine with a hint telling apps to not draw decorations, but I'd like to > > mandate that CSD is supported by everything. > > > > [0] > > http://build.gnome.org/ostree/buildmaster/results/tasks/applicationstest/a > > pplicationstest/work-gnome-continuous-x86_64-runtime/screenshot-nautilus.d > > esktop.png > > > > Cheers > > > >> Martin Gräßlin > >> > >> [1] > >> http://lists.freedesktop.org/archives/wayland-devel/2013-November/011980. > >> html > >> > >> _______________________________________________ > >> wayland-devel mailing list > >> wayland-devel@lists.freedesktop.org > >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > -- > > > > Jasper
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
