Hacker News new | past | comments | ask | show | jobs | submit login

Gnome3 is in a fight againt anybody who doesn't just want to look at the pretty colors. It really doesn't do anything right.



And even if you don't use GNOME3, Gtk3 is now required by Firefox, including Firefox gtk3 bugs, which will be fixed in Firefox. Most importantly the many regressions of Gtk3 itself. Gtk3 was a good refactoring to support Wayland and HiDPI, but it's not stable or fast yet for everyone, like Gtk2 has been. I accept the fact when gtk devs argue that gtk2 has many architectural bugs, but day to day as a user I don't notice them, and I very much prefer the old file dialog, for instance.

Gtk3 may be faster in theory due to GPU acceleration as a possibility, but when Gtk 3.20 for a split second shows a black rectangle for each new dialog while it's opening, I have a hard time taking their gpu acceleration argument seriously.

I tried building Firefox 48 with gtk2, but it crashed in the file dialog, while the gtk3 build is slower and introduces gui regressions (yes, I've reported the gtk3 bugs). Right now I cannot move past Firefox ESR with gtk2, and I hope I can still use Firefox next year.

What I'm saying is that GNOME3's stack (especially Gtk3) doesn't seem to work outside GNOME3 as compatibly as Gtk2 does, and it may be what's intended, if past communication from the GNOME dev team is any indication.


It made me so sad when Firefox switched over to GTK3, and now I'm stuck with their foolish attempt at improving the file browser. For whatever reason by default it tries (and fails) to open a network connection, and they broke the ability to navigate through the filesystem using just the keyboard.


> foolish attempt at improving the file browser.

https://bugzilla.mozilla.org/show_bug.cgi?id=1267863

https://bugzilla.mozilla.org/show_bug.cgi?id=635044

I predict that someone will get fed up enough to revive the Firefox Qt port, since Qt doesn't break as much between releases, and it doesn't conflict with Mozilla's plans to drop GTK2 support. The memory overhead of Qt is absorbed within a modern browser's memory needs.


An up-to-date QT FireFox port would make me so happy :)


The GNOME dev team is where people go when they can't put in work in systemd. The days when it was good are long gone.

GTK3 drags in way too much of gnome for comfort, but I don't want to drop all GTK3 apps, so I have to put up with it.


Actually, if you build GTK3 yourself, it doesn't need anything more than a current default GTK2 distro package does, but you'll lose features like colord support. My experience is with Gentoo USE flags, but I believe FreeBSD ports has options for packages that do the same and are the original inspiration for USE flags, so one should be able to use a lean GTK3 and GTK2 on FreeBSD.

When GTK3 and even Qt5 go user-unfriendly and dev-unfriendly ways, it's no wonder there's many immediate mode ui library projects that are popular or actively developed Haskell FLTK bindings.


GTK3 does not drag any gnome stuff??!? It wouldn't even be possible, that would be a circular dependency.

https://www.freshports.org/x11-toolkits/gtk30 It's "lean" by default, you can't even make it "not lean".

They're big, but I wouldn't call them "user-unfriendly and dev-unfriendly". QML/QtQuick is the best GUI development thing ever.

P.S. I was building Firefox from ports for a while, just to get GTK3 support earlier than they turned it on by default :-P


My point is that a lean build of GTK3 doesn't require more than GTK2 right now does. In the port linked to, libepoxy and libcolord can be avoided. And when you do that, it's down to what GTK2 depends on in its default build config on most Linux distros. If you could disable ATK, you could shave off some more, but GTK3 doesn't build without ATK.


And my point is that libepoxy and libcolord aren't "dragging in way too much of gnome" :)


Qt5's base memory overhead is big (minimum 25MB for the simples hello world window you can create). The modularization of Qt5 is a good idea, but it also makes use on Linux distros a pain, because it's too many modules, like the mess some Linux distros create when they split core Perl into a gazillion packages.


Just use Tk. Or wx. They're both well supported, cross platform, and if you use ttk, you can even have your app look good. And native.

For WM, I use i3. If you don't mind tiled, I'd highly reccomend it. It's great, the docs are great, and the config file is easy to understand, so after the base setup, you don't have to worry about it.

XFCE, TWM and sawfish are pretty cool, if you're not into tiled.


> Just use Tk. Or wx.

Yes, Tk just works for gui and is underappreciated.

wx's default backend is gtk (2 or 3) and they have an experimental Qt5 backend now, which is unsurprising given GTK3's state. So wx doesn't help, unless you can make the Qt backend work (Qt5 is so modular that it's often a pain).


Tk is pretty and lean but I never felt comfortable using it in C code. A native C toolkit would be nice.


iup? It's uglier than Tk though.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: