Re: GTK+, WM, desktops and CSD

[Olivier Fourdan <fourdan gmail com>]

+gtk-devel-list

Argh sorry, I didn't mean to make that email private,  thought my
mailer would copy the list as well, my bad :(

On 5 March 2015 at 19:29, Olivier Fourdan <fourdan gmail com> wrote:
> Emmanuele,
>
> Let's face it, I doubt GTK+ will ever dominate the world, so the "it's
> not consistent because we're not using a single toolkit" is not going
> to be solved overnight. And frankly, as much as I like GTK+, I do not
> wish other toolkits to go away either, so we shall have to deal with
> heterogeneous toolkits for any foreseeable future.
>
> GTK already check for a compositor and detecting the DE to adapt is
> really not a good approach, it doesn't scale, and worse it ends up
> being really confusing (I can't remember which famous app was doing
> that, but I do remember that we ended up pretending to be gnome in the
> session just so it would work reliably...).
>
> As I wrote, the final word would remain the to apps, just like now,
> all I'm proposing is to replace the decision made by GTK to use CSD
> based on a compositor with a hint from the DE instead, nothing more.
>
> Cheers,
> Olivier
>
>
> On 5 March 2015 at 19:18, Emmanuele Bassi <ebassi gmail com> wrote:
> > Hi;
> >
> > On 5 March 2015 at 17:51, Olivier Fourdan <fourdan gmail com> wrote:
> >
> > > I am not one of them, but there are a lot of people (including KDE
> > > devs apparently) concerned about CSD because it means different
> > > decorations depending on the apps/toolkit => Consistency might suffer.
> >
> > I don't strictly buy the "consistency" argument at all.
> >
> > Right now, on my desktop, I have open two different browsers — Firefox
> > and Chrome — that do not look like anything on my desktop. I also have
> > an office suite using its own toolkit which passes a slight
> > resemblance to GTK, if I squint my eyes and tilt my head a bit. If I
> > were so inclined, I could be probably running some non-GTK
> > applications, and those would look fairly different.
> >
> > There's no consistency because we're not running a platform with a
> > single toolkit.
> >
> > If you're referring to the window controls, you can specify them even
> > for GTK windows using client-side decorations; it's a setting that can
> > be changed to reflect your environment — that's why both server-side
> > and client-side decorated GTK windows have the same buttons.
> >
> > > I think it's very little change in GTK+ as it's already able to do
> > > both SSD and CSD (currently, decision to use CSD or SSD being made at
> > > run time based on the availability of a compositor).
> >
> > That's not entirely correct. The decision to use client-side
> > decorations is up to the application developers, not to the toolkit.
> > An application developer may decide to support both the UIs, and opt
> > for client-side decorations if they detect that the application is
> > running under GNOME, but the toolkit is only tangentially involved.
> > The only place where GTK decides to use an header bar or not is for
> > the dialog windows it creates — file selection dialogs, print dialogs,
> > color selection dialogs, etc. Those are under the control of the
> > toolkit, so the toolkit can make a decision. The UI of an application,
> > on the other hand, is the remit of its developer. The toolkit cannot
> > really move widgets around, because it's missing context to do so. If
> > I use a GtkHeaderBar with a button at the top left, and the
> > environment does not support CSD properly, where should the toolkit
> > put that button? Keep the header bar, but still have decorations on
> > top, thus replicating things like titles?
> >
> > Your proposal for an hint could be simply solved with a check on
> > whether the screen is composited (which is already available) and/or a
> > check on the desktop environment. Sure, we can add a freedesktop.org
> > spec that tells us if the application is running under GNOME, KDE,
> > XFCE, or whatever. Obviously, it all breaks apart as soon as "choice"
> > is factored in — if somebody is running under KDE with KWin without
> > compositing, what would the environment be? Same with XFCE running
> > with another window manager. Let's ignore that for a minute, though,
> > and figure out the issues of such a hint.
> >
> >  • How does that hint get specified? Is it an X11 property on the root window?
> >  • How does it get monitored? What happens if the user changes the
> > setting at run time? Do we get a client message?
> >  • How are applications supposed to react when that setting is found,
> > or when it changes? Do they ship with two different UIs, one for CSD
> > and one for SSD?
> >  • What happens if the application does not have two UIs? Is the
> > setting ignored, and the application stays with client-side
> > decorations even if the window manager does not support the Motif WM
> > hints?
> >
> > At the end of the day, though, if the application developer decides to
> > use a GtkHeaderBar and client-side decorations, it's the application
> > developer's prerogative to have their wish obeyed.
> >
> > Ciao,
> >  Emmanuele.
> >
> > --
> > https://www.bassi.io
> > [ ] ebassi [ gmail com]