[HN Gopher] Qt Creator 10 Released
___________________________________________________________________
Qt Creator 10 Released
Author : jandeboevrie
Score : 70 points
Date : 2023-03-29 18:22 UTC (4 hours ago)
(HTM) web link (www.qt.io)
(TXT) w3m dump (www.qt.io)
| sciurus wrote:
| > Qt Creator is a cross-platform, complete integrated development
| environment (IDE) for application developers to create
| applications for multiple desktop, embedded, and mobile device
| platforms, such as Android and iOS. It is available for Linux,
| macOS and Windows operating systems... In addition, you can use
| the experimental WebAssembly plugin to build applications in web
| format and run them in web browsers.
|
| From https://doc.qt.io/qtcreator/index.html
| smallstepforman wrote:
| Dont forget the BSD's and Haiku. I use QtCreator under Haiku
| and its a really well behaved app.
| kugelblitz wrote:
| Whoa! What a blast from the past! I remember using Qt in ca. 2002
| when interning for a robotics institute. My advisor wasn't
| available for the first week or two so I had free reign to do
| what I want. I ended up using Qt to create a robot simulator
| which uses laser eyes to navigate through a simple maze of
| obstacles.
|
| It was a super-simple algorithm (I'm hardly the scientist, more
| like a pragmatic developer), but it seemed as if it were doing
| complex things and Qt helped make it look relatively cool even
| with my basic coding abilities.
|
| Finally, first time I can contribute a "I remember a couple of
| decades ago when I was using tool X". I'm a web dev now and I
| have a more laid back stance regarding new tech, so I never write
| "Oh, I wrote a SPA-transpiled prototype with RustJs 0.0.4rc" or
| whatever (been burned too many times; e.g. bower, grunt, gulp,
| AngularJS 1, etc).
| synergy20 wrote:
| flutter + dart might be an alternative to Qt these days for cross
| platform GUIs, which is what I'm learning these days, in addition
| to desktop it does mobile platforms as well.
| pier25 wrote:
| Yeah and they are integrating the Rive 2d vector graphics
| engine into Flutter which is way faster than Skia (and QT).
|
| https://twitter.com/guidorosso/status/1639080101186011136
|
| https://twitter.com/guidorosso/status/1595187838454140928
| AbuAssar wrote:
| would you please share where he says that they are
| integrating the Rive 2d vector graphics engine into Flutter
| pier25 wrote:
| It's in the first thread I shared.
|
| This tweet in particular:
|
| https://twitter.com/guidorosso/status/1639080107301306369
| sho_hn wrote:
| What OP means is that everything there suggests the Riva
| folks are releasing their tech for Flutter as an add-on,
| while your original comment suggests the Flutter project
| is adopting/integrating this tech inside Flutter. I was
| also confused.
| pier25 wrote:
| Oh I'm very sorry for the confusion...
| schaefer wrote:
| Rive looks so amazing! But tragically, no Linux client.
|
| /sigh
| not_your_vase wrote:
| Note that this is about Qt Creator, and not Qt. Though it is
| created by Qt company primarily to work with Qt, it is a very
| capable C/C++ IDE on its own right, even if you don't use Qt at
| all.
| karmakaze wrote:
| So Qt is both a cross-platform toolkit and a brand of
| development tool? That seems confusing being not tied to
| using the Qt toolkit.
| sho_hn wrote:
| It's more a side-effect.
|
| Qt is a C++ toolkit, and Qt-based projects are either C++,
| or use the QML markup language, or both.
|
| Projects that use Qt for the GUI or use other Qt modules
| often also use other C/C++ libraries (for example, in-house
| stuff) and they're often hacked on together.
|
| Therefore the free IDE you can get for Qt also happens to
| be a very good C/C++ IDE/editor.
|
| Qt uses CMake as its native built system - arguably CMake
| was popularized in general when KDE adopted it, a large
| FOSS user of Qt. CMake is not Qt-specific, and many other
| C/C++ libs use or integrate well with CMake. Therefore Qt's
| free IDE is also very good at general CMake support.
|
| Qt is often used for embedded or heavier IoT projects,
| therefore the IDE has useful features for deployment and
| remote debugging that also work for other stuff. And so on.
|
| The Qt Company doesn't really push/advertise Qt Creator
| much as an independent product, but the utility is really
| not bad.
| karmakaze wrote:
| I'm guessing that the part that would make it make sense
| for me is that the Qt Creator is made by the team that
| makes Qt or something in that ecosystem that's a label
| they give themselves. For instance I wouldn't call an IDE
| I made, Swing Creator if it was made with Java Swing but
| I had no other association.
| sho_hn wrote:
| Make no mistake, the main reason Qt Creator exists is to
| enable and promote Qt-based development and tick a box
| when selling to customers. They don't sell Creator
| individually (it's free), so they don't really make money
| from it outside of Qt sales.
|
| Qt competes for major business in markets like automotive
| or general embedded, where vendor frameworks are from the
| "one-stop solution for Windows" generation that come with
| IDEs aimed at specialists that get trained to use them,
| e.g. because they have a mechatronics/Simulink/etc
| background more than a programming one. Or because
| they're designers and used to Photoshop/Figma and you
| need something you can import into. These are often
| horribly old and crufty Eclipse derivatives or even OG
| Win32 MFC apps.
|
| Examples would be boutique solutions you've never ever
| heard of but probably used or seen in a car, e.g. the
| Kanzi toolkit, or STM's TouchGFX for microcontrollers.
|
| So Qt decided to make one too to round out the value
| prop.
|
| It's just that Qt (a) grew up originally as a desktop UI
| toolkit for PCs (so using it for a desktop app works out)
| and (b) is on a much cleaner, much more general-purpose
| tech stack, so it happens to actually be fairly good and
| reasonably general-purpose. Partly also because the Qt
| folks who wrote it simply used other desktop IDEs or
| classic hacker's editors before and decided to make a IDE
| they would themselves like to use.
|
| That said, The Qt Company has more recently done some
| acquisitions that actually do go more into the direction
| of branching out into development tools. They acquired
| Froglogic, makers of Squish (a GUI unit testing framework
| in wide use) and also a Coverity-like code scanner. So
| who knows, maybe they'll reposition Creator a bit.
| karmakaze wrote:
| If you don't mind my indulgence, does Qt Creator have any
| features specific to developing with Qt? Along the lines
| of Xcode being able to edit resources or graphically
| connect components, etc? Even a specialized search that's
| better at finding Qt things. That would take away all
| ambiguity.
| sho_hn wrote:
| Yes. Qt as a framework comes with a built-in declarative
| markup language called QML (a superset of ECMAScript).
| Full IDE support for QML including debugging/profiling
| and also a visual design/editing mode are unique to Qt
| Creator.
|
| You can use Qt Creator while ignoring or perhaps even
| without realizing this is there (since also many, though
| increasingly fewer, Qt apps are written in pure C++
| without any QML use), but if you do use Qt, it's of
| course a large potential value add.
| synergy20 wrote:
| vscode is eating the world these days, unless I use QT
| libs, vscode might be a better alternative for c++ IDE
| now?
| dekhn wrote:
| I use VSCode to develop Qt apps; I tried qt creator but
| like Eclipse and NetBeans, I found them to be "less
| general".
|
| The one tool I truly love is Qt Designer, which is a GUI
| designer that outputs declarative config for the GUI, but
| also makes it easy to plug in custom classes for special
| widgets. It's the most rational and practical GUI
| designer I've used.
| [deleted]
| saidinesh5 wrote:
| I think you have it the other way around. In addition to mobile
| platforms, flutter tries to do desktop too.
| pjmlp wrote:
| C++ is useful outside Qt, one of the top languages on the
| industry, Dart on the other hand...
| kernal wrote:
| >Dart on the other hand
|
| Is a better language than Java.
| pjmlp wrote:
| Only if stuck in legacy Java 8, and even then, Java is more
| useful than Dart.
| dekhn wrote:
| by the time flutter and dart expire, Qt will still be embedded
| in billions of cars and military devices.
| Eumenes wrote:
| It'd be cool if there were native ways to use a Zapier or IFTTT
| with a Qt
| jbirer wrote:
| I love how "professional" Qt code and API feels compared to GTK+
| and how their team is not involved in any political drama. Always
| a joy to use their products.
| jeroenhd wrote:
| I kind of disagree. GTK+ gets a lot of (sometimes deserved)
| flak for their API choices but Qt isn't all that different.
| They have plenty of weird legacy APIs, design choices, and
| restrictions on their API design so they can keep selling their
| paid products.
|
| With GTK+ you get a Gitlab issue where everyone from GTK+
| developers to /g/ users spout their opinions and then
| eventually the team and the developers take a decision that's
| probably going against at least half the comments in the
| thread.
|
| With Qt you get "this is the API, live with it". I'd describe
| its API design method close(r) to the Windows API than any open
| source API I know of.
|
| Sure, it creates a lot less drama, but at the cost of openness.
|
| I'm not a fan of any Linux UI design toolkit, but I found GNOME
| Builder to be much more intuitive and working better out of the
| box than Qt Creator. GNOME's UI language may be... a choice,
| but Qt applications often feel like toy UIs or those fake
| operating systems you find in games without some pretty
| deliberate planning (and styling). With libadwaita being
| brought into GTK+ I think neither looks any good out of the box
| now, but the tooling for GNOME seems a lot better at least.
|
| In terms of API and tooling support, I don't think any open
| projects come close to what Microsoft did with Visual Studio
| and C# back in 2005.
| sho_hn wrote:
| > With Qt you get "this is the API, live with it".
|
| This is true often, but not always. Quite a bit of Qt APIs
| get created collaboratively on gerrit; I've had API changed
| based on my input. It's also possible to contribute APIs;
| I've done that, too. Some bigger new modules or API surface
| area is also moved through Qt Labs first before becoming part
| of the product, making for a longer feedback period. We've
| also had Qt folks actively attending events like Akademy to
| demo new WIP APIs and gather feedback and feature requests
| and engage in PoC ports of real software. There's also venues
| like the annual Qt Contributor Summit for larger discussions.
|
| You're right that this open approach is not the only channel
| for APIs into Qt, and in hybrid communities like his there's
| always some tension, and of course having to be a little "in
| the know" or engaged in the community means there's perhaps a
| higher barrier to entry in some ways. I respect not liking
| that and preferring if there's only a community-based
| channel.
|
| It's also worth pointing out that for the most part, Qt has a
| fairly healthy approach to low/mid/high level customizability
| and extensibility to its API. It has internalized this as one
| of the reasons for its success, even if it sadly fell a bit
| by the wayside during the early Qt Quick years. That means
| that "this is the API, live with it" is not really a
| straitjacket - you get to override, supplant, extend a lot.
| guerrilla wrote:
| > With libadwaita being brought into GTK+ I think neither
| looks any good out of the box now, but the tooling for GNOME
| seems a lot better at least.
|
| Yeah, this is the part that hurts. So much work done on the
| backend and so many great apps, then to lock everything into
| that...
| zorr wrote:
| What is the problem with libadwaita?
| sho_hn wrote:
| There's plenty of political drama around Qt.
|
| Not a fan of comments that praise product A with some sort of
| vaguely axe-grinding reference to product B.
| jmnicolas wrote:
| They're both C++ though.
|
| Bindings aren't ideal, I wish there was a native Linux gui
| toolkit with a "sane" language.
| FpUser wrote:
| Try Lazarus FreePascal IDE. Has extensive GUI you can design
| visually
| smallstepforman wrote:
| > They're both C++ though.
|
| I'd argue that Qt API is pre-C++98, ie. pre std template
| library. Qt uses its own classes (vector, string, etc)
| instead of std template library. Even the MOC can be
| eliminated with the STL. Its an ancient API which is separate
| from modern post C++11. They've tried adding some STL and
| C++11 concepts, but they have millions of lines of legacy
| code to support, so its just more layers and bloat.
| sho_hn wrote:
| You're not completely wrong, but I think this overstating
| things by a lot. I'll grant you the containers for example,
| but you can generally use STL algorithms with them. And
| plenty of old ways of doing things have left modern Qt-
| based codebases and moved to more modern ways of doing
| things, including a fair amount of moc macro usage (and
| yes, you can remove the moc these days, but it has
| different perf characteristics - cf. the verdigris
| project).
|
| The community around Qt is pretty active at adopting modern
| C++, e.g. imho https://github.com/danvratil/qcoro is
| leading work.
|
| I'm glad that folks clamor for keeping things fresh, but
| every 30 year old project is going to span a few minor
| revolutions along the way.
| BearOso wrote:
| Gtk is C, but it's introspected in a way that it generates
| really good bindings for other languages. gtkmm and gtk-rs
| are really good.
|
| Qt _is_ C++ through and through. Even more so because of its
| MOC. It 's really hard to port to other languages.
|
| If we wanted a standard toolkit for Linux, it'd have to be
| written C to be compatible with most FFIs. The problem with
| Gtk is it's in coalition with Gnome, and its developers shun
| anything not fitting that scope.
| sho_hn wrote:
| > Even more so because of its MOC.
|
| Ho-humm, I'd argue that specific point. The meta-object
| system adds introspection and reflection, and helps it get
| e.g. fantastic Python bindings. Various other bindings are
| also basically built around wrapping QObject+QMetaObject.
|
| Yes, binding Qt is anyway harder than GTK's C API. But not
| because of the MOC.
| BearOso wrote:
| That's an interesting point. I hadn't thought about the
| MOC helping introspection.
| cglong wrote:
| Having never written using any of these technologies, I was
| wondering how ergonomic GTK would be in Rust. Isn't GTK
| very object-oriented in its design?
| zorr wrote:
| Check out the gtk-rs project which provides the Rust
| bindings.
| lelanthran wrote:
| > They're both C++ though.
|
| One of them is.
|
| > Bindings aren't ideal, I wish there was a native Linux gui
| toolkit with a "sane" language.
|
| There's none, because all the linux GUI toolkit developers
| are "sane" enough to make the toolkit x-platform.
|
| If you're looking for "something that runs on linux, and
| linux only, and nowhere else" you are not going to find
| anything the way you find "something that runs on windows,
| and windows only, and nowhere else".
| zorr wrote:
| GTK has bindings to modern languages. The gtk-rs project is
| actively working on Rust bindings. I'm personally working
| with some others on Kotlin Native bindings and I know a new
| JVM effort is in progress using the new JVM FFI
| capabilities.
| favsq wrote:
| >One of them is.
|
| None of them I'd say. I'd argue moc is not C++
| dekhn wrote:
| moc is the part of C++ the standards folks didn't see a
| need to integrate, but it should have always been there.
| Since all it does is take syntactic sugar and output more
| C++, it's clearly C++.
|
| of course, C++ eventually gained the ability to implement
| moc natively using a more general solution.
|
| to me, moc and the Qt base classes sort of round out C++
| to me in a way that is better than the alternatives. I
| can imagine an entire world of application development
| based on Qt C++ base, and in fact I've written a few
| network servers this way. Simply having event loops with
| message passing built-in makes programming that much more
| enjoyable for me.
| sho_hn wrote:
| There's a lot of overstated FUD about the moc. It's a
| preprocessor that expands a few macro strings into
| relatively simple boilerplate C++. Yes, it's a separate
| little preprocessor binary instead of using C++'s built-
| in macro system, but the concept itself is not foreign to
| C++.
|
| The macro incantations aren't massively complicated and
| mostly are simple labels placed in header files; body
| code rarely uses anything moc-related these days.
|
| Compared to the crazy stuff Microsoft has done over the
| years within and on top of C++ on their platform, Qt's
| moc is barely a footnote.
|
| I respect not liking it, and I totally get the appeal of
| doing the same thing with tools built directly into the
| language (which to this day aren't fully comparable, and
| are mostly recent - check into the verdigris project for
| a solid and interesting take on attempting this), but
| it's a reasonably straight-forward approach to the
| problems it solves.
| simplotek wrote:
| > Yes, it's a separate little preprocessor binary instead
| of using C++'s built-in macro system, but the concept
| itself is not foreign to C++.
|
| It does have it's drawbacks. The MOC heavily penalizes
| build times, and build caching tools like ccache don't
| work out of the box with it. So not only does the MOC
| worsens builds, it also prevents basic optimizations from
| mitigating it.
|
| > Compared to the crazy stuff Microsoft has done over the
| years (...)
|
| Microsoft did a fantastic job with it's GUI frameworks.
| WPF is a stellar example of getting most things right.
| It's astounding how views are so trivial with WPF. XAML
| voodoo has it's critics but no one praising Qt would ever
| dare point a finger at XAML.
| sho_hn wrote:
| GTK+ is C. There's C++ bindings (gtkmm), but they don't have
| a lot of uptake.
| saidinesh5 wrote:
| With Qt, the drama has been usually around licensing, GPL
| fearmongering etc.. That being said I do like their API design
| guidelines ( https://wiki.qt.io/API_Design_Principles ) and
| coding conventions ( https://wiki.qt.io/Coding_Conventions ).
| Valuable read for any developer.
| LeSaucy wrote:
| Formatting goes bonkers when using arrow functions in qml :(
| nokeya wrote:
| They mentioned my tiny contribution and my name in changelog. Now
| I can die peacefully (:
___________________________________________________________________
(page generated 2023-03-29 23:02 UTC)