Live data from Hacker News

Firefox nightlies for Linux are now using Gtk+3

glandium.org

121–129 of 129 posts

Re: Firefox nightlies for Linux are now using Gtk+3

#121

Earlier quoted context omitted.

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…

> 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 agr…

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".

Re: Firefox nightlies for Linux are now using Gtk+3

#122
post #32

Great! A lot of improvements depend on this GTK3 switch (like using Azure with Skia) and it took quite a while. I'd still prefer Firefox to use Qt 5 instead, but whatever. Shumway however is still far from finished, and I'm not sure what will happen with plugins which depend on GTK2.

the plugin-container process still links to gtk2 afaik

Ah, so they can coexist in such fashion? Before there was some problem with that.

Re: Firefox nightlies for Linux are now using Gtk+3

#124

Does this mean that upcoming Firefox builds won't run on RHEL6, or does Firefox bundle its GTK3 build?

For now, Firefox can still be compiled for GTK2. I imagine that as time goes on more and more responsibility of maintaining that port will move to the LTS distributions that actually care about that.

(This is just what I think is likely to happen, this isn't based on any announcement by Mozilla.)

Re: Firefox nightlies for Linux are now using Gtk+3

#125
post #116

Earlier quoted context omitted.

Do a google search for GTK 3.16 theme bug. You'll find a bunch of people for whom it didn't take minutes.

Then submits bugs and contribute to fix those bugs, it is the way open source works, if you don't like it, go use something else, nobody is forcing you to use it.

What does being open source have to do with having crap policies?

There are plenty of open source projects that don't have those problems, and it's not like the core team is interested in making theming anything else but a clunky hack so that everyone uses Adwaita...

Re: Firefox nightlies for Linux are now using Gtk+3

#128

Earlier quoted context omitted.

> 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 agr…

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 1…

> 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.

Re: Firefox nightlies for Linux are now using Gtk+3

#129
post #115

Earlier quoted context omitted.

Things have improved a lot with the CSS engine maturing. With GTK+2 themes where loadable compiled modules and where far from simple. With GTK+3 you do everything with CSS alone. Of course full stability cannot be provided due to the fact that the CSS can poke at the internal composition of composite widgets, not unlike how greasemonkey scripts can hardly cope with the target website changing, but things got much mor…

Bullshit. Every time a new GTK3 release comes up, the bug trackers of popular themes flare up (many of them obscure, e.g. https://github.com/shimmerproject/Numix/issues/206 ), various undocumented tidbits and bugs in the theming engine pop up and "innovations" like the client-side decorations are introduced. Meantime, clunky, terrible C modules written back when GTK 2.10 was a thing work just fine on 2.99. That is no…

The vast majority of third parties GTK+2 themes were using the pixmap engine (or murrine in some cases), which was basically what the current CSS engine is, just more arcane and infinitely less flexible.

I reiterate: full stability for theme developers CANNOT be provided, unless you're willing to give away much of the power of the current theming system, basically going back to the annoyingly limited pixmap engine. This (understandably) is not a tradeoff the GTK+ developers are willing to make, and I guess neither third party developers.

> Meantime, clunky, terrible C modules written back when GTK 2.10 was a thing work just fine on 2.99.

I don't know, I remember Murrine being often broken after new GTK+ releases, despite it being under active development.

> https://github.com/shimmerproject/Numix/issues/206

That issue has been opened on 10th April, I guess your issue is more than your theme needs more help for its maintenance rather than GTK+'s fault. Again: there's no provision of stability for themes. Either you accept to keep up with upstream or you'd better stick to the default theme. Just like using a greasemonkey script when a website changes.

The changes in GTK+ have become progressively less dramatic: this means that fixes for themes are now smaller/simpler, not that they don't need active upstream tracking.

Post reply on HN