Re: GTK+, WM, desktops and CSD

Ah, I think I see the disagreement.

We don't decide between SSD and CSD based on the presence of a compositor and _GTK_FRAME_EXTENTS, we instead push really hard for CSD with an SSD fallback.

It's a subtle difference, but it shows our preference: we don't want a hint to say that the DE prefers SSD, we want a hint to say that the DE can support/not support CSD.

If you want to help improve CSD fallbacks to behave better when we don't have a compositor, that would be great! But ultimately, SSD does not lead to the types of applications and the types of experiences we want to create, so a hint asking us to prefer to use SSD that we would realistically mostly ignore isn't particularly useful.

On Thu, Mar 5, 2015 at 12:29 PM, Olivier Fourdan <fourdan gmail com> wrote:

On 5 March 2015 at 20:09, Emmanuele Bassi <ebassi gmail com> wrote:
>>> On 5 March 2015 at 19:17, Florian Müllner <fmuellner gnome org> wrote:
>>>> What about apps that rely on CSD for part of their UI? Will those have the
>>>> final word as well, or are they just screwed?
>>> The same as now without a compositor :)
> a) X11 without a compositor is a deeply uninteresting case; I'd go as
> far as saying that if you're running X11 without a compositor you're
> basically asking for a broken system

I am not sure I am following you here, but people do run WM without a
compositor, it is a reality.

And GTK supports that, at least up until now, and that's fine by me.

> b) not having a compositor is not at all equivalent to changing a UI
> from a CSD to a SSD scenario. The UI *changes*, even in drastic ways
> for the user interaction. The application has to be informed about it,
> and has to be designed with those two cases in mind. It has to ship
> with two fairly different sets of UIs. It already happens for menus,
> but you'll have to convince application developers to ship those two
> UIs, maintain them, and keep them from going out of sync. Your idea
> stops at providing a patch for a hint. You're vastly underestimating
> the effort that such hint entails on the larger ecosystem.

But it's already the case, I am not advocating to reinvent the entire
ecosystem of UI interactions here, I am merely asking if a setting to
help GTK decide to go CSD or SSD instead of just detecting the
presence of the compositor alone would be interesting...

gtk-devel-list mailing list
gtk-devel-list gnome org


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]