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.
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.
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.
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.
> 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.
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".
> 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.
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 more stable in the last few cycles.
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 not simplification. Simplification is when things get easier, not when they get harder.
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.
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.
I'm currently using Greybird[0] under XFCE, but I'll keep my mouth shut since it's both blue and grey with black desktop panels ;) The widgets sizing and layout is decent though
Honestly I haven't seen anything GTK+ based that looks as good as KDE (4.x).
> Honestly I haven't seen anything GTK+ based that looks as good as KDE (4.x).
Here's a phrase I never thought I'd heard :-).
I don't really like Greybird, but Bluebird is nice. Now if only there were a (non-hacky) way to consistently disable the frickin' client-side decorations, I could almost use Gnome 3.
I've spent considerable time looking for GTK3 themes that meet your requirements.
My current choice is openSuse-Pistachio which is green, reasonably compact, and did not break for two consecutive Ubuntu releases. zonColor icons work beautifully, too, with adjustable colors.
There are a few more reasonable choices (though not oodles) on gnome-look.org
I also get GTK2 for free. That's not the problem. I'd happily make my own GTK3 theme if GTK3 weren't so incredibly hostile to theme development. It's literally less reliable than Windows Blinds, which is a frickin' hack on top of a closed OS.
It's not a problem of asshole theme creators, it's a software quality problem, and everyone in the Gnome Project's bubble is dancing around it and pretending it's good for the users.
Often that is acceptable advice, but in this case, their issue that:
> - Doesn't break in the next release.
is something that can't be worked around simply by creating your own theme. That seems to be caused by poor compatibility checking (or reckless disregard, as others are claiming), which could bite you even if you create your own theme.
Obviously, you could extend your suggestion to "fork gtk3", but that's likely a significant undertaking and not reasonable for everyone. I think it is reasonable to expect developers to maintain compatibility between minor version releases, assuming they're using semantic versioning, otherwise it's poor communication on the part of the developers.
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...
Yeah, but the backend seems to be buggy, the documentation is not up-to-date and basically half the things that work in 3.x break mysteriously in 3.(x + 1).
Meanwhile I can use a gtk2 theme from 2006 without any problems (and it doesn't make my desktop look like a kid's HD drawing). As long as I can do that, I have very little motivation to put up with gtk3's crap.
People seem to like it. Personally I don't, but... yeah. Gtk3 devs have outright said that gtk3 is not officially supported in any environment but GNOME3, which also worries me. On the other hand, this may be enough stimulus to make QtFirefox happen.
I would like to see a screenshot of that xfce-b5 theme and what you want to achieve. For reference, this is how Firefox/Iceweasel looks in my system, running GNOME Shell: https://i.imgur.com/VedZNiC.png
I didn't crop it: that is all that is visible when maximised. I'm using tree-style-tabs for Firefox, and the Hide Top Bar and Maximus Two extensions for the Shell.
Most gtk2-based (or dependent, in case of eclipse) apps I use at daily basis (incl. floating deadbeef settings window with older gtk2 plugin) side-by-side. I haven't included evince (gtk3) as I am using partially broken gtk3-Mist theme (not compact as xfce-b5, but still better than Adwaita). Nothing scaled, cropped or such. Btw, I use Classic Theme Restorer plugin, which also helps with firefox UI compactification.
This firefox theme makes the app's decorations really small. The icons look as if they were designed in 1995, but if there is a choice between slick and compact, I pick compact.
On second thought, Classic Theme Restorer works just as well with the latest firefox dev build.
TreeStyleTabs, like felipeerias already mentioned seems to be THE reason why a whole lot of people use Firefox. (Others like me have a bunch of additional reasons.)
What's the problem with deadbeef? It supports both GTK+2 and GTK+3 interfaces - GTK+2 is even the default and considered more stable since most of deadbeefs developers prefer that one.
Edit: Regarding Evince, there's Atril. It's the GTK+2 evince fork from the mate developers.
You've made my day, thank you so much! Atril is really what I've been looking for.
Regarding deadbeef, yeah, it was mentioned mostly on emotional basis. I had some troubles building gtk2 plugin on my home machine, good chances that it was problem with inconsistent building environment, yet no problems with building simple gtk2 apps or deadbeef gtk3 plugin. I haven't dug deeply though. At work, I just use slightly older deadbeef version with gtk2 plugin :)
If you need help with building deadbeef, just visit us in IRC (#deadbeefplayer in freenode) and we'll help you. There are also portable builds available, those should work on any distro.
I believe it's optional on the part of the application developers, but it's not optional on the part of the users. (Although it only happens if you have a compositing window manager, so that's one way to disable it.)
I for one like the current gnome themes but I can very much relate to (Gnome and Ubuntu) devs going off in other directions that I find weird and counterproductive ("breaking" (IMO) alt-tab, copying "shiny things" (dock) from Mac etc), copying other problematic (IMO) designs (single menu, hidden menus) from Mac.
I've encountered that while being on a quest to find perfect gtk3 theme :) Scrollbars are tremendous, which is crucial on tiling wm (see my screenshot above, for example).
Yes, I've been trying the nightly builds (elm branch) on and off for a while, and the smooth scrolling really makes a difference. What it does is it translates touchpad input directly to page scrolling, and not to a series of discreet "scrollwheel up/down" events. Its a very Mac-ish experience.
Another great thing is the fidelity of widgets (buttons, dropdowns) esp. on a high dpi screen.
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).
Firefox smooth scrolling tears on every Linux machine I've used lately. Different distros, different video devices abd drivers, different compositing managers, etc. If I disable it, either the tearing is gone or the issue is difficult to see, I'm not sure. If this fixes that, that'll make me quite happy.
[edit] Oh, reading that thread, it sure does sound promising. I'll have to check it out.
I’ve always used its “smooth scrolling” feature, and I do not recall ever encountering any issues with it at all, save possibly one which has been happening for what is probably almost a year and which I still haven’t reported: monospaced code blocks with horizontal scrolling don’t draw the newly exposed regions properly as you scroll horizontally (of course, selecting the text fixes that, but it’s still a nuisance). Is that the sort of thing that you’re referring to?
Weird, I haven't seen that. I'm referring to vertical scrolling, and what I'm seeing is typical tearing like you'd see when you're having vsync issues in video games. When movement stops, everything looks fine again, there's no lasting corruption.
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.
Firefox uses GTK to draw native-looking widgets. Basically, Gecko passes an X11 pixmap to GTK2 the latter draws the buttons/scroll bars/etc. into it with xrender. This means that Firefox either has to do all of the rendering with xrender and pixmaps, or do an expensive read-back of the native widgets from the pixmap and draw other web content into whatever kind of surface it wants. The thing is, we really really want to move away from xrender. GTK3 has a slightly different API for this and can draw native widgets into any kind of surface that can be wrapped in a cairo context. So for Firefox, the most important part of moving to GTK3 is the removal of this dependency to X11 and xrender.
Chrome (as far as I know) doesn't do native-looking widgets (and to be honest I would be happier if Firefox didn't either), so moving to GTK3 is not that big of a deal for Chrome because it doesn't use the GTK nearly as much as Fireox does.
I don't really use chrome. If the widgets don't look native that's fine, but do they behave natively? If they're not drawn by gtk, do the standard keybindings work if they've been changed from gtk's defaults. If not that would be quite infuriating to use.
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).
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.
As an i3wm user, sometimes, but not always, after resuming from sleep, chrome puts context menues (and only context menues) on my other screen, so I wholeheartedly agree that Aura and multi-monitor (tiling?) setups have some issues.
I wonder if the difference in decision here has to do with Firefox having its own Long Term Support version. So people needing GTK2 on say Ubuntu LTS can use Firefox LTS for that, and latest Firefox is more free to focus on GTK3.
No, because it is horribly broken in many situations: On linux, context menus often end up on a different monitor than the window, on windows, Aura can’t render text readable at all, etc.
Still when I upload a file, I get the native file selection box.
Also, the "use system title bar and borders" option (when right-clicking on the topmost bar) feels a bit like a hack, but I guess it is the best solution to get rid of that extra top window decoration space on most OSes.
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.
You should check out Otter browser (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.
Jolla uses a Qt port of Gecko (ESR, it seems) as the engine of Sailfish Browser, the default browser on Jolla devices. See https://github.com/tmeshkova/qtmozembed
As I understand it, even during the Nokia days, the point was to use Gecko with a Qt-native UI, so it wasn't about getting the entirety of XUL-based Firefox polished on Qt.
I made some fixes to the Qt backend a year ago, but gave up again rather quickly. There are some rather big chunck missing and as others have said it's actually getting worse. For example the Sailfish people removed the component that renders native buttons, because that would have been a lot of work to port to Qt 5. (So now you only get the rather ugly XUL implemented controls)
> Anyone from Mozilla aware of the status of the Qt Firefox port?
From what I can tell the progress is backwards. A few years ago there were Firefox Qt builds on mozilla and regular progress on it. Now the builds disappeared and the only commits to the Qt backend are in some hard to find github repos with no activity.
I haven't seen any activity around the Qt port for a long time.
Really the main visible difference is the file/print dialogs. I think maybe XDG would be a better way to standardize that, and would fix many other apps as well.
Rekonq actually uses WebKit under the hood, and it's pretty fast (faster that firefox and chrome) and lightweight, without any issue of compatibility problem on any webpage. The only big issue is that was very unstable for a lot of time.. at least on KUbuntu.
Rekonq is dead (as a project I mean), and I've seen plenty of compatibility problems, with rekonq, qupzilla or even the test browser (i.e. the problem is with the engine). FWIW epiphany (or "web", as is it called now) is GTKwebkit based and crashes just as often.
Qupzilla-git i.e. the version based on Qtwebengine is getting there, so reasonably soon we may have a decent Qt-based browser (I don't doubt scrollaway knows that). Also the fiber browser looks promising.
I do think we need a way to do CI between chromium and Qtwebengine, or else we'll end up shipping browsers lagging one or two versions behind chromium.
As far as gecko goes, I think it's over. The hope is servo, which being much more modular may be integrated without struggling with XUL.
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.
>> So the next question is, anyone running Firefox on Wayland yet? ;)
I run Fedora 22 and tried FF on Wayland. It brought the system to a crawl, but I believe it was using Xwayland and not native. Running it native Wayland is supposed to be nice. I'm hoping my old machine from 2005 will still work great with Wayland. Desktop and simple web stuff worked fine, but it died on cookie clicker.
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.
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.)
I've been out of the gtk loop for a while now—I built a couple apps on gtk2 back in the day. What is wrong with gtk3? Why would this be controversial at all?
I don't have a definitive answer, but I think it'd be from association with Gnome 3, which draws out all sorts of pointless and tiresome flame wars amongst people who thrive on creating (and then wading into) emotionally charged drama about software, of all things. :(
Gtk+ 3 is part of the modern degenerate conspiracy along with systemd and other abominations such as kdbus to destroy Linux by straying from the time-honored ancestral traditions of UNIX which were devised when men were still true hardworking men, that spent hours of sweat and tears configuring their window managers and compiling kernel modules as was ordained by the ancients.
ggs ... if you feel this way then create a for profit service that makes money ... like nginx ... keeping things alive is about having minions to work for you
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.