
Firefox nightlies for Linux are now using Gtk+3 - abrowne
http://glandium.org/blog/?p=3573
======
xpinguin
Disasterous :( For me, it has begun from evince and deadbeef, now firefox is
on its way to follow.

The problem is that I am unable to find any compact gtk-3 theme that looks
like xfce-b5 theme for gtk-2. Xfce theming engine seems to be broken under
gtk>=3.8. The only possibility is to recreate theme from scratch and pray that
nothing would be broken when minor bumps again. Hell, I am unable to find
_any_ theme compact enough!

Could somebody please help me to rule out: do most people really like that
ugly-looking space-wasting bullshit like Adwaita (and other such nonsensical
things mistakenly called "themes"), or is there some mysterious underground
group guarding the treasure chest with human-friendly themes allowing only
deserved ones in (how to become that one, btw?)?

Its like being forced to leave my simple but consistent country house (gtk2)
in favour of tall block building (gtk3), using the lift (smooth scrolling) as
an argument. I don't need lift.

tldr; Firefox won't be able to compactify its UI to the degree desired. Some
users could clearly identify such situation as "regression". I am pretty much
disappointed and annoyed of the trend.

~~~
weland
I was prepared to whine about exactly that.

There is literally no gtk3 theme that, simultaneously:

\- Is not flat and generally grey or dark blue. It's as if everyone Apple
fanboy who was rejected by Apple's UX department is now making GTK themes.

\- Is not frickin' ginormous. I know multitasking is frowned upon now that we
have tablets, but I have a bloody 27" screen, I _want_ more than one window on
it at the same time!

\- Doesn't break in the next release.

At first (as in, 2011 or so) I just blamed it on gtk3 being new and all that.
But we're four years from that. This disaster seems to be _intentional_.

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

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

------
chrismorgan
And
[https://bugzilla.mozilla.org/show_bug.cgi?id=958868](https://bugzilla.mozilla.org/show_bug.cgi?id=958868)
indicates that it has true smooth scrolling. _That_ is, in my opinion, the
poster feature for upgrading to GTK+ 3.

~~~
andor
It does. The GTK3 version of Firefox already shipped with Fedora 21 (last
December), and has been scrolling very smoothly ever since.

~~~
glandium
I'm surprised, the Fedora maintainer told me Fedora wouldn't ship with Gtk+3
Firefox before 22.

~~~
abrowne
I'm not a regular Fedora users, but I was following this enough to notice that
it was not default until version 22. There were builds for testing via copr
(like PPAs for Fedora).

------
evmar
Chrome used GTK2 as that was current at the time, and when we looked into GTK3
we concluded that it'd be a pain to target both simultaneously (the point of
the new major version number is that the API changed) and that as long as we
were supporting old distros (e.g. "Long Term Support" versions) we should keep
GTK2.

These days, those older versions are dying away, but Chrome doesn't use much
GTK anyway. I wonder how hard it would be to target both. But that doesn't
solve the binary compat problem anyway.

~~~
xiaomai
It's a real shame chrome moved away from GTK. Aura is probably fine for many
use cases but it does weird stuff on multi-monitor setups (drawing artifacts
and windows jumping around).

~~~
arianvanp
Aura really doesn't like my xmonad setup. Chrome doesn't like it at all
either. If I lose focus of the chrome window due to a Panel coming up
(undocked window), chrome won't regain focus and I can't type anywhere and I
have to SIGTERM it to make it work again. quite annoying.

~~~
samdk
I've had issues with chrome/xmonad not regaining focus properly that were
fixed by adding the code mentioned in the 'usage' section of this page:
[http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-
Ew...](http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-
EwmhDesktops.html)

Not sure if that'll help you with your specific program, but it might.

------
scrollaway
Anyone from Mozilla aware of the status of the Qt Firefox port? I remember
seeing progress on Github and I was really excited for a while, but it seems
to have completely disappeared.

Right now the Qt world doesn't have an acceptable browser, which is incredibly
annoying for us since we're targeting Qt-based desktop environments. I'm
hoping the move to GTK3 at the very least helps towards that.

~~~
mih
You should check out Otter browser ([http://otter-browser.org/](http://otter-
browser.org/)). It's FOSS, an Opera 12 clone and uses Qt5. Despite it still
being in a beta with known bugs it's under active development and quite usable
in its current state.

~~~
scrollaway
Thank you, I hadn't heard about it. I'll keep an eye on it.

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

~~~
johnny22
the plugin-container process still links to gtk2 afaik

~~~
glandium
Yes, Gtk+3 Firefox uses Gtk+2 plugins. Hypothetical Gtk+3 plugins are not
supported.

~~~
shmerl
Thanks, that's good to know.

------
zobzu
So the next question is, anyone running Firefox on Wayland yet? ;)

~~~
sohkamyung
Apparently, yes. [
[https://plus.google.com/112174839778779720402/posts/BB586bhi...](https://plus.google.com/112174839778779720402/posts/BB586bhiyKH)
]

~~~
zobzu
Exciting times!

------
nilgradisnik
That is great news. I'm very impressed with the latest Gnome 3.16, Gtk+3 is
definitely a step in the right direction. Go Mozilla!

------
gillianseed
Nice, so I assume it will now run under 'pure' Wayland rather than XWayland ?

~~~
Ded7xSEoPKYNsDd
This was an important step in that direction but I don't think it's there yet.

[https://bugzilla.mozilla.org/showdependencytree.cgi?id=63513...](https://bugzilla.mozilla.org/showdependencytree.cgi?id=635134&hide_resolved=1)

------
smegel
Gtk+3 != Gnome3

------
uxcn
I use almost no icons, and in fact I ended up installing a plugin to hide the
menu bar after the last UI change unhid it from vimperator. So, I guess this
doesn't impact me.

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

~~~
Ded7xSEoPKYNsDd
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.)

------
vsync
I hope SeaMonkey will still work normally.

------
cjsthompson
At last!

