Qt Getting In On Generative AI, Starts By Adding GitHub Copilot To Qt Creator

[lowflyer]

The GitHub Copilot integration makes developers more effective when writing code, allowing them to focus on the business logic instead of reinventing the wheel.

Snake oil to lure corporate IT managers into contracts - and the poor software developers two levels down have to save the ship from sinking. It's a computer assisted approach like the "to increase the efficiency of the software developers they have to type faster" approach.

I don't have high hopes, seeing how much crap AI produces in a short time.

[patrick1946]

QML should have been its own thing, it should have been 100% natively interoperable with C++, instead they went for the mediocrity that is V8, which turned out too slow for small expressions, so they had to supplement it with their own V4, which they now have a convoluted way to convert "back" to a 10 times more C++ code than it takes to write the damn thing, and now they have to re-implement almost the entire qtquick engine halfway through version 6 in hopes to make the while mess a tad more efficient.

Qml was invented 15 years ago. WebApps with JavaScript were hyped everywhere. So I imagine there were people inside Qt which were hyping JavaScript too. What you can clearly can see is that Qml was designed declarative but then they added JavaScript on top and it got messy. Even if they would add C++ it would have been messy. If you want to use a tool for GUI development random expression will break it. That is in my opinion the biggest drawback of Qml. It was designed from programmers for programmers and not for designers.

And they added Qt for MCU which is a complete different implementation which is not not anymore using JavaScript or QObject. But most people don't see it because it is marketed to embedded devices.

[bug77]

TableView was only introduced late in Qt 5.x, if I remember correctly Qt 5.10 (or whatever we used at the time) didn't have it. Mind you, that was still many, many years after the introduction of Quick and QML, and it was already advertised as a full replacement for QWidgets all over the place... and that's just one example. Qt Quick Controls 2 had MANY deficiencies and not all of them were fixed when we decided to stop using Qt.

I'm sure lots of improvements were made in the meantime, but you still inevitably end up with a C++/JavaScript hybrid software with QML that is nearly impossible to debug properly.

Edit: you linked to the Qt Quick Controls 1 implementation. Qt Quick has two different component libraries: Qt Quick Controls 1.x and 2.x. It should be noted that we used Qt Quick Controls 2.x, because the QQC 1.x was already considered deprecated at the time and was missing other things we needed. You cannot really mix 1.x and 2.x components, that results in a serious visual clash and other issues. I don't understand why they even made two completely separate component libraries in such a short timeframe.

So you had a means to handle tables since Qt 5.1. The means to handle tables in Controls2 seems to have landed in 5.12: https://doc.qt.io/qt-5/qml-qtquick-tableview.html
I feel that somehow you drew the short straw here.

[ssokolow]

You probably haven't suffer through it enough to actually know it. I loathed QML initially, but today I wouldn't touch the widget stack with a 10 feet pole. The key is to really develop your own framework on top of QML, and focus on what you need, rather than prolifically using each and every redundant convenience stock component, where bugs, design limitations and omissions eventually cascade into problems the moment your complexity scope exceeds the rather limited complexity scope of the component's design.

If you love the widgets look that much, QML has a fairly comprehensive support for traditional look, there are very few corner cases that might not be supported, but usually it is not hard to work around that.. And the GUI is not all that hard to setup, and way easier to implement than with the widgets stack, given that you are still free to keep your entire logic layer C++ only.

QML can very effectively be applied to pretty much everything where performance is not critical, not just GUI, and to greater flexibility and faster development time. It is all about properly designing you code, not that much what framework or language it uses.

Yes QML is a tad more bloated, but widgets are not far behind, as most of that bloat is QObject anyway, Nowadays it doesn't matter that much, I personally don't see QML applications lagging significantly behind OS native applications in terms of performance or efficiency metrics. In fact, there are many native apps that work way way worse than the stuff I make with QML.

Or, I could just use QWidget and not go back to the "PyGTK requires people to reinvent having both multi-select and drag-and-drop in an MVC widget at the same time" that drove me to Qt in the first place.

Seriously. It's 2023. It's shameful that I have to fight the defaults to make a Qt Quick UI not feel like a bad port of an Android app.

...plus, MyPy with strict mode gets me closer to doing everything with the protection of Rust's type system than QML does. I have no interest in regressing on that front. I'd choose Python/Rust (via the PyO3 crate) over QML/C++ or QML/Rust (via the qmetaobject crate) any day.

It's not about the bloat. It's about the amount of work I have to do to make the application meet my quality and maintainability standards... standards where QML is a fundamentally flawed concept because I don't want "Electron UI without the flawed Electron undercarriage". Having to reinvent and debug the platform HIG without getting paid to do so is the problem and, after having been burned by it so many times, I don't want to be a hypocrite about "I've implemented all the platform-native UX features that I'm aware of".

Even Apple is struggling to meet that bar with their SwiftUI rewrite.

I keep coming back to Joel Spolsky's Things You Should Never Do, Part I, written in response to Netscape Navigator 6 being a rewrite.

[brent]

