[tenfingers]

I'd say good riddance GTK3. I really liked GTK1/2, to be honest. I liked the column-based (unixy) file dialogs, detachable menus that you could use as a poor-mans toolbars, and many minor tweaks.

The API was always horrendous (it still is!), but as user I liked it so I just coped as a developer anyway.

Since the full embrace of gnome, I started to dislike GTK2/3 more and more. The stupidity of file dialogs starting in "recents mode" also for save, to name one. Saving a file again? You see restarting at the top directory, just like in windows. Well, it's because the file dialogs don't have any saved state if you happen to destroy the dialog instance. A tweak that costs literally nothing to implement, but probably "not granma friendly"?

GTK3 is also downright slow. The new theming mechanism might be fancy, but objectively I have some UIs that I left at GTK2 intentionally for lower latency.

I re-evaluated QT4 as a user. The API and developer tools are just light-years ahead.

It's unfortunate that I cannot say I like the evolution of QT5.

[ultramancool]

Been using Qt5 for quite a while at work - what changes don't you like in it? Most things seem to just be relatively minor improvements from Qt4.

[IshKebab]

I use Qt5 extensively and these are the things I don't like (mostly QML-specific):

* It's HUGE. A "hello world" QML program is like 50 MB. You can get it down to about 20 MB is you use a custom Unicode library build (there is a 20 MB DLL which just contains Unicode data).

* The QML compiler is only in the commercial version. I know there is a third party open source version, but that is too much hassle. And yeah maybe I should pay, but hey!

* Lots of things still are impossible with QML. There's no decent basic text widget (e.g. for a log output).

* You can make custom QML widgets, but they can't render text. Kind of limiting!

* I don't think the basic premise of QML works that well. There is such a big difference between C++ types and QML types most of your code ends up dealing with the mapping. Especially lists of things are very hard to get right (and the documentation doesn't really point you to the "right" solution - which is to subclass QAbstractListModel if you were wondering).

* QML seems very hacky and javascripty - it doesn't scale well. Especially scopes and id's.

* Some QML things are weirdly hard, for example

- Rich tooltips

- Adding padding around list items

- Doing anything with the rich text widget.

That said, I still really like it. I'd just like it more if they:

1. Reduce the size.

2. Redo QML (again!). I'd be even ok with a custom language. It can be similar to Javascript, but it should support the native C++ Qt types (and custom ones) much easier.

[ourson]

You can actually build Qt without icu ( pass -no-icu to configure[.exe] when building Qt)

QML is designed with mobile in mind. For heavy desktop UI, Qt Quick Components, kinda fills the need.

Qt Quick 3 would be unwarranted, but a lot of maturation needs to happen.

[pjmlp]

It might be, but last time I tried Qt on mobile I ended up redoing the app in Java, C++/CX with XAML with C++ for the common code.

The effort for doing from scratch native widgets in QML was greater than the approach I took, specially because Qt didn't provide wrappers for the APIs I cared about.

[tenfingers]

As for GTK3, rendering performance, latency and memory usage in QT5 suffer significantly. QT4 is not light, but QT5 adds overhead for no reason.

I like the general polishing in the core modules, but I have really no use for qtquick. For this reason, I really encourage anyone to get onto copperspice (http://www.copperspice.com/). Without MOC, QT really feels an awesome API.

[ultramancool]

While I can't say I've experienced any significant memory usage or latency issues (possibly because I'm targetting recent hardware and working with large volumes of data), I'm completely in the same boat with QtQuick and CopperSpice does look quite interesting, I'll have to check it out.

[joezydeco]

I use Qt a lot on smaller embedded targets and I haven't moved to 5. Don't really want to mess with the new windowing system and I can't put Wayland/Weston on a lot of my smaller projects.

I'm pretty much locked into 4.8 (and it's eternally open tickets) for life.

[turrini]

And it does support Linux FrameBuffer.

http://doc.qt.io/qt-5/embedded-linux.html

[ultramancool]

The thing to note here is that the stripped out the windowing system implementation for embedded machines. So if you're using framebuffer without X11 or Wayland you're on your own for windowing now, which was previously provided in Qt4.

That's my understanding at least, I don't use Qt on embedded platforms though, can anyone confirm this?

[slavik81]

I don't work on embedded platforms, but it seems Qt5 supports directfb, which can do windowing.

http://doc.qt.io/qt-5/embedded-linux.html http://stackoverflow.com/a/21489384/331041

[joezydeco]

That's my understanding as well. I haven't looked deep enough into the QPA stuff to understand it.

[turrini]

Qt5 doesn't require Wayland, I'm using Qt 5.5.1 with widgets on embedded environments (X11 included) without problems.

[joezydeco]

X11 included

Yeah, um, not possible for me. I use the Linux framebuffer and that's it.

[witty_username]

> Wayland/Weston on a lot of my smaller projects

Huh? Qt5 doesn't require Wayland; I've used it on X.

[rhodysurf]

Whoa thanks for pointing out copper spice! I use Qt everyday at work and this could be cool to mess around with for some projects.

[jabjoe]

Yes, MOC and QT's C+++ is really an awful thing. Copperspice being just normal C++ is interesting. Have to see what happens. But for me, C is where my heart is, so there is still two + that need to go for me. ;-)