Hacker News Reader

Comment by rixed | Hacker News Reader

Meanwhile, copperspice got rid of the MOC more than 10 years ago.

I'm no longer familiar with Qt nor C++, but I guess the real blocker here is that the Qt foundation is only looking for ways that are 100% backward-compatible to inccur no change in its commercial userbase? Or am I missing something more subtle?

View on HN

> looking for ways that are 100% backward-compatible to inccur no change in its commercial userbase?

Non-commercial users also care about backwards compatibility.

Also FWIW Qt does break backwards compatibility in major versions, though the breakage isn't huge. And regardless of commercial or non-commercial, it is in general a good idea to avoid breaking people's working code.

> Meanwhile, copperspice got rid of the MOC more than 10 years ago.

That's perfectly fine. Copperspice didn't aimed to support legacy code, and thus could introduce backwards incompatible changes without looking back.

Dropping support for legacy Qt code also ensured it was automatically irrelevant, which is why most people in a thread over Qt have absolutely no idea what copperspice is, let alone that it existed for over a decade.

I wasn't aware of Copperspice, but would have been tempted to use it. Qt seemed to have lost it's way when it started with Qt Quick and QML and deemphasized it's roots as a cross-platform library with widget-based UI.

I was always uncomfortable with MOC - the rest of Qt was great, so you put up with MOC, but I was always hoping they might have moved away from it as C++ got more powerful.

I was always kind of uncomfortable with MOC too, but I couldn't really articulate why. I consider it "wizardry that works but I don't understand" and I never bothered to go in and really understand it. The more I program though, the less I want any kind of "wizardry" in my code, whether or not I understand it.

Does this motivate me to go back into all my C++/Qt projects and try to un-MOC-ify them? No. But if I started a new project, maybe I'd try to do with without MOC and instead do more in handwritten C++ code.

MOC just seemed to me like an unnecessary hack - an unwanted layer between me and my C++ code that was hard to justify. I suppose it may have served more of a purpose in the early days of Qt (1st release was 1995), but IMO could/should have been phased out when C++11 came along with things like std::function well suited to signals & slots.

What exactly are your qualms with Qt Quick and QML? I find the separation of UI (QML) and logic (C++) pretty amazing. QML is such a nice language and the framework has grown a lot over the years. I developed a block editor (Notion style) in QML and C++, wrote about it in my blog[1].

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

For my taste there was already enough separation of UI and logic in a widget-based UI with callbacks or signals/slots. I was using Qt for desktop app development, so didn't see any benefit to Qt Quick and QML which seemed more intended for mobile, and a step away from native desktop feel. Qt Designer also helped separate UI from logic, but although it was great I found it didn't quite hit the mark. I would use it for prototyping, but then reimplement for real.

In general I got into Qt wanting a nice GUI toolkit for C++ on Linux. The cross-platform support was a bonus, but not something that I ever actually used. MOC was already an unwanted step away from pure C++ development, and QML would have been another one. At the same time Qt Quick and QML support seemed to suck all the wind out of further Qt development for desktop use.

I still don't hear any concrete feedback regarding QML and Qt Quick - the stack is very suited to desktop apps as well. My FOSS app (1,500,000 downloads) has a Kanban UI written in QML[1] and people seems to like it. I do think the choice of Javascript as the scripting language for QML is not ideal to say the least (although there were some improvements to type safety like using `required` in model-view, etc).

Also, most QML components are just C++ objects exposing QML api. And I think there are some compile flags to convert QML to C++ (even some JS code).

[1] https://www.notes-foss.com

> I still don't hear any concrete feedback regarding QML and Qt Quick

Well, evidentially you chose/prefer that stack over Qt Widgets, presumably for some considered reason (unless it was just Nokia pushing that as the future, per their own mobile interests).

There was definitely a change of focus when Nokia bought Trolltech. For me it was a negative one.

Not the one you asked, but since I share the exact same feeling, and for what it's worth: I used to reach for Qt when I needed a complex desktop app, the kind of app with a high density of widgets, controls and information, great care for UI but little for aestetic. QML felt to me like it was going in the direction of web development, up to a point where you'd be better off having a separate front-end and back-end, all in the name of more eye candy.

I understand their worries, but it was not my need (and it felt patheticaly hopeless). When I need a web app, I go for a web app

Like most forks, it seldom gets used by the large majority that still cares about Qt.

It also never supported the whole Qt tooling ecosystem.

Reply on news.ycombinator.com