So you had a means to handle tables since Qt 5.1. The means to handle tables in Controls2 seems to have landed in 5.12: https://doc.qt.io/qt-5/qml-qtquick-tableview.html
I feel that somehow you drew the short straw here.

We just followed best practices and recommendations from the docs. At the time, QWidgets was long considered outdated and QQC 1.x was just declared deprecated as well. QQC 2.x, the "new shiny", was recommended for new projects. So we used it. Missing TableView was just one issue, there was more but I don't really remember. We also encountered significant issues when we later updated to a newer Qt version. After a few years our project was stopped altogether.

[ddriver]

....

Your problem appears to be relying too much on stock functionality over trivialities you can easily do your own way in a couple of lines, packaged inside a unit under your control.

I reckon the bulk of provided functionality is useless or not worth using, but that's just the design of components, in my experience QML itself is ok, a good supplementary for c++, it is just that the qml stock components are all over the place, and not overly well designed, there's a specific component to do almost each and every specific thing, rather than emphasizing on a smaller but more versatile and general purpose toolset.

It is fairly easy to even make your qml apis c++ compatible if you design your stuff right, using the same naming, use functions instead of operators, wrap pointer access in GADGETs to unify member access operator, and most of the code can simply be copy pasted from qml after prototyping right into c++.

Rewrites are not that bad, but the real insights come after 6-7 rewrites. I was able to distill a project of around 200k lines to 5k, but it was a very incremental process. And each rewrite was not simply because it had to be cleaned up and freshened a bit, but because of a fundamental architectural redesign.

That much redesign process taught me one thing - never ever use ANYTHING 3rd party directly in your code - always wrapped, always peripheral, always under control and re-implementable, that's the key to using Qt and qml safely. You simply have to refuse the temptation to indulge the "Qt experience" and go for your own, routed through whatever framework you are using has to offer.

4-5 years ago I was quite sure QML was itself broken as a technology and unreliable, because of so many bugs and limitations hitting design blockage, but it turns out the problem was trying to "freestyle" but doing it in the "Qt way" - the stock library just doesn't cut it - the design scope of components is quite limited, there are many unanticipated and untested usage combinations. so the moment you exceed trivial complexity it becomes a cascade of bugs and limitations.

But I eventually learned to do it right, and as soon as I stopped leaning on QML and using it more conservatively, turns out it is a perfectly capable front end / structure / configuration tool, and prototyping is way, way faster than c++ and widgets or graphics view.

[Nth_man]

I'm not a developer, but as an end user, Qt-based desktops and apps are my favorite.

Yes, Kate, Konsole, Okular, etc. are stable, fast, configurable, free/libre software, free of ads, free of planned obsolescence, free of vendor lock-in, free of spying, free of EULA abuses, free of "give me your phone number", free of malware...

[ssokolow]

Your problem appears to be relying too much on stock functionality over trivialities you can easily do your own way in a couple of lines, packaged inside a unit under your control.

No, my problem is that I don't want to have to break out a HIG document or design some kind of assistive API-based differential fuzzing harness to make sure that whatever I patch together matches platform conventions I don't personally know about and rely on.

If I wanted to write "half of PHP's standard library exists in the comments section of the PHP manual" code, I'd write it.

You seem to be missing that. The reason I consider Electron unacceptable, and have been ejecting GTK 3 apps from my desktop as fast as I can find replacements, is that I have very low tolerance for stuff not harmonizing with KDE UX conventions and I'd be a hypocrite if I just hard-coded KDE conventions in an application I also want to offer to Windows users.

I reckon the bulk of provided functionality is useless or not worth using, but that's just the design of components, in my experience QML itself is ok, a good supplementary for c++, it is just that the qml stock components are all over the place, and not overly well designed, there's a specific component to do almost each and every specific thing, rather than emphasizing on a smaller but more versatile and general purpose toolset.

Yeah, no thanks. I migrated from GTK+ 2.x to PyQt because I was tired of using my own reimplementations of functionality QWidget gave me either out of the box or with three or four lines of glue. I haven't been 20 years old for a long time. I don't daily-drive Gentoo Linux anymore and I also don't write my applications in non-QWidget GUIs for the same reason. Even QWidget+Qt Designer is embarrassingly inefficient compared to what Borland Delphi was doing in 1995.

It is fairly easy to even make your qml apis c++ compatible if you design your stuff right, using the same naming, use functions instead of operators, wrap pointer access in GADGETs to unify member access operator, and most of the code can simply be copy pasted from qml after prototyping right into c++.

I'll interpret that in the most favourable light and assume that all those also apply to Rust as integrated via the qmetaobject binding crate. Aside from the memory-safety, which PyQt can also give me, I use Rust wherever possible for the composability that C and C++ are infamously bad at.

Rewrites are not that bad, but the real insights come after 6-7 rewrites. I was able to distill a project of around 200k lines to 5k, but it was a very incremental process. And each rewrite was not simply because it had to be cleaned up and freshened a bit, but because of a fundamental architectural redesign.

