[xpinguin]

That gtk3 maintainers position on backward-compatibility really puzzles me. May be I am wrong, but theming engine is a vital part of an UI toolkit - you need to represent all the fancy widgets somehow in a way appropriate to the user. Yet they keep on breaking things almost each minor, leading a lot of theme creators to quit. Might be the real underlying cause of our whines...

Nevertheless, I don't see any other way than point out to the problem again and again, when each important piece of software is going to switch to gtk3. World does not stop on gtk3, there is Qt, which can handle gtk2 theme engines pretty much seamlessly (at least, from my experience), without breaking things at each release.

[weland]

Yeah. I still manage to live in a gtk2-only world for now, but mostly because I don't really need too many GUI programs (I can't remember the last time I opened something other than Thunderbird, Firefox, Emacs, and whatever pdf reader and image viewer I have lying around) but that's obviously not sustainable.

Unfortunately, GTK3 (and, for that matter, much of the modern Linux user-side development ecosystem) is increasingly hostile. Frequent, often unwarranted changes (implemented through code of dubious quality), crap documentation (when it exists). It feels increasingly like developing for (and using) OS X or Windows, just without the good parts that we all secretly covet, like Visual Studio and Interface Builder and the MSDN.

[EmanueleAina]

> May be I am wrong, but theming engine is a vital part of an UI toolkit

Arguably, for a big chunk of GTK+ users (me included) it's not. I care about the work on the default theme as I can't really be bothered to install custom themes. For me, the same is true for Qt or whatever other toolkit: either they give me appropriate defaults or I will probably tend to ignore them.

That said, it seems that GTK+ developers agree with you more than you seem to expect: in the past few cycles they worked a lot on the theming engine, simplifying it to the point that the whole theme is defined only by CSS.

Instead of writing clunky, complex loadable modules in C, they can just mash together some CSS and customize every part of the UI. This is a massive improvement over GTK+2.

Of course, since the CSS can poke at the deep internals of the toolkit, complete stability cannot be provided: think of it as a user-level CSS that cannot cleanly cope when the target website changes.

[xpinguin]

Well, I feel exactly the opposite. Although, I had no chance to write gtk theming engines due to lack of neccessity, I would argue that most of the time clear good ol' imperative chunk of simple and straightforward C is far better than arcane declarative CSS based on whatever underlying rules I am not fully aware of.

P.S. I has experience with both - besides writing my decent share of C code over the course of past 10-or-so years, I had an opportunity to write stylesheets in pre-HTML5 times (for money). Later was far more sane and flexible (yet a bit arcane due to multi-browser compatibility) than writing on pseudo-CSS in order to compactife modern Eclipse (4.x). No way I would believe that pseudo-CSS for constantly unstable underlying engine could be somehow better than "clunky, complex loadable modules in C".

[EmanueleAina]

> imperative chunk of simple and straightforward C is far better than arcane declarative CSS based

Nope, consider yourself lucky if you have never heard the horror stories about the old theming code (and even more lucky from the fact that you never had to poke at it). :)

P.S. Me too, I worked at a small studio developing web apps for a few year, then moved to optimizing HTML/JS/CSS3 apps running on a custom WebKit enviroment with animations, transitions and whatnot on a embedded (and horribly low-powered) platform and now I have the pleasure of trying to make WebKit work well on the Raspberry Pi.

As far as I can tell, CSS is several orders of magnitude better than poking at C code for those purposes.