Hacker News Reader

Comment by dvt | Hacker News Reader

If you don't use some kind of layouting language (like XML/HTML), this is inevitably what you will always end up with. See: AWT[1], SWT[2], Swing[3], Qt[4]†, Fyne[5], etc., etc., etc.

[1] https://docs.oracle.com/javase/7/docs/api/java/awt/GridLayou...

[2] https://github.com/eclipse-platform/eclipse.platform.swt/blo...

[3] https://stackoverflow.com/a/12867862/243613

[4] https://stackoverflow.com/questions/37304684/qwidgetsetlayou...

† Qt actually has a (XML-based, I think) layouting system, but you can also just do stuff in code, which is generally discouraged.

[5] https://gist.github.com/ledongthuc/9686787fe51bbe763fa1e5038...

View on HN

Qt has uic xml layout engine which was cumbersome to use, you weren’t discouraged from using c++ classes instead. The discouragement came later when Qt shifted towards qml (a bad shift as it’s just as unweildly, imo), now they discourage writing qml in c++ because the qml engine can get out of sync. Qt can prevent this but they want you to pay for a premium license for it. Slint is a sister to qt that does not have this restriction afaik.

I wish there would be an elegant c++ class/function based ui framework again.

Agreed that a C++ API for qml would be great. qml by itself is great though, I don't see why it is unweildy. If anything it's unpolished, there is stuff that is more difficult than it should be, but it's miles ahead of what there was before imo.

It is unwieldily because it abstracts logic into a different language and paradigm. You need double the cognitive understanding of qt now to know how it operates.

As someone with 10,000+ lines of C++ code and 10,000+ lines of QML code in his app[1] I can say this is false. It's actually much easier and straightforward to decouple the UI (QML) and logic (C++). It also makes such a great combo - QML is amazing to write UIs in and C++ is a fast, battle tested compiled language. I wrote a little bit about my app development if you're curious[2].

[1] https://get-notes.com

[2] https://rubymamistvalove.com/block-editor

By the same metric c++ qwidgets is amazing to write UIs and by keeping everything in c++ there is easily less abstraction, I can easily navigate my code, not jump between two different systems. There really is no great reason why qml objects couldn’t be c++ classes/functions. Decoupling does what for me, but introduce more syntax, documentation, and learning curves. You should give writing a Kde6 Kirigami app a try and experience the absolute pleasure of adding another abstraction layer onto qml, c++ to muck things up. Qml is the cooler brother of Uic, but at least uic was optional.

I'm very fond of QML's syntax, so can't quite understand why you don't like it. It has a learning curve, but I studied all the basics in a day (it's just so simple and intuitive, imo).

Not sure how "QML in C++" would look like, but it doesn't sound pretty. Recently someone published a declarative UI inside C++[1] (without a different syntax) but I felt a bit off with this approach. Maybe that's something you mean?

[1] https://github.com/brisklib/brisk

[2] https://news.ycombinator.com/item?id=42450963

I don’t know how else to explain it that compared to qwidgets where everything can be handled in code. Qml might be all the things it claims , elegance, separation of concerns, simple syntax, etc, but that still doesn’t eclipse my initial issue that it’s an unnecessary abstraction. You might not think it’s pretty but I think it’s pretty to only use c++.

It's not difficult or disorganized to layout GUIs in a programming language. HTML exists as an alternative to having nothing. If you have a programming language you can give the data to the GUI library directly without having to learn a new markup language, have the bloat of a new markup language or learn the quirks a new markup language. You can also put format it and put newlines in there.

The thing is, most GUIs by necessity involve fairly deep hierarchies of graphical objects so you're either going to have deeply nested calls like this, or you're going to scatter the fragments across a number of files in a way that they need to be reassembled in the reader's head in order to understand what's going on.

most GUIs by necessity involve fairly deep hierarchies of graphical objects

First, this isn't really true. You might typically have a window, a container, a layout object and then your gui components.

Second you don't need nested calls, you just add one component to another.

or you're going to scatter the fragments across a number of files

Why would that be true?

they need to be reassembled in the reader's head in order to understand what's going on.

This is a bizarre way to make a GUI let alone thinking it's necessary. Where is this idea coming from?

FLTK, JUCE, Tk, ImGUI, Swing and Qt are not like this at all.

Reply on news.ycombinator.com