On Thu, Mar 5, 2015 at 10:37 AM, Olivier Fourdan <[email protected]> wrote:
> +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 <[email protected]> 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...). > Hi, GTK+ should not try to detect the DE it is running under. It should check for the _GTK_FRAME_EXTENTS protocol in _NET_SUPPORTED on the root window. > > 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 <[email protected]> wrote: > >> Hi; > >> > >> On 5 March 2015 at 17:51, Olivier Fourdan <[email protected]> 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 > [email protected] > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- Jasper
_______________________________________________ gtk-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtk-devel-list
