Qt 5.10 released
blog.qt.io
blog.qt.io
I see that when people think of Qt, they think of WxWidgets, Cocoa or MFC as alternatives. No, I submit to you that Qt framework is a more elegant, easier to use alternative to Boost as well.
This is not to say that QtQuick or QtWidgets aren't solid. However, the success of these two modules ends up occluding the others which to me are the real gems from the QtFramework: QtCore and QtNetwork.
QtCore provides a solid event loop, the most easy to use implementation of the observer pattern via its signal-slot mechanism, robust threading utilities and a bunch of other utilities that make writing apps in C++ an absolute breeze.
QtNetwork for a series of networking utilities that are elegantly simple.
If I were to write a command line app or a database or server, I'd reach for Qt in a jiffy.
Qt is not just for GUIs!
It looks like (as of early 2016 at least) it is platform-dependent, which makes sense but kind of takes away the appeal for me.
https://forum.qt.io/topic/57675/which-file-formats-or-codecs...
https://forum.qt.io/topic/63110/list-of-video-formats-qt-sup...
This might help: https://wiki.qt.io/Qt_5.5.0_Multimedia_Backends
If you get a format that all of Directshow(win), AV Foundation(osx) and Gstreamer(linux) support, you're pretty much set. Something like mp4 container with h.264 video and mp3 audio is pretty standard these days.
http://doc.qt.io/qt-5/qabstractsocket.html#waitForBytesWritt...
https://bugreports.qt.io/browse/QTBUG-40332
There is a workaround, but developers have to know about it first. And it's such an unexpected and weird behaviour that 99% of developers don't.
This was our fix (1 line of code), in case that helps anyone:
https://github.com/sqlitebrowser/sqlitebrowser/commit/739464...
For Windows users we now put this var in to global environment via our installer, and probably break other software in the process.
You might also be fixing it for some too, if they're running other Qt applications. :)
This is not the best example. Qt has a lot of overhead in its event loop, threading, parallelism and containers implementations compared to alternatives. It's not the best choice as a base for high performance database.
Now Cocoa would win but I prefer C/C++ to Objective-C, it's close though.
Good work people.
Also, I know this might sound crazy, but what about (f/m)asm?
I don't know what (f/m)asm is in this context, sorry.
It uses the native UI so fits in better with OSes, whereas Qt ones stand out to me (you can see the buttons aren't native). I did a lot of stuff that was "owner drawn" so reimplemented OnPaint to draw things myself for custom-look controls.
wxWidgets dropped its ODBC support a few years back so talking to databases likely needs another library. Also the ports/HTTP section of it isn't massively useful so I use libCurl instead.
Despite the bugs, it is quick to build and I found working with it enjoyable. Some controls (like the wxDataViewCtrl I think) were really slow so I wrote my own; the OpenGL wrapper works alright but I had to put some work into forcing it to resize; basically be prepared to put some work in - but it is rewarding. I like the layout mechanism - makes other systems like MFC look poor!
You can build wxWidgets and force it to use the STL for its container classes etc; Qt appears to implement everything again instead of just using the existing STL I think.
The developers are helpful and the forum is useful, at least for basic problems. I enjoy(ed) using it anyway.
I think Qt wins in all other domains though. Documentation, extensiveness and quality of the non-GUI stuff, etc.
But not having native widgets kinda sucks. You can see that when you make that compromise, the question comes why not to use Electron (which is a competitor of those two in reality).
It follows the path of Turbo Vision, OWL and VCL.
Where productivity comes first, and C style tricks are only done when performance really matters.
Many C++ APIs suffered from std not being rich enough, and lots of Cisms in the early days.
Nowadays with all major OS vendors switching to safer languages for the UI layer, Qt seems to be the last C++ GUI framework in widespread usage.
The stdlib doesn't have anything to use files.
The C win32 API CreateFile() has 6 arguments each more obscure than the previous one. Gotta support sync and async in a single function.
The C kernel API NtCreateFile() has around 13 arguments, probably including enum with 105 different values.
It also has the QFileInfo class to retrieve file info, such as creation/last-modified/last-accessed date.
It just seems super weird to not also have the matching functions available to set those dates. Which we really wanted for our client side Qt/C++ GUI, as I'd just finished doing the server side part in Go which does provide those.
And Qt seems to provide pretty much everything else... but this one weird bit which is missing. :/
QML, Quick and Qt Widgets are fantastic though.
I still miss the Amiga in general though. It was nice to have complete control over the machine, working in harmony with the OS... or hosing it and causing a Guru Meditation.
I caused so many of those, lol. It is also funny how I gravitated to Linux and Qt after finally leaving Amiga. Qt back than seemed like a combination of Amiga and BeOS.
Side note:
The funny thing is I think the computers of the future will more resemble the hardware structure of the Amiga than the single chip multi-core computers of today. Once we can't fabricate smaller nor make faster calculations the module design we had of the amiga will become dominate. We are on the edge of having a CUDA built on the silicone or what Power9 is doing by giving them faster lanes.
* Creating standalone executables / installers for the app itself is already not so easy (I use - and recommend - PyInstaller [1]).
* Code signing the executables so users don't get an ugly "this app is untrusted" warning is tedious for the three different platforms
* Auto-updating is a pain to implement as well. I'm using Google Omaha (same as Chrome) on Windows [2], Sparkle on Mac [3] and Debian packages / fpm on Linux [4]. In total, I probably spent two to three months just on auto-update functionality.
* You really can tell that Qt is "drawing pixels on screen". Sometimes you have to draw pixels / perform pixel calculations yourself. The built-in "CSS" engine QSS works to some extent, but often has unpredictable results and weird edge cases.
I considered Electron as well. But its startup performance is just prohibitive. I blogged about this (and which other technologies I considered) [5].
I've been wondering for a while whether I should not open source my solutions to all of the above problems, to save other people the months required getting everything to work. Would anybody be interested in that? It would be something like a PyQt alternative for Electron.
[edit] People are very interested so I'm starting a MailChimp list. If you want to know if/when I open source a solution then please subscribe at http://eepurl.com/ddgpnf.
[0]: https://fman.io
[1]: http://www.pyinstaller.org
[2]: https://fman.io/blog/google-omaha-tutorial/
[3]: https://sparkle-project.org/
[4]: https://github.com/jordansissel/fpm
[5]: https://fman.io/blog/picking-technologies-for-a-desktop-app-...
We made a MVP using Electron but had to ditch it because of performance issues. PyQt seems like the best alternative, but the pain points you described were hard obstacles in the beginning.
* We gave up on making Omaha work, after some wasted weeks, and are using pywinsparkle to autoupdate on windows.
* The QSS feels buggy all around, the "border-radius" property is one of the simplest examples of that.
Would greatly appreciate some open-source solutions, examples or simply some blog posts of best-practices and how you are managing these pain points. :)
[0]: https://fman.io/blog
Just as anecdata, I've tried out Qt w/C++ a bit earlier and what I tried, I found good. And I wrote some simple wxPython GUI wrappers for my xtopdf toolkit, that experience was good too.
I've also tried out PyInstaller a bit for both simple CLI and GUI (wxPython again) apps; that worked well too. It's an interesting piece of technology; I think it must be doing a lot of stuff.
Python's Achilles heel, this is what caused me to walk away from Python. I usually make short very specific programs and I work on multiple of sites. Python was a pain to make executables. I now try to use Racket for everything and it makes executableson Windows, Linux and Mac.
Has things really improved the last 2 years?
[0]: https://fman.io/buy
I suppose the issue is distributing python.
I've always preferred KDE to GNOME because I feel it is higher quality desktop environment, but I will be the first to acknowledge KDE mucked up around KDE 4 and even today there are weird glitches in the vastly improved KDE5. That said, I still run Kubuntu because I feel it continues to be better than Ubuntu (GNOME), and I can live with the little annoyances.
Meaning that you will just as often find them working on something under the Freedesktop banner, but with a massive Gnome slant, as on Gnome proper.
In other words while KDE devs have a clear understanding of where the DE ends and the rest of the OS begins, Gnome devs seems to consider everything above the kernel (and is likely biding their time for the day Torvalds steps down) the domain of Gnome.
Of course the one time I attempted to write something with Gtk+, it very much felt like a "We hate C++, so we're going to implement everything C++ does as conventions and macros on top of C" project.
In the early days, Linux/gcc also had some dynamic linking performance issues with complex C++ libraries. As a result, KDE apps actually did take a lot longer to start up than Gnome apps. However, once launched, the KDE stuff always felt like it actually ran faster. Thankfully those issues are long since fixed.
As I replied in a sibling comment, yep that was part of the issue.
KDE, in a sense, was the original free desktop.
> K Desktop Environment (KDE) was founded in 1996 by Matthias Ettrich, who was then a student at the Eberhard Karls University of Tübingen. At the time, he was troubled by certain aspects of the Unix desktop. Among his concerns was that none of the applications looked, felt, or worked alike. He proposed the creation of not merely a set of applications but a desktop environment in which users could expect things to look, feel, and work consistently. He also wanted to make this desktop easy to use; one of his complaints about desktop applications of the time was that it is too complicated for end user.
Gnome could be considered an American "but-its-not-all-under-my-gpl" response.
Personally I always found glib and friends always quite ugly from a technical standpoint, and the poor documentation and support for platforms other than Linux made me move to Qt quite early on when I started.
That's weird, AFAIK KDE development is predominately German, Scandinavian and Anglo and I was under the impression that many key gnome developers were South American.
Back when KDE was being developed (which was open source), although the Qt source was available Qt wasn't free software nor OSI compatible. Back then it was owned and developed by Trolltech ASA, a Norwegian company (it was eventually bought by Nokia). Because it wasn't considered free software nor OSI compatible, certain distributions such as Debian didn't include it in their free repository and the FSF claimed it was incompatible with the GPL. So you had to grab it from non-free. I remember compiling 1.4x myself, same with KDE. It was eventually released under the QPL which wasn't considered GPL compatible by the FSF. Eventually it was also released under the LGPL. However while all this relicensing was going on (and it took various years), GNOME was already being developed, which was taken under the wing of the FSF as the free software desktop. By the time Trolltech had released Qt under the QPL and GPL, we already had a fractured "Linux" or open source desktop.
During the early versions of GNOME and KDE (before Web 2.0) ie. KDE 1, KDE 2, KDE 3 and GNOME 1 and GNOME 2 KDE was seen as a Windows esque desktop environment with lots of bells and whistles. As you say, it had large support in Germany and SuSE. Meanwhile, GNOME was regarded as a more Apple-esque desktop environment (like OSX or macOS as its called now) and the other main large commercial Linux distribution RedHat and main competitor of SuSE had GNOME as default desktop environment. GNOME also had HIG when KDE didn't yet.
Meanwhile, as you put, GNOME's libraries were LGPL and were therefore more proprietary-friendly because it doesn't require the fee for a commercial license which Qt has. For bigger companies that might not be a large barrier of entry, and you can find an ample amount of high commercial quality applications based on Qt.
A comprehensive history is written on Wikipedia [1]
Incomplete lists of software using Qt (doesn't contain discontinued software such as e.g. Opera for Linux) [2] [3]
[1] https://en.wikipedia.org/wiki/Qt_(software)#History_of_Qt
[2] https://en.wikipedia.org/wiki/Qt_(software)#Applications_usi...
[3] https://en.wikipedia.org/wiki/Category:Software_that_uses_Qt
The original reason for that was ABI compatibility, and being able to provide bindings for various languages which was considered a primary goal. As I recall at the time, there was no C++ ABI standard (or GCC didn't implement it), and it was considered hard to provide bindings of the library to various other languages.
GTK was written in C mainly for that reason.
This also explains why common object-oriented concepts are reimplemented in C in GTK, because them rejecting C++ for ABI reasons didn't mean they rejected the concepts.
This also explains Vala, Gnome's OO language that pre-processes to C, in order to get the best of both worlds. (anyone getting CFront flashbacks?)
History puts everything in context...
P.S. Name mangling is what define that the function "int print(char*)" will become "___4print@4" in the compiled DLL. All the functions in a DLL are listable and have a name, that's how they are found.
It was a "Look at me!!!" project by De Icaza, the same guy that would later do Mono and now works for Microsoft, using the Gimp derived GTK toolkit, and using the Qt license as a pretense.
Looking back at it, it is really "funny" how much alike the path of Icaza and Poettering is.
Am sure there are more subtle reasons. But recently there's a noticeable swing towards Qt. The next version of Budgie will build upon Qt, as did the aborted Unity8. LxQt is the future LXDE. But GTK has an entrenched mindshare in FOSS that Qt just doesn't.
On the programming side (via Perl and Python), I never liked GTK and have always preferred Qt.
So not only there was the license issue, usually C devs would side with Gtk+/GNOME and C++ with Qt/KDE.
I remember a few language flame wars when Gtk--/Gnome-- were started, nowadays Gtkmm/Gnomemm.
Back in the day SuSE and Mandrake were the best KDE distributions for desktop users.
As they kind of faded way, KDE lost a bit of momentum.
Then there was the whole mis-understanding with their reboot, which was supposed to be dev only and distributions took it as if it was ready.
The learning curve and full fledgedness of Qt was not needed for me.
But more often than not Electron is good enough and there are even approaches to get JS on the desktop with less memory consumption than Electron.
Since we're in a submission about Qt: if you really don't want to touch C++ (which is kinda understandable, although C++ with Qt actually isn't that bad), Qt is very well supported in Python. Using them together is a breeze, and if you really do miss the craziness of JavaScript, you can still use it in QML :P
And if QML is what you only care about, you can even wrap it with Rust.
Just in order to retain your sanity, you need to use several layers above JS to transpile your code - like JSX when you do UI or TypeScript when you do... well, anything.
I believe that JS is considered easy only because you can get your first impressive results very quickly when combined with HTML and CSS, which makes it easy to not lose your focus when learning. That might make it a good language to learn in, say, primary school on IT lessons - of course, only if there weren't other, better suited stuff available targeting these cases specifically already. Anything else actually makes JS harder than, say, Python. Or Go. Or C#. Or Java. Or even C++ with Qt (although C++ is easily second worse). Or Rust. There's just so much stuff you have to keep in your head while writing JS, it's not worth it. But you have to let go of "I know it, so I'll use it, no matter how well suited it is" mentality, and that can be challenging.
It depends on the setup. I use CoffeeScript 2 which gives me most of what I miss from Python (which was my favorite language for years). And when I go back to Python I miss having a debugger as good as Chrome's, as well as some CS2/ES6 features.
> There's just so much stuff you have to keep in your head while writing JS, it's not worth it.
Can you give me some examples?
This alone clearly states that you known nothing abou C++ beyond tired old, meaningless clichés about irrelevant stuff you've heard somewhere and are complaining about something you know nothing about.
Because you're repeatedly showing profound ignorance on very basic aspects of using a programming language.
> Has C++ eliminated undefined behaviour recently?
You are aware that you're parroting on and on about an entirely irrelevant issue, don't you? I mean, any behaviour which has been left undefined in the international standard only means that there is a chance that two implementations may not implement the same obscure aspect exactly alike. And that's perfectly fine because these obscure corner cases shouldn't be used to begin with. That's what undefined behaviour does mean in practice.
But even if you for some obscure and irrational reason care enough to rely on behaviour left undefined then you also go another standard approach: adopt a specific implementation and check how the behavior was implemented.
Additionally, rust and go and python and other programming languages are not defined at all and somehow programmers don't get bothered by the fact that these programming languages are entirely undefined. But somehow you feel differently about a language you clearly know nothing about.
By undefined behaviour, I mean things like null dereferences, buffer overflows, memory leaks etc. that are done by accident and result in serious issues at runtime. I'd rather use a safer language where I can be more productive where possible.
Sounds like you're talking about implementation defined behaviour or unspecified behaviour which are different from undefined behaviour (these three terms are defined in the C++ standard document).
> But somehow you feel differently about a language you clearly know nothing about.
You're not even trying to understand the point you're leaping to attack. You clearly have a chip on your shoulder about something.
Big community, with many learning resources.
Nice package managers, with libraries for basically everything.
Since many people already know JavaScript from working as a web developer, they also have a faster start.
Is there any project similar to those two, for Windows?
- Repo : https://github.com/nidium/Nidium/tree/windows-x86
- Screenshot : https://i.stack.imgur.com/5hTqR.png
I wouldn't even begin to know where to start with Electron. There are so many web frameworks and they're all badly documented... whenever I have to make a website I usually start off thinking "Right, I'll do it the 'modern' way this time - with React or Vue... and Typescript.. and and do I need webpack? and...??" but there's so much badly-documented half-finished stuff out there I usually end up giving up and doing plain Javascript. Doesn't help that the modern web stack is a total hacky mess.
I'd gladly take Qt with C++ any day even though I only know enough C++ to shoot myself in the foot with.
(Another thing that comes to mind is that there is a huge amount of software for testing, analysing, introspecting and debugging C++ applications - I would say that most other ecosystems are lagging behind in that aspect)
RStudio VS Code Discord / Slack (Well slack has not been rock steady)
Qt has language bindings.
Maybe the bindings are good? I just don't know, and I'm suspicious of an approach that seems to be entirely outside of mainstream Qt practice.
Yes you still write QML.
work great with Python
All the niceties that Qt as a framework provides (file system, multi-threading [mutexes, threads, semaphores, etc], JSON, shared memory, CLI arg parsing, even a State Machine!!) are a huge productivity boost.
Qt is awesome but one of its main problems is its insistence of duplicating standard components and coming up with subpar alternatives which are then forced upon developers.
30 years in the making, still waiting for that thing to actually exist.
How long have you been developing in C++? The standard is so little, there might as well not be one. I don't even think the printf() function takes the same arguments on all platform.
My point of view is that, where I'm using Qt anyway, I might as well use its threading library for the very nice support it provides for other things such as signal-slot connections across threads.
Additionally, QWidgets, the old pure-C++ based UI libraries are still available too. It also bundles a ton of other stuff, an embeddable web browser, javascript engine, collections library, concurrency library, networking library etc.
I’d much rather write a lightweight desktop app in any of the native toolkits, but especially Cocoa/Swift, and do the heavy lifting parts outside of the GUI application. But you’ll still have to write a native Linux one, and QT is my front runner there. But I do recommend looking at the Xamarin stuff too. Depends on your needs and where you’re coming from as a dev.
QT is awesome, don’t hear me wrong. But if your target platform is distros running gnome, it might not even be the right choice for a native Linux desktop app. And again, none of this cross-platform compatibility discussion necessarily makes it a better choice than Xamarin stuff.
I’m just saying, it’s not “the” option. It’s just a very good choice.
Even then, only if you dynamically link to the library.
If you statically link to an LGPL library, then the entire codebase (your code and the library) must be covered under an LGPL compatible license.
If you dynamically link to an LGPL library, then only the library must be under an LGPL-compatible license (ie if you modify the library, those modifications must be made available), but your own code that links to the library can be under any license you wish.
This is because the LGPL considers statically linking as a single work, while dynamic linking as multiple works, which can be licensed independently.
GPL:
Regardless of linkage, your code must be under a GPL compatible library.
The GPL considers the software as a single work regardless of linkage.
This isn't right. You can statically link proprietary code to LGPL libraries and the LGPL license does not "infect" your proprietary code.
The only thing you have to do if you go this route is ensure that the people receiving your combined work are able to relink any modified version of the LGPL pieces. This can be done, for example, by providing object files for the proprietary pieces and a script to link them to the LGPL pieces, upon request.
https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...
Point is... it's a gray area.
Linking technology itself is actually rather irrelevant to the legal questions that a court general ask in defining copyright. FSF happen use it as a bright line in the sand on where they will enforce the license, but any author can make their own decision on that matter. Game companies has for example gone after mods that inject itself through windows libraries, arguing that the mods purpose and existence is dependent on the original game and thus created a derivate work.
There was a historical case when a person legally bought a painting and cut it into several pieces only to stitched them together into a mosaic. The court judged it as a derivate work and thus requiring additional copyright permission from the author.
As with other gray areas in copyright, derivative work also have semi-exceptions. Compatibility is one. Since there is multiple different C standard libraries, it would be hard to argue that a program is specifically a derivative work of one. It would also be very easy to demonstrate the works independence by simply using a different standard library.
PyQt brings a interesting question but in the end I doubt it would be that much of a gray area. In theory you could make a program that is only compatible with Qt but don't actually depend on it, but in practice I suspect most such program do not start, operate, and function if you remove the Qt parts. In such cases I expect the accused will have a hard time arguing that the final work when used has no copyright-protected elements of Qt.
If you are comfortable with C++ and both traditional and event driven flows, Qt is worth a look -- you may love it or hate it, but you will have something to compare it to and know enough to form your own opinion. Otherwise, pick at least 3 different languages/toolkits and implement a simple application in each to be aware of different ways of doing the same thing. Repeat for a different simple application.
This vaccinates you against taking a model of your first toolkit and using it as the only way to solve every problem.
That said, Qt is a solid cross platform toolkit that you can use it to write robust applications. However, it severely locks down your choices. If you use it, force yourself to at least be aware of other options. My 2c.
Do you want to make cross-platform things? Sure, try this https://github.com/picoe/Eto (or these http://www.mono-project.com/docs/gui/ )
Do you want to be closer to the metal? More OpenGL? Go C++ or Rust ( https://github.com/rust-unofficial/awesome-rust#gui and https://github.com/rust-unofficial/awesome-rust#graphics )
Do you want less setup for your users? Go the Electron way, and/or eventually just build Web Apps!
Move semantics are much better. Not sure what you mean by clear pointer ownership, though.
If I give something a raw pointer, I don't expect ownership to be taken over by that something.
``` auto window_ptr = new QWindow(); auto field_ptr = new QTextEdit(window_ptr); ```
First, requiring the use of `new` is bad practice in modern C++.
Second, passing ownership of `field_ptr` to `window_ptr` is unclear. Because I called `new`, I expect that I need to call `delete`.
``` delete field_ptr; delete window_ptr; ``` Ooops... now I have a double-free!
I understand that Qt has been around since long before pointer ownership semantics were defined. But pointer semantics have been around for quite a long time now. The Qt Company really needs to modernize. Even if they don't want to use `std::unique_ptr` or `std::shared_ptr`, they can create their own (hopefully easily compatible) `QInstance` and `QSharedInstance` or something similar.
The raw pointers everywhere and lack of clear ownership is, in my opinion, a barrier to entry. I myself am pretty timid to use Qt because of it and I've got 10+ years of C++ experience.
not in this case: when you call delete on field_ptr, it removes itself from the list of children of windows_ptr. The other case would have crashed though.
But generally you don't even need to have new / delete / make_unique / whatever:
class MyWidget : public QWidget {
QFormLayout lay;
QPushButton button;
QLineEdit edit;
public:
MyWidget(QWidget* parent)
: QWidget{parent}
, lay{this}
{
button.setText("Hello world");
lay.addRow("Button", &button);
lay.addRow("Some text", &edit);
}
};
Likewise, you can just store a std::vector<std::unique_ptr<QObject>> if it makes you sleep better at night, if the objects are child of the class in, which you're storing them.
> Even if they don't want to use `std::unique_ptr` or `std::shared_ptr`, they can create their own (hopefully easily compatible) `QInstance` and `QSharedInstance` or something similar.
There are already various smart pointer types in Qt. But would you really like them to add unique_ptr overloads everywhere ? I'd hate to have to do
auto my_widg_ptr = std::make_unique<MyWidget>();
auto my_widg = my_widg_ptr.get();
parent_layout->addWidget(std::move(my_widg_ptr));
connect(whatever, &foo::bar,
[=] { my_widg->do_stuff(); });
auto my_widg = new MyWidget;
parent_layout->addWidget(my_widg);
connect(whatever, &foo::bar,
[=] { my_widg->do_stuff(); });I think my point though is still valid: that it's implicit ownership rules which are not clear ownership rules.
Does anyone have up-to-date experience with Qt? It's quite clear Symbian is no longer the main target, but did they ever get back to treating C++ as a first-class citizen, or is it still all about QML?
Sure, the main development focus is on QML etc., but that's mostly because desktop is a more mature platform than mobile.
[1] Except for the QtWebkit to QtWebengine transition perhaps. I haven't followed that very closely.
Getting the "feel" of a company's priorities can be hard, if you're not actively using their platform. I was hoping someone on HN had a somewhat realistic picture of where Qt is going these days.
It's still pretty unusable though :/ The default for Qt apps is via Xwayland in Fedora for example.
For embedded and mobile deployments, QML is the only option.
If you try to use a common C++ widget dialog, you will get a tiny desktop like window, regardless of the platform.
QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
The above is on an android tablet; but it displays perfectly fine on phones, too. Just see the sources of the above project for implementing such a dialog:
https://gitlab.com/eql/EQL5-Android/blob/master/examples/my/...
https://gitlab.com/eql/EQL5-Android/blob/master/examples/my/...
QML is easier anyway, and gets better with every version...
C++ Widgets should be able to offer a mobile friendly version of themselves.
Which was actually a point that was discussed for the Qt roadmap at Qt World Summit 2017.
The approach of re-doing in QML standard UI components is not appealing.
I really wanted to like QML. It gets lots of things right, but it's just so unfinished, and a few things are really weird, like ... I'm pretty sure object IDs sit in a global namespace and can be accessed by any component. A child component can access its parent, which just screams spaghetti.
And as far as I know there's still no way to have text in a custom widget. I wanted to make a QML graph widget. The lines are easy... but labels. The API for that is still private.
Another example: I wanted a log window, like a compilation log or something. There's only one QML widget for that and the only operations you can do on it are append(string) and remove(offset, length). You can't remove the first line of text for example. I ended up having to keep a separate array of line lengths, it was a huge hack.
Never seen any QML, don't know why people think Qt is about QML and javascript.
>pknopf: This reminds me of the project I am currently working on.
.NET/QML https://github.com/pauldotknopf/net-core-qml
Not quite production yet, but it will be soon. I'd love to he[ar] some input. You can check the unit tests for how things are working currently.
Besides, it still is C++: you can totally compile everything without the moc (although its probably not very useful to do so), since the extra keywords are just #defines.
I've personally never had any issues with the moc (but I did only ever use QtCreator/qmake, so...)
https://phabricator.kde.org/source/rust-qt-binding-generator...
https://youtu.be/MakX3OSsDUQ?t=54s
I have never heard any company ever call it Q.T.
Community: Q.T and I rarely hear it called cute. I usually call it Q.T. even though I know it is cute.
Him not being norwegian, I cannot know if that is correct or just something that is said in their office in Oslo...
[1] At least, Perfect Table Plan is quite successful, he has been selling it for a long time now. HyperPlan is newer, but IIRC he had some sales for it too.