+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]
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list