[HN Gopher] Qt Creator 12 Released
___________________________________________________________________
Qt Creator 12 Released
Author : jandeboevrie
Score : 80 points
Date : 2023-11-23 15:58 UTC (7 hours ago)
(HTM) web link (www.qt.io)
(TXT) w3m dump (www.qt.io)
| righthand wrote:
| I love Qt Framework, but the entire project has this weird
| entrenchment around using UIC or QML which are both designed to
| be some sort of templating for easily creating apps.
|
| However when actually writing code this stuff is practically
| magic which was confusing for me to learn about.
|
| I found it much quicker and logical to just write the classes and
| register your widgets/components in the C++ class constructor
| than use these magic files which rely on nested XML/JSON. The
| entire point of these files is to make building an app seem easy
| (even easier than HTML + JS) but I find the entire thing
| confusing and overly engineered when you really need to write and
| reference logic.
| billfruit wrote:
| There was still the 'moc' magic in the traditional Qt.
|
| But the interesting question is can something like Qt be fully
| build in modern c++ without need for such magic?
| righthand wrote:
| Yes that's what I'm saying you can build your software
| without this magic (moc, uic, qml) but it's not clear that's
| what is happening in the documentation for it. You simply
| just strip out the register for it in the proper files and
| then delete the xml or qml files.
|
| A lot of this stuff gets further promoted in things like Qt
| Creator which relies on building these kind of meta
| definition files.
|
| Moc is less of a problem IMO because it's more related to C++
| macros which at least is a language feature.
| saidinesh5 wrote:
| There were a couple of attempts in that direction, but i
| haven't really seen them used in any production codebase.
|
| https://woboq.com/blog/verdigris-qt-without-moc.html
| jcelerier wrote:
| https://ossia.io uses verdigris pretty much exclusively.
| Worse syntax but lots of advantages compared to moc.
| jenadine wrote:
| What advantages?
| jcelerier wrote:
| - Ability to use latest standards without issues - for a
| long time moc's c++ parser choked on headers containing
| too recent C++ features, breaking the build. For instance
| I remember noexcept and [[attributes]] being quite
| problematic a few years ago.
|
| Verdigris in contrast is just macros with c++17/20 code
| so it works and keeps working with newer standards.
|
| - moc integration in build systems would also not work
| well, e.g. for a long time there were issues in cmake's
| automoc if two files had the same name in different
| folder of the same project.. gets kinda complicated when
| you have projects with multiple thousands of source
| files.
|
| - I observed decreased build times after the switch
|
| - It's just a couple headers, very easy to experiment
| with changes and improvements
| pjmlp wrote:
| Not until reflection comes to be.
|
| Maybe with concepts + if constexpr + traits, if one is
| willing to open the druids metaprogramming book.
| vintagedave wrote:
| You need other magic. C++Builder does it via compiler
| extensions for properties/events instead of something like
| moc, so at least it's a closer-to-code compilation.
|
| One day it'll be in C++ natively. PME (property, method,
| event) was proposed to the committee in 2002. Modern C++ uses
| a different approach, but as is common with current
| additions, it can be argued is far more verbose and clumsy.
|
| https://www.open-
| std.org/jtc1/sc22/wg21/docs/papers/2002/n13...
|
| Then of course Microsoft has their property (subset) syntax,
| Unreal Engine has their macros and build system, Qt has
| reflection and C++Builder the same via extended RTTI...
| everyone who needs this, whether it's Qt, MS, Epic,
| Embarcadero, etc reinvents their own mostly overlapping
| wheels. And still in 2023 a solved problem has not made it
| into the standard. The most powerful in terms of width of
| features is C++Builder and I often wonder what would happen
| if Epic adopted a similar or the same pattern instead of
| using macros and preprocessing. Probably C++ would be forced
| to either split or adopt support for the features multiple
| companies need.
| zerr wrote:
| wxWidgets, FLTK and gtkmm use only pure C++ (and some
| preprocessor macros).
| zik wrote:
| Sure, but the PME approach Qt uses makes constructing
| complex UIs quite a lot easier.
| LorenDB wrote:
| QML is not "magic". It's a separate language that integrates
| with C++ and makes UI design easier, sort of like how webpages
| use HTML/CSS for the graphics and JS for the logic.
| righthand wrote:
| When it is unclear how my app compiles this separate language
| together with C++ it is magic. When I attempt to write an
| application and someone says "use this other language and
| don't worry about the implementation details" that appears as
| magical to the implementer.
|
| Magic can be de-obfuscated with documentation but if I can
| accomplish the same thing in C++ with nearly the same amount
| of code, then the magic isn't for me and C++ is a lot more
| clear and reduces cognitive overhead.
| saidinesh5 wrote:
| > but if I can accomplish the same thing in C++ with nearly
| the same amount of code
|
| That's not the case when it comes to QML/QtQuick though. It
| sounds like you were writing a desktop application, So
| C++/QWidgets were probably a better choice for your use
| case. But for embedded/mobile use cases, where reactive,
| smooth animated user interfaces are the norm, QML is on an
| entirely different league.
|
| Also, with QML I didn't have to worry about the ugly
| combination of junior engineers and C++ footguns.
| Palomides wrote:
| I've been working on a team replacing a widgets UI with
| QML, everyone on the team loves QML and finds it way
| easier/faster to work in (and the design/management love
| all the smooth animations etc.)
|
| and the guy who sucks at C++ breaks things less
| saidinesh5 wrote:
| Yeah that's more or less how it was for us too. Do make
| sure QML has all that you need. On Desktop (this was back
| in 2018, so ymmv), things like table view, undo redo
| stack, other integration features were missing.
|
| Our journey was like: "Wow.. this is so nice and easy."..
| 70% later.. "Should have researched this better. Now we
| have to mix QWidgets with QML code to get what we want".
| righthand wrote:
| I'm working in mobile too but have no use for smooth
| animations (which is of very little value) so QML isn't
| really valuable. I also do not like the idea of embedding
| a browser stack and forced to write JS just for that
| purpose. The point is to keep my code in C++ and not hop
| around to x different files to make sense of my
| application.
| Longhanks wrote:
| C++ is not the language for GUIs on mobile. There's not a
| single mature, widely adopted framework that supports C++
| for laying out widgets/views/GUI elements.
| saidinesh5 wrote:
| QML is NOT a browser stack though. QML is just a way for
| you to script QObjects. QtQuick - on the other hand - is
| a very performant GPU accelerated scenegraph that can be
| scripted using QML.
|
| > The point is to keep my code in C++ and not hop around
| to x different files to make sense of my application.
|
| Another point of view that differs from this is - QML
| lets you easily separate UI logic from business logic, to
| better make sense of your application. Especially when it
| comes to "responsive applications". For eg. All the UI
| related parts of your application stay in QML files in
| folders like desktop/ android/ common/ etc... All the
| "backend logic" stays in C++, ready to be used by all
| these UI elements.
|
| It is not about being forced to write JS. Nothing
| stopping you from writing very declarative looking C++
| either (fun article: https://woboq.com/blog/property-
| bindings-in-cpp.html ). It is just about using a better
| tool for the job. State machines. Reactive properties.
| Declarative UI description. All of these make you need a
| lot less code than writing everything in imperative c++.
| righthand wrote:
| It's not a browser stack but includes an HTML painter and
| V8 engine in your project? This sounds pretty close to a
| browser stack to me. If this isn't true then this is one
| of the confusing aspects. In including pieces of a
| browser stack or whatever is going on doesn't really help
| it make it look not like one. It seems like the ideas are
| obfuscated just to call it something else.
| jenadine wrote:
| I think it doesn't include a V8 engine anymore. Qt has
| its own JS implementation as far as I know. And it
| doesn't have a full html painter (If you don't use
| QtWebEngine)
| saidinesh5 wrote:
| HTML painter? you mean how QLabel supports rich text via.
| HTML tags?
|
| Not sure what you are getting at with the "ideas are
| obfuscated to call it something else". You'd have a
| widget tree/graph even with QWidgets/QObjects. Would you
| call any QWidget program that uses QJsEngine "a browser
| stack"?. QML is just a declarative programming language,
| that lets you script QObject properties/react to
| signals/property changes. NumberInput {
| id: width } NumberInput { id: height }
| Label { text: "Area value is: " + width.value *
| height.value // automatically gets updated }
|
| All expressions in the above snippet of code are
| basically Javascript expressions. To accomplish the same
| in pure C++, you'd need to implement some kind of
| observer pattern/manually connect signals and slots
| across objects to allow for updates of dependent values
| (Label's text).
|
| QtQuick is a scenegraph that uses QML to render a GPU
| accelerated UI. Which is what is needed on
| embedded/mobile UIs to get smooth high performant
| animated GUIs. That'd be too ineffecient and cumbersome
| to accomplish with QWidget/C++.
| righthand wrote:
| In QWidget if you use it then it's compiled into the
| application. If you use QML it's always there as far as I
| understand. Please review this post which seems to
| indicate that JS and HTML components are added to a
| project when QML is used.[0] It may not be a full engine
| but as I've previously stated I'm not interested in
| writing things in multiple languages. I want as few extra
| languages as possible. To tell me it's not a browser
| stack then go on about how to use QML you can declare
| pages in HTML and JS that are then compiled into the
| binary that passes data between C++ and JS is entirely
| ignorant of my initial goals. If I wanted to use browser
| technology and JS I would build my app for a browser.
|
| Perhaps these technologies are useful for those who want
| to quickly write a mobile app with slick animations.
| Indeed it is a easy way for Qt to gain audience for those
| types of apps especially for people who aren't able to
| learn C++. For my intentions I am looking for less
| overhead overall to keep files as pure C++ as possible to
| ensure that a class I'm writing represents the full scope
| of it's functionality and domain.
|
| [0] https://news.ycombinator.com/item?id=38395603
| j1elo wrote:
| Where it is that you see "magic"? QML is a markup language
| (just like HTML is for web) which can have inline code in
| it (JavaScript). These QML files are quite literally
| embedded into the binary, loaded in-memory at runtime, and
| processed by a rendering and execution engine. Quite
| similar to how a web browser would render HTML and execute
| JS code. In fact, the latter in QML originally was done by
| V8 itself!
|
| The extra feature of the QML engine wrt. a web browser is
| to provide callbacks and hooks, doing what I guess we could
| call FFI, allowing for events and function calls to travel
| between C++ and JS. Complex, but not much sort of magic in
| there.
|
| As far as I understand, we would draw a parallel between
| QML and what Tauri does. It just embeds a whole interpreter
| into your program, in order to be able to draw the markup
| and run the scripting.
| saidinesh5 wrote:
| For a beginner to Qt (not necessarily programming. not
| even C++. Just Qt.), most of this tends to be magic
| though.
|
| The build system automatically embeds all the QML files
| into the program binary. The QObject system transparently
| adds reflection to C++, using the build system. The
| QmlEngine that keeps track of properties that are in use
| and automatically updating the dependent values, and the
| headaches that come with broken bindings.
|
| Not saying it is a big deal to learn or anything, but a
| lot of this stuff is not what "traditional C++ devs" are
| used to. I had to teach some new devs "Intro to Qt for
| C++ progammers", so i got to see this from their
| perspective.
| j1elo wrote:
| But that's a knowledge issue. Which is fine, if I can say
| one thing for sure is that none of us was born knowing
| anything at all :-)
|
| C++ programmers would probably be used to lower level
| kind of technologies, but when talking about this I think
| it just helps to think about what would you do if you
| wanted to embed an HTML and JS file into your program and
| wanted it to work like QML works.
|
| For an experienced C++ dev, a list of stuff will
| naturally start flowing through their mind:
|
| * A mechanism to inject the files into the binary upon
| compilation.
|
| * How to interpret the HTML and paint on the screen?
| We'll need an HTML rendering engine and a surface
| painter.
|
| * About JS, how to run it? Well, maybe time to include V8
| into the program. It will take care of running JS code.
|
| * Now to make calls between both languages. Probably V8
| already provides callbacks because it implements FFI
| already for you.
|
| * And other stuff you mentioned, like a property manager
| that remembers what has been registered and creates
| change observers in order to trigger events for C++ to
| know.
|
| Thing is, Qt already gives you all of this done,
| otherwise their proposal of QML wouldn't have gone too
| far...
|
| These series of articles touch on the topic and can
| enlighten a bit about some details:
|
| * https://www.kdab.com/qml-engine-internals-part-1-qml-
| file-lo...
|
| * https://www.kdab.com/qml-engine-internals-
| part-2-bindings/
|
| * https://www.kdab.com/qml-engine-internals-
| part-3-binding-typ...
|
| * https://www.kdab.com/qml-engine-internals-
| part-4-custom-pars...
| photoGrant wrote:
| The reality behind 'Magic' is always a 'Knowledge' issue
| ;-)
| saidinesh5 wrote:
| > But that's a knowledge issue. Which is fine, if I can
| say one thing for sure is that none of us was born
| knowing anything at all :-)
|
| It is just that for them, "non c++" tools ended up doing
| a lot of this magic work. Plus the idea of "embedding
| another language or two into a language where i already
| made UI without any fuss" tended to keep some of the more
| experienced C++ devs away from QML in my experience.
| Giving them tasks like animating the UI, writing custom
| styles etc.. that's where QML converted more C++ devs in
| my experience.
|
| Those kdab blogposts were indeed very helpful for us back
| then.
| righthand wrote:
| No offense to Qt but if I wanted any of that I'd write my
| app for a browser. There is very little benefit to write
| something that works just like a browser with extra
| overhead when I'm trying to write in C++.
|
| That's usually what people mean by magic, extra
| complexity that is not apparently beneficial even when
| partially understood.
| jwells89 wrote:
| I might be misunderstanding something but last I played with
| it, it seemed like the stock QML controls were extremely
| barebones and required either rolling your own or pulling in a
| library of third party QML controls for pretty basic stuff,
| which is a bit strange compared to the the range of controls
| provided by Qt Widgets and a turnoff for anybody looking for
| something a little more "batteries included".
| saidinesh5 wrote:
| Officially, There were QtQuickControls:
| https://doc.qt.io/qt-6/qtquickcontrols-index.html . No one i
| knew really cared for them though.
|
| Most of the time, QtQuick was meant to target embedded/mobile
| world, while QtWidgets - desktop. QtQuickControls 1.0 have
| been a dumpster fire anyway. So we had to write our own for
| performance reasons. QtQuickControls 2.0 were a bit of a
| licensing headache iirc. (Most of the companies i worked for
| stuck with Qt5.6 for licensing reasons).
| sho_hn wrote:
| Qt Quick Controls still exist and are supported and
| actively developed - in the 2.x version range, since 2016.
| saidinesh5 wrote:
| Yeah but they were officially released with Qt 5.7 no?
| iirc they had a different license too. LGPL v3 was a
| problem for most of the companies i worked for back then.
| None of them purchased a commercial Qt license. The
| situation was so weird that even during 2021, they were
| just using Qt 5.6. Slowly they started moving away to
| Electron and other tech. (devs were cheaper/easier to
| find).
|
| The closest thing to QQC 2.0 we had was something called
| QSkinny. Every Qt < 5.6 project I worked on, we ended up
| reimplementing the same common widgets. 4-5 times. I lost
| track of things after that.
| righthand wrote:
| I have very little experience with QML but from what I saw
| was that it was more barebones than widgets and offered
| little advantage over UIC which I also don't use for the
| reasons stated above.
| sho_hn wrote:
| > I might be misunderstanding something but last I played
| with it
|
| I'd say this is a fair description of a point in the past,
| but these days Qt Quick Controls 2 (which is bundled) is
| fairly well-featured, and they do keep adding new features
| release-by-release. It's not far from parity with Qt Widgets,
| and some things it does significantly better (e.g. animation
| or complex input handling).
| hermitcrab wrote:
| I use Qt Creator most days (version 10). It is a great piece of
| software. Although it seems rather slow recently (due to Clang-
| Tidy?).
| rubymamis wrote:
| A very welcomed release. I love Qt. I'm building a note-taking
| app with an advance block editor (so you could write some text
| and have a Kanban in the same view). The model is in C++ and the
| view is built with QML and I absolutely love that combo. In less
| than 20 days I managed to have all the basics ready (including
| multi block selection, support for different block types, etc).
| You can check it out here: https://www.get-plume.com/.
|
| I can't recommend Qt more!
| saidinesh5 wrote:
| Good to see QML being more ready for desktop use cases than
| what I remember... Out of curiosity, what component library did
| you use with QML?
| rubymamis wrote:
| Nothing fancy, just the built-in ones. The rest I customize
| myself (very easy to do).
| bravetraveler wrote:
| Fedora already has it built/released _(on F39, at least)_
|
| edit: _12.0.0-0.2_ appears to be _-beta1_ on closer look :D
| api wrote:
| Qt itself is nice but C++ is just not the greatest language for
| building GUI apps.
|
| I'd love to see support for Go or Rust. Go seems particularly
| well suited and would be extremely productive for this kind of
| programming.
| jcelerier wrote:
| For Rust it's not that easy: Qt's basic model is a tree of
| widgets, where the parents know (and own) their children aaand
| the children also know their parents, which from what I
| understood creates ownership cycles (all handled automatically
| by Qt obviously but the Rust borrow checker cannot really be
| made aware of it). Basically a lot of ownership transfer
| happens behind the scene in Qt to make sure that things "just
| work" and that you don't have to call delete manually for each
| widget.
| api wrote:
| You'd probably use Arc or create a special custom smart
| pointer in Rust for use with the Qt paradigm. Simple
| references probably would not be expressive enough for Qt.
|
| Qt objects have to be heap allocated anyway so you would not
| be adding much overhead. If you designed a specialized
| container it could probably be zero overhead.
| jcelerier wrote:
| Well that's the thing, Qt already has its smart pointer
| types which work with the QObject system - e.g. QPointer.
| You certainly wouldn't want to have a double layer of
| indirection, just like std::shared_ptr<QStuff> is an
| antipattern
| aatd86 wrote:
| I'm currently building something in Go that should eventually
| work with Qt as one of the underlying drivers if that's
| possible.
|
| I'm a bit afraid of the FFI costs but I will look into the
| nitty gritty later.
|
| There is always possibilities for the electron/tauri/wails
| route if all else fails.
| saidinesh5 wrote:
| Rust has quite decent support for QML though. One of the really
| famous video footage stabilizer apps uses Rust with QML:
| https://docs.gyroflow.xyz/app/technical-details/used-
| technol..., and that is a non trivial UI: https://gyroflow.xyz/
| j1elo wrote:
| Having been involved as a C++/Qt developer for years, I also
| agree that C++ is a big hindrance for adoption of Qt.
|
| I totally understand that nobody would want to learn C++, of
| all languages, in order to make their pet music collection
| manager, or whatever other app. I'd wager for 95% of apps, the
| fine control over memory and resources is just a premature
| optimization, and only brings friction by requiring to learn an
| arguably difficult to master language.
|
| Go would be a great choice for general application development.
| Of course you might want to use C++ or Rust for a complex video
| editing package or something demanding like that... but to make
| the To-Do or Calculator app _du jour_ , having to learn those
| languages is overkill. I guess that's also why there are so
| many Electron-based applications.
|
| In general, having a garbage collector is a huge productivity
| boon, while not having to distribute a runtime interpreter
| (that's why I didn't mention Python) is also great.
| zerr wrote:
| The main downside of becoming a C++ dev is that all of other
| languages seem so inferior.
| jenadine wrote:
| If you want to use Rust, you can use the Slint toolkit. It is
| really similar to QML.
| bkinman wrote:
| I'm really happy that slint exists. I hope it gains traction.
|
| I'm writing some data exploration/visualization tooling with
| it.
|
| I really appreciate the permissive licensing vs Qt.
| xrd wrote:
| Great recommendation. Thanks!
| justin66 wrote:
| > C++ is just not the greatest language for building GUI apps.
|
| Compared to the other languages you listed, it demonstrably is.
| They've been around for over 10 years and aren't used much for
| the purpose. Maybe Rust and Go just aren't good (let alone
| great) for building GUI apps.
| pjmlp wrote:
| Anyone left stranded with Microsoft 's decisions regarding C++
| GUIs, only has C++ Builder and Qt, as frameworks that combine
| C++'s capabilities with high productivity tooling like for Java
| and .NET.
| dist-epoch wrote:
| You misspelled Electron.
|
| I can't remember the last time I saw a new Qt app.
| speedgoose wrote:
| The Tesla GUI in the car is made using Qt and it's arguably
| one of the best. But I agree almost everyone go with
| Electron.
| pjmlp wrote:
| Eletron, when one cares more about themselves than their
| users. (TM)
| alostpuppy wrote:
| That should be a shirt
| sho_hn wrote:
| Ditto Mercedes.
| jeroenhd wrote:
| Tesla using Qt for GUI while SpaceX uses Electron shows how
| crazy modern UI development has become.
| inferiorhuman wrote:
| As much as Tesla's well known for thumbing their nose at
| safety, Qt has variants designed for safety critical
| things like instrument clusters. Whoever owns Qt these
| days even calls out instrument clusters specifically.
|
| Electron has none of that.
| zik wrote:
| Not to mention how slow Electron would run on the
| embedded CPU on the Tesla dash board.
| adhamsalama wrote:
| All KDE apps!
| pjmlp wrote:
| Linux user I guess.
| Barrin92 wrote:
| The Telegram Desktop client is a Qt app as well. (and about
| ten times snappier than any other messengers desktop client)
| Rochus wrote:
| And LeanQt of course.
| rsp1984 wrote:
| Long time Qt / Creator user here (15+ years). Qt Creator used to
| be the best C++ IDE by a mile and it's still pretty competitive
| (yes, you can use it without any Qt whatsoever!), however these
| days I am very unexcited about new releases of it. It looks like
| the Qt team prioritizes ever more features (who's asking for
| these!?) and bloat over fixing even the most basic of bugs. It's
| really baffling.
|
| The Qt Creator bug tracker [1] is bursting at the seams but
| nobody seems to really care. 5+ years old, very reproducible,
| very annoying bugs are being ignored by the 100s.
|
| Here's an idea: can we have a feature freeze for like 1 or 2
| years and _only_ solve bugs / tech debt? There's no new feature
| that you could put into Qt Creator that I'd prefer over bugfixes.
| None.
|
| Eike, or others from the Qt team, if you're reading this, please
| give it a thought. You have a fantastic IDE and it's painful
| seeing it degrade so much. Thank you.
|
| [1] https://bugreports.qt.io/projects/QTCREATORBUG/issues/
| nly wrote:
| They should just give up and add the features that are
| compelling to Code via extensions.
| octorian wrote:
| Okay, this makes me think of QTBUG-56214, which has to do with
| Qt Creator suddenly not recognizing mouse scroll wheel events
| after a while. (often as a result of various device state
| changes common if you use a KVM on your machine)
|
| Been following the issue for years, apparently it was marked as
| fixed a few months ago, but the issue is clearly still there. I
| wonder if this latest Qt Creator update will finally
| incorporate the fix, or if its not really fixed.
| jclay wrote:
| We build meldstudio.co (a performance oriented desktop app) using
| Qt/QML and managed to entirely avoid Qt Creator. It's like
| traveling back in time coming from a VS Code configured with
| clangd and LLDB debugger.
|
| Really wish they would invest in getting QML LSP to a working
| state. It's been in development for well over a year now and
| still not used by Qt Creator itself. qmlls is missing proper
| formatting support, syntax aware highlighting (although we paid a
| contributor to land this upstream over a year ago, the PR is
| still pending). It has unusable latency compared to other LSPs,
| the list goes on.
| snvzz wrote:
| I wonder whether it supports normal (as in, vscode-like) tab
| switch behavior these days.
|
| When I tried it a few years ago, it forced some history-based
| keyboard tab switching, rather than behaving like everything
| else.
| mardifoufs wrote:
| Sadly QT designer is still a complete trainwreck that doesn't
| seem to have been updated in a decade. It's so sad because it
| could be very very useful, but the entire way it works just makes
| it hard to use. Adding widgets is messy, using them in code is
| messy, there's no way to combine both and see the results, the
| way you handle/modify the objects themselves is super unwieldy...
| it's no wonder why desktop GUIs are getting overtaken by web
| based apps.
___________________________________________________________________
(page generated 2023-11-23 23:02 UTC)