Yeah, I'd rather knock 6-7 different projects off my TODO list, thanks.

That much redesign process taught me one thing - never ever use ANYTHING 3rd party directly in your code - always wrapped, always peripheral, always under control and re-implementable, that's the key to using Qt and qml safely. You simply have to refuse the temptation to indulge the "Qt experience" and go for your own, routed through whatever framework you are using has to offer.

Or, alternatively, write as much of your application as possible in Rust as a library, expose Python bindings using PyO3, and then use Python+MyPy+Ruff as a more statically-verifiable, more native-to-KDE's-UX-and-HIG analogue to QML which can glue together QWidget APIs instead of Qt Quick APIs.

But I eventually learned to do it right, and as soon as I stopped leaning on QML and using it more conservatively, turns out it is a perfectly capable front end / structure / configuration tool, and prototyping is way, way faster than c++ and widgets or graphics view.

Good to hear... sounds like what I get using PyQt as a QML for QWidget on top of a Rust-written backend, but with more wheel-reinvention to make things feel native on KDE and more face-first slams into "QWidget has an implementation of this that would meet my needs... Qt Quick/Kirigami/whatever only gained it in the Qt version from a month after the feature freeze for the lowest Kubuntu LTS I want to support... and I don't feel like developing inside a Flatpak yet."

(Yes, I know the KDE Discover update manager is QML-based using KDE's Kirigami alternative to Qt Quick... it's full of UX papercuts that annoy me.)

[ddriver]

Yeah, I'd rather knock 6-7 different projects off my TODO list, thanks.

Who doesn't, but then again, it is actually a good idea to learn how to design software first, and then knock off projects as you put it, And it is admirable that you even have 6-7 different projects on your list, cuz most programmers I know have ONE - making it through the work day and not having to think about software development till the next.

Consider tho, them 6-7 "different" projects do not necessarily give you better substance than the ONE project, important enough to merit such scrutiny. Doing one critical project right can teach you and reward you way more than a bunch of trivial and non-challenging ones. Yet again, that "quantity over quality" notion. You are kinda like saying "I don't need to fix that heart disease, that's too expensive and requires discipline to form new healthier habits, I'll just fix myself better by getting hair transplants, new dental veneers, color contact lenses and a set of new clothes and shoes. Now that's a way to get tangible results and FAST

Your design is probably way way worse than it needs to be, but then again nobody told you that, because the "standards" in the industry are abysmal. Your own design is usually what impedes you the most, it is the most likely source of issues that you are instead delegating to project onto something else. I did a complete software architecture analysts in my last job - a top player in the industry, a multi billion revenue company - and its code base was quite literally chugged full of wrong practices and anti patterns. It was " industry standard" according to the senior devs, pretty much how it was probably industry practice to have 20 people barely managing to hold together something that, if designed properly, could easily be handled by a couple of devs

There's nothing wrong with rewriting a project 7 times, it is 100% in the ballpark of common to try and fail at least several times before you learn how to do something complicated right. This doesn't mean you have to rewrite EVERY project 7 times to get it right, it means you must make that journey ONCE before you learn. If you always went with what you got, and vent your frustration on your tooling instead, then you will never move forward.

Those guys at my last job - they had also done "a rewrite", I mean that mess that I audited - it was exactly the product of one full rewrite. Because again - the rewrite only served to freshen and clean things a bit, they did not really bother to come up with a better design.

Oh, also, you are not supposed to "keep reinventing and re-implementing" on a per project basis, you do initially, but down the line you realize "oh, I can actually have my own framework I can reuse across". I mean, if you don't write reusable code, you should probably quit.

Always have YOUR clearly defined API, always use your API, never use anything 3rd party directly in your code. Trust me, you don't want want to have to surgically remove something like Qt from your project, because you want to change framework. You can quite easily unify vastly different graphics front ends into a compatible subset and effortlessly migrate as long as you use your API. If you are like them poor sobs at my last gig, this means you have to rewrite 99% of your own GUI code, which itself is a bloated and overly verbose and error prone mess, and probably mess things up in the logic layer that drives it, because of the same lack of sane abstract underlying design.

And finally, keeping dependencies down to a minimum is always a good idea. Writing rust apps which use qt through qml through python and a bunch of other tools to glue legacy stuff together.... what now? Yeah, sounds like a real elegant solution.

And no, you can't "glue together qml functionality" out of qwidgets - a module that doesn't even have a notion of most of the functionality QML provides, you can hack together a rudimentary legacy GUI kit - something that's rather dwindling in popularity and at this point - wildly redundant.

[bug77]

We just followed best practices and recommendations from the docs. At the time, QWidgets was long considered outdated and QQC 1.x was just declared deprecated as well. QQC 2.x, the "new shiny", was recommended for new projects. So we used it. Missing TableView was just one issue, there was more but I don't really remember. We also encountered significant issues when we later updated to a newer Qt version. After a few years our project was stopped altogether.

That does sound like something Qt would do, deprecating stuff before its replacement will reach feature parity. Makes me wonder if they're somehow involved with Wayland