Shared publicly  - 
ah right, GTK+ cannot fix integration bugs because they would look "unpolished" when gnome shell crashes and it would make from GTK+ developer view "our own stuff look worse".

Thanks that we clarified what GTK is for :-( No wonder that non-GNOME desktop environments port to Qt and non-GNOME applications port to Qt.
Arjun AK's profile photoJulius Schwartzenberg's profile photoMikhail Krutov's profile photoAndreas Sturmlechner's profile photo
GNOME and GTK are more lost than an octopus in a garage.

It's a Spanish expression.
+Julius Schwartzenberg Recently a rather high profile application for music, cough #audacious  *cough,*  dropped from GTK3 to GTK2 in the move to QT. That event ignited another round of wait, how many people are leaving GTK? 

The list of other applications dropping GTK and going to QT is getting pretty long in and of itself... neverminding the rather damning comments from not just +Valve developers, but other downstream groups publishing through +Steam as well, on just how atrocious the Gnome/GTK clique has gotten. Then there is the whole mess with #clientsidedecorations  which more and more actual end-user developers are discovering is an entire list of problems in and of itself...
You cannot post something like that without a link!
+Martin Gräßlin you're being disingenuous at best.

an application crashing in any environment is bad, regardless of the environment. if I say that GTK+ is portable, but it crashes in MacOS, Windows, and Wayland, then you'd be right in saying that GTK+ is not portable at all. an application crashing is an application that does not work.

since GNOME developers are the core contributors to GTK+, and since GTK+ is the core platform of GNOME, and since GTK+ is an open source project driven by its contributors, then it's perfectly legitimate to say that the core contributors to GTK+ have all the vested interest in the worl in making sure that GTK+ does not look like ass in GNOME.

I know this is a different situation than Qt and KDE; Qt caters to a thousand different platforms, and KDE is just a consumer of that platform; nevertheless, Qt is driven by whosoever can invest engineering resources to get the best support on their platform. GTK+ is in a similar situation, except that the people investing engineering support are the GNOME developers. not MacOS developer, not Windows developers, and not KDE developers.

+Je Saist it's funny you say that, because Steam is actually using client-side decorations on Linux. crazy, right?
Well, it's really a self-fulfilling prophecy. GTK+2 was promoted as cross-platform toolkit, GTK+3 is "the toolkit for GNOME". This internal focus manifests itself in portability problems, and in features bit-rotting without much care. The episodes around the theming APIs constantly breaking and similar stories breaking are just getting worse, and that might well be the result of not caring enough for all non-GNOME platforms. We can observe a positive feedback loop here, where developers that expect their apps to also work outside of a GNOME desktop are getting so frustrated with the current situation, they're just running away, often to Qt which delivers on the platform promise.

In Qt, it's not just "whoever can invest in such platforms", there's also a strong culture to actually care for cross-platform compatibility. KDE has merged a ton of code into Qt in the past two years with the transition to Frameworks 5. That has not resulted in Qt sucking on other platforms, however, it results in new features that work also on other platforms in Qt. That's not a random coincidence, it's the result of caring also for other than your own target platform, and of simply not allowing in code that breaks elsewhere (cowboy implementations of CSD, to name a popular example).

A user-visible result is that in many cases that Qt applications integrate well in a range of platforms, GNOME, Plasma, Mac OS, Windows. GTK apps look great on GNOME3 and look like ass everywhere else. This is not a surprising outcome at all of defining GTK+ as the GNOME toolkit.

Most importantly, making sure other platform implementations don't break is a matter of respect to your users.
+Sebastian Kügler stop spreading memes: the "themeing API" has not, has never, and does not break. it's stable, and part of our API contract. what changed are the CSS style classes applied to widgets, which were never declared API, or stable; it means that themes have to keep up with new widgets and with how widgets draw themselves. those changes have been made in response to bugs in the themes, not because we like to change how widgets want to draw themselves. luckily, now that we have mostly migrated all GTK+ widgets to be drawable through CSS (with some holdouts that we have to keep because we're API stable), we can settle down, and avoid further changes. now that we have a decent theme inside GTK+ itself we also can guarantee a degree of API stability in theme colors, so third party themes can actually depend the internal theme and assets.

as to making sure GTK+ does not suck on other platforms: we don't have resources to ensure stuff does not break. it would be awesome if we did. it would be great if people turned up and fixed backends outside of X11 and Wayland. turns out that if you don't pay people to do that, people don't do that out of the goodness of their hearts. we've been through this with DirectFB, with all work trickling down upstream (if ever) after some company needed a DirectFB-based GTK product. Qt is lucky: it has engineering resources for MacOS, Windows, and whatever platform it supports. good for you, guys. I'm happy. we get app developers that want to ship their apps to Windows, but don't have time/resources/knowledge to fix the backends to actually work, or even keep up with the internals changing.

you want to ensure GTK+ works on Windows? or even on KDE? show up, contribute patches, run a continuous integration build. even replying on mailing lists when we propose protocol extensions to make sure that our toolkit features integrate in your platform is welcome — which is something that apparently does not happen.

so, yes: GTK+ is the GNOME toolkit, because GTK+ is the core of the GNOME platform. you can use GTK+ on other platforms, and we'd love to get contributions for improving that. shockingly, that does not make those contributions magically appear our of nowhere, so we keep ensuring that the toolkit works best in the one platform that has a vested interest in making sure that GTK+ works.
Markus S.
I find it funny how +Emmanuele Bassi demands that people from other DEs contribute to GTK. KDE develops a GTK theme to make GTK apps integrate well into a Plasma workspace. Where is an official Qt Adwaita theme? Not only isn't there any attempt to make Gnome apps work well under other DEs, no by forcing CSDs into the apps, Gnome apps work less and less well anywhere else.
KDE also makes it perfectly possible to use Mutter under Plasma. OTOH Gnome people found it to be too much freedom to allow their users to switch window managers, so they made it impossible in Gnome 3.

So stop demanding that others fix the shit you broke. Don't break it in the first place. 
+Markus S. let's not bullshit people, here. the Qt/GtkStyle integration was done because Trolltech wanted to make sure Qt apps would work on Ubuntu, which was a GTK/GNOME shop, not because KDE developers, out of the goodness of their hearts, decided to play ball with GTK. if somebody wants to write a GTK theme engine that draws like the default KDE theme, be my guest: you can ship it anywhere you like.

we're not "forcing" CSD on anybody: we're telling the window manager that we're going to decorate our windows ourselves. we actually proposed extensions to the EWMH, to which nobody replied because apparently nobody gives a shit until it's a week from API freeze on KDE.

we also don't prevent people from switching window managers: you can run most of the GNOME apps with any window manager — except that you'll need to write your own settings manager, and you'll probably have to redo all the integration work that we had to do to make sure that your session locks properly and without races, or that your settings get propagated to all the applications regardless of the toolkit they are using. ah, right: KDE still does not use the XSETTINGS protocol that was devised years ago precisely for getting stuff in sync.

really, stop spreading FUD. if this is what passes for opinions, I'm honestly better off wasting my time on Phoronix.
Perhaps the APIs haven't changed, but the behavior behind it seems to have, according to experiences of developers I've read from.

Essentially, if interfaces to the outside world (that includes structural definitions that 3rd parties can use, such as CSS classes) change, it's effectively changing the API. Might be source compatible, perhaps binary compatible, but still behaviorally different, and that's causing pain for 3rd parties. If I change stuff internally and it results in previously working code / UIs suddenly looking like ass -- that's breakage.

I have to add here that I don't have these problems myself, not being a GTK+ user, so maybe they're solvable and there's a good explanation to every single one of them. Still, to many developers, these issues are real. I don't personally think the reasons and underlying mechanics are hard to understand if one listens closely enough. In the current situation and outlook, for many projects it's a good enough reason to consider even a larger port.
+Emmanuele Bassi the GTK engine +Markus S. is referring to is the Oxygen engine. It mimicks the look and feel of the Oxygen Qt style (that's the one we've been using as Plasma 4.x's default style). There are GTK+2 GTK+3 versions. It's purpose is to visually integrate GTK apps into Plasma workspaces. It's quite nice, try it sometime: git:// (patches welcome :)).

The Ubuntu Qt style is unrelated. KDE developers decided to play ball with GTK long ago. :)
+Sebastian Kügler I know Oxygen — especially because it tends to break GTK apps, given that it overrides the CSS, which means that it's working against the toolkit's drawing model. hopefully, now that we have moved everything to CSS, Oxygen may be able to be moved to a full CSS style, and keep working.
+Emmanuele Bassi Good. In Plasma 5 (5.0 is due in ~3 weeks), we're moving to a new theme and widget style, it's called Breeze, and at some point, we'll surely want to be able to theme GTK+ apps, so we get a consistent look across toolkits and different apps. We don't have a native Qt style for it yet, just a QtCurve style, which is kinda-like-but-not-quite CSS, workable for now, but a natively drawn Qt style would be nice. For the QtQuick UIs, we already have that, and moved the theming into SVGs rendered on the scenegraph.

The new Breeze style is much simpler, visually, so I'd guess it's also easier to implement as a CSS style. We're transitioning gradually to the Breeze style, as it's too much to get into 5.0, and there's still a lot of work ahead of us.
+Emmanuele Bassi I'm answering to your first reply here - after that I wasn't online any more and the discussion drifted. I got this reply in an integration bug report I created after GTK+ apps regressed badly in all environments except GNOME in a minor (!) release. A developer proposed a better suited default which would make the integration better on most environments without harming GNOME at all. But GTK developer said no, because it would look "unpolished" if g-s-d crashes. It just shows one how the perspective is: a potential flicker while g-s-d restarts is more important than better integration with all other environments. You know I spent quite some time reporting the integration bugs, I felt like the GTK+ quality manager - a job I should not be doing. I had been told by the same dev that it "seems to be working more or less just fine" when we reported the first problem including screen shots showing how "great" it looked with KWin. Yeah right, we would report bugs if there were no problems. The same dev reported a bug against XFCE that their window manager is the only one not supporting the latest shit from GTK+ camp - guess what KWin showed the same "bug" and the same with a bazillion other window managers a KWin dev actually tested. I'm investing lots of time to make the situation for our users better by starting to implement support to make your GTK+ applications unbreak in our window manager. GTK just requires all window managers to adjust to their changes. We are probably the only one which has the manpower to do that. Yeah when that happens, you totally get that looking "unpolished" in GNOME Shell is more important than integrating with the rest of the world. Yes it's very motivating that I now spend time to add support for GTK's newest stuff while at the same time we removed all application specific bugs.

You know I played long with the thought of just enforcing our own decorations around GTK's applications to make them unbreak. It will look like shit but at least the window can be closed and the shadow is no longer part of the window. After reading that I know I should do it, there is no hope that GTK devs will fix the integration issues. Looking polished when g-s-d crashes is more important. I get that pity that GTK+ apps look unpolished everywhere else.
For the integration issue. You raised something, but integration issue is vague. I'd like to see the specifics, read the whole conversation, etc.
+Emmanuele Bassi "KDE is just a consumer of that platform"

Actually, it is a significant contributor to the platform.

The HTML engine, XML/XSLT query implementation, multimedia and other bits came from KDE's repositories. In Qt5 KDE kicked that up a notch and a lot of functionality was added to Qt for things like l10n calendar handling and ref count based app exit by the KDE team.

The real difference is not that KDE is a consumer of Qt, but that Qt has as a core principle "run well everywhere".

"the Qt/GtkStyle integration was done because Trolltech wanted to make sure Qt apps would work on Ubuntu, which was a GTK/GNOME shop, not because KDE developers"

For all your talk of not bullshitting people, Emmaneule, you're evidently not above it yourself ...

The integration with Gtk environments started long before the GtkStyle integration. I know because I was there for the discussions and implementation. It started with things like automatic run-time button order changes in dialogs depending on the environment and continue to creep forward until we had glib event loop integration which opened further doors.

The GtkStyle integration was another logical step in ensuring Qt applications run amazingly well on all platforms, including those using Gtk.

That said, even without all that work: Qt apps work on Ubuntu. This was not about making them 'work' it was about making them look more 'native' or 'at home', if you will. This "Qt apps don't work on ... because ... " meme was tired a decade ago.

Now, the actual style the person was referring to was the Oxygen Gtk+ style, which you apparently you do know about. The reason it was mentioned, obviously, was to show that KDE people care about how other things look in Plasma as well as how their own apps look in other environments.

Ok, with that all straightened out ... Gtk+:

Personally, I respect the decision to take Gtk+ more centrally into the GNOME project and make it "the GNOME toolkit". I completely understand the stress of not having enough resources and see the choice to draw down the requirements for Gtk+ ("Work well on GNOME Shell, everything else is a bonus") as a completely valid response to those resource restrictions.

Unfortunately, this is making Gtk+ less attractive to others, which means less usage and even fewer resources available to it as time goes on. Gtk+ may have entered a self-reinforcing cycle there ....

I understand why app devs (and theme devs up until now) are not happy and even upset: they've put a lot of effort into using Gtk+ in their app(s) operating under the assumption that portability was part of the package, even if we define "portability" to the very limited horizon of "other X11 envs". That definition has changed, they haven't had a direct say in that (which, as you note, is partly their fault for not getting involved so there were more resources available to Gtk+ dev!), and so they have some resentment. Fine.. it'll blow over and people will move on.

I think people working on other envs like XFCE or KDE's Plasma should not sweat it, though. I think the best approach is to simply advise their users that apps built with Gtk+ 3.x will have a sub-standard presentation due to a change in that projet's goals, and similarly advise application developers that if they wish to target any env other than GNOME Shell they should consider alternatives to Gtk+ 3.x. The users and app developers will make up their own mind on this, and it will all sort itself out naturally.
+Emmanuele Bassi “I know Oxygen — especially because it tends to break GTK apps, given that it overrides the CSS, which means that it's working against the toolkit's drawing model. hopefully, now that we have moved everything to CSS, Oxygen may be able to be moved to a full CSS style, and keep working.”

Sooo… considering that you asked Martin for GTK patches, I assume that you hereby volunteer to write these patches? I mean, you wouldn't want to come across as dishonest after you called out for not bullshitting, right?
+Markus S.: Don't be a jackass, thanks.

And because you like the tit for tat method: Speaking as a GNOME release team person who often looks for Oxygen issues as part of helping out with Mageia. I've raised integration problems with people who can do something about it. E.g. the symbolic icon issues. Wasn't working, people at Mageia noticed this, thanks to various feedback and a little bit of prodding it was fixed.

Let's not start behaving shitty towards eachother and put people into camps, that's not the way forward.
+Emmanuele Bassi "you want to ensure GTK+ works on Windows? or even on KDE? show up, contribute patches, run a continuous integration build. even replying on mailing lists when we propose protocol extensions to make sure that our toolkit features integrate in your platform is welcome" - don't act like Gnome developers are open to collaboration...
Most of us here have seen the mail where feedback was given when Gnome was just starting to think about CSD... You guys spit in the face and went forward...
It feels like you think that Gnome is the most important project in the entire Linux ecosystem and all should bow before you...
And it doesn't help to the stereotype when you instantly respond aggressively to everything that's said...
I have the impression you will wait till Plasma 5 is released and then might start talking...
+Martin Gräßlin I read the bug report you linked to, but I did not get the impression they are unwilling to solve the problems. Maybe I missed something?
+Lilian Moraru: I don't get it, what email are you talking about (reference)? It is very clear that CSD has a few issues. But at the moment I get the impression your complaint is "I told you CSD is not nice and you went ahead anyway". Bugs can be solved, design and how things work can be changed. In the past the window manager did a lot of stuff, it is not mandatory to keep everything working exactly the same way for ages. Maybe I'm totally off, but the lack of reference doesn't help.
+Julius Schwartzenberg some were closed as WONTFIX, in others we were told that we are doing it "wrong". Overall so far nothing got fixed, only things improved that we can add support for it. In other words: all WMs are expected to change their code to make GTK apps work again. I think it's understandable that I'm not thrilled about it.
+Martin Gräßlin that makes it more clear, thanks. I'm indeed surprised about this, because backwards compatibility is in general considered important in this area. If I would notice such problems with GTK+ applications I will know where to report the problems and it seems the only solution is to encourage others to do the same.
+Martin Gräßlin Could I ask for little clarification? 
The problem discussed in the bug is that some GTK+ application  doesn't report the  shadows it draws properly, not the fact that application (application, not window manager, the group of widgets tied together to do some job) is drawing not only the widgets, but some underlying crap?
Just.. WAT. 
Add a comment...