16 ms·
Qt 5.10 released
- liquidnitro02 9y agoAwesome cant wait to check out the new features!
- nikanj 9y agoQt used to be an absolutely awesome C++ framework. Then Nokia happened, and it turned into a weird Rapid Development Environment™ for Symbian®©. 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?
- majewsky 9y agoNot sure what you're talking about. Qt 5 didn't remove anything that was there in Qt 4 [1], and added quite a few nice things like native Wayland support and more OpenGL integration. 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.
- nikanj 9y agoThe main development focus is the very thing I was curious about. I remember Qt being slow to support new things eg. high dpi, unless you were using QML. 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.
- casione 9y agoIt looks to me like they're very underfunded and have completely lost focus. The high DPI "debacle" is a good proof of it.
- shaan7 9y agoSure /s. We have a Qt app with GUI completely written in Qt. Scales pixel perfect on HiDPI out of the box as long as you make sure to not hardcode pixel values.
- seba_dos1 9y agoThings have definitely accelerated since Nokia regarding desktop platforms. High DPI support has gone through a few iterations and is working pretty well now. Also, Qt is now using open governance model. Qt Quick is still important, but I wouldn't say it's the single, most important thing it used to be anymore.
- carlos22 9y agoNow the focus of QML is mostly embedded where it really shines. Desktop and mobile is still possible with qml.
- jhasse 9y ago> native Wayland support It's still pretty unusable though :/ The default for Qt apps is via Xwayland in Fedora for example.
- majewsky 9y agoI'm using some KDE apps under Wayland (Sway, to be precise), and they're definitely not running under Xwayland (as confirmed by `xlsclients`). There is a lot of scaling confusion, but it's far from "unusable". Just not pretty.
- jhasse 9y agoMust have been some bug with my configuration then: There were scaling issues resulting in some buttons being unclickable.
- pjmlp 9y agoAll new APIs are done with focus of improving the QML experience. 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.
- eql5 9y agoEver heard of QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling); (to be set before creating the QApplication instance).
- pjmlp 9y agoHow does it help, when displaying a tiny file selection dialog on an Android device? https://bugreports.qt.io/browse/QTBUG-42491 https://bugreports.qt.io/browse/QTBUG-42491
- eql5 9y agoThese file dialogs are not for mobile! But it's easy to make your own ones, please see: https://gitlab.com/eql/EQL5-Android/blob/master/screenshots/REPL-file-dialog.png https://gitlab.com/eql/EQL5-Android/blob/master/screenshots/... 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/qml/ext/FileBrowser.qml https://gitlab.com/eql/EQL5-Android/blob/master/examples/my/... https://gitlab.com/eql/EQL5-Android/blob/master/examples/my/qml/ext/FileDelegate.qml https://gitlab.com/eql/EQL5-Android/blob/master/examples/my/...
- joezydeco 9y agoQt5 dropped the QWindowing Server for embedded platforms.
- dkersten 9y agoI'm of a different opinion: that Qt was good, but became great with Nokia. QtQuick (with its hardware-accelerated scene-graph based rendering system for rich UI's with ultra smooth animation) is awesome and QML is a very nice and pleasant way of declaratively creating UI's. Sure, you'd want to minimise the use of javascript, but QML + C++ is a pleasant experience, in my opinion, and much nicer than QWidgets.
- distances 9y agoI agree. Plus people tend to forget it was Nokia that relicensed Qt to LGPL, which was a massive gift for most developers. I really liked QML myself when I was using Qt, but even many of those who don't care about QML are likely enjoying the benefits of the more liberal license.
- IshKebab 9y agoStill all about QML. QtWidgets (C++) is well maintained but it's clear that they aren't really focusing on it. 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.
- ajuc 9y agoI kinda like QML. I liked qt3 for desktop apps, and pyqt was pretty sweet, but qml frontend and C++ backend is even better.
- digi_owl 9y agoMy impression was that QML was already happening before Nokia got involved.
- seba_dos1 9y agoQML was heavily inspired by EFL's Edje and the QEdje project, which was started in the middle of 2008. Qt Kinetic was initially presented at the end of 2008, however, it was still pretty much widget-oriented (the closest you could get to QML's was to use QGraphicsWidget by yourself, like Plasma 1 did). Qt Declarative (later called Qt Quick), including QML, has been shown in May 2009, a year after the acquisition by Nokia (June 2008, announced in January).
- user5994461 9y agoI've been on Qt projects, it's all C++. Never seen any QML, don't know why people think Qt is about QML and javascript.
- b1gtuna 9y agoIs Qt a good, modern framework for desktop application development for a beginner? If not, can someone recommend something else?
- nodelessness 9y agoI was researching a GUI framework for creating a desktop tool (that is a not very memory or CPU intensive). I felt that Electron was good enough. For the GUI framework it seemed like I can make do with Photonkit[1] and ReactJs. [1] http://photonkit.com/ http://photonkit.com/
- yorwba 9y agoIs your remark about the memory requirements about what the tool's functionality itself would consume, or the complete application (including the Electron runtime)? I was under the impression that each Electron application would require as much memory as an instance of the Chrome browser.
- nodelessness 9y agoYes. I was not building an application like Tableau or IntelliJ. I also was not building anything that had high performance requirements (which electron will definitely fail at) it was a CRUD app - the desktop version of a website with sync functionality. The learning curve and full fledgedness of Qt was not needed for me.
- the_common_man 9y agoElectron seems to be the preferred approach these days (much disliked by people who appreciate native apps). That said most Qt apps don't look native all the time either (it comes close enough)
- deleted 9y ago[deleted]
- k__ 9y ago
- dazzawazza 9y agoI've coded desktop apps (mostly editors and tools for games) for 25 years across X (Motif toolkit), Amiga, TOS, DOS, MFC, Cocoa, Win32, WxWidgets, Fox Toolkit and Qt. Qt has by far been the best, most rewarding, most empowering experience. It's a great library. Now Cocoa would win but I prefer C/C++ to Objective-C, it's close though. Good work people.
- Razengan 9y agoWhat about Cocoa with Swift?
- dazzawazza 9y agoI've not used swift yet but it looks very nice. Cocoa is still a very well designed and complete toolkit so I imagine it would be very productive.
- arca_vorago 9y agoI'm very interested to hear your opinion on WxWidgets, as I have heard more desktop app devs endorse it over the years. What features makes QT win out over it? Also, I know this might sound crazy, but what about (f/m)asm?
- dazzawazza 9y agoIt was so long ago that I used WxWidgets I'm not sure my opinion has value any more. Certainly 10 years ago it suffered from poor documentation (like most open source projects) but the Python bindings were very nice. Also Qt has a nice interface builder (not as nice as Cocoa but very useful) WxWidgets didn't have one at the time. I don't know what (f/m)asm is in this context, sorry.
- tonyedgecombe 9y agoI used wxWidgets for a couple of applications, the core was OK but anything outside of the basic widgets tended to be buggy. I wouldn't use it again.
- 9y ago
- royjacobs 9y agoThis is awesome. I can't wait for the KDE binding generator to mature so we can finally start using it more properly from Rust.
- happy_rust44 9y agoThe features of the C language were added with purpose. They were intended to solve a real problem and solve that problem they did. Simple arithmetic with promotion. Automatic register allocation with a portable (between compilers) ABI. A simple-but-handy preprocessor. And so on. C is also a lean language: a single person can feasibly write a C compiler in a relatively short time (tinycc is a C99-compliant C compiler written in just 65kLOC of C!). C set out to achieve a clear goal and it achieved its goal. Thanks to the cleanness of C lots of quality compilers came on the market quickly and even decent OSS solutions were available early on. In contrast, C++ never had a clear goal. The features of C++ were added almost at random. Stroustrup's original idea was essentially "C is cool and OOP is cool so let's bolt OOP onto C". Retrospectively, OOP was massively overhyped and is the wrong tool for the job for most of the people most of the time. Half of the GoF design patterns just emulate idioms from functional programming. Real OOP languages like Smalltalk and IO express many useful things that C++ cannot. The feature that C needed most was perhaps parametric polymorphism (aka generics in Java and C#, first seen in ML in the late 1970s) but instead of that C++ got templates that weren't designed to solve any particular problem but rather to kind of solve several completely unrelated problems (e.g. generics and metaprogramming). Someone actually discovered by accident that C++ templates are Turing complete and they wrote and published a program that computed prime numbers at compile time. Wow. A remarkable observation that led to decades of template abuse where people used templates to solve problems much better solved by other pre-existing solutions such Lisp macros and ML polymorphism. Worse, this abuse led to even more language features being piled on top, like template partial specialization. The massive incidental complexity in C++ made it almost impossible to write a working compiler. For example, it remains extremely difficult to write a parser for the C++ language. The syntax also has horrible aspects like List<Set<int>> being interpreted as logical shift right. None of the original C++ compilers were reliable. During my PhD in 2000-2004 I was still stumbling upon dozens of bugs in C++ compilers from GNU, Intel and SGI. Only after two decades did we start to see solid C++ compilers (by which time C++ was in decline in industry due to Java and C#). C++ is said to be fast but the reality is that C++ is essentially only fast when you write C-like code and even then it is only fast for certain kinds of programs. Due to the "you don't pay for what you don't use" attitude, C++ is generally inefficient. RAII injects lots of unnecessary function calls at the end of scope, sometimes even expensive virtual calls. These calls often require data that would otherwise be dead so the data are kept alive, increasing register pressure and spilling and decreasing performance. The C++ exception mechanism is very inefficient (~6x slower than OCaml) because it unwinds the stack frame by frame calling destructors rather than long jumping. Allocation with new and delete is slow compared to a modern garbage collector so people are encouraged to use STL collections but these pre-allocate huge blocks of memory in comparison so you've lost the memory-efficiency of C and then you are advised to write your own STL allocator which is no better than using C in the first place. One of the main long-standing advantages of C over modern languages is the unpredictable latency incurred by garbage collectors. C++ offers the worst of both worlds by not having a garbage collector (making it impossible to leverage useful concepts like purely functional data structures properly) but it encourages all destructors to avalanche so you get unbounded pause times (worse than any production GC). Although templates are abused for metaprogramming they are very poor at it and C++ has no real support for metaprogramming. For example, you cannot write an efficient portable regular expression library in C++ because there is no way to do run-time code generation and compilation as you can in Java, C# and languages dating back to Lisp (1960). So while Java and C# have had regular expressions in their standard libraries for well over 10 years, C++ only just got them and they are slow. C++ is so complicated that even world experts make rookie mistakes with it. Herb Sutter works for Microsoft and sits on the C++ standards committee where he influences the future of C++. In a lecture he gave his favorite 10-line C++ program, a thread-safe object cache. Someone pointed out that it leaks memory (Herb Sutter's favorite C++ 10-liner has a memory management bug). My personal feeling is that the new Rust programming language is what C++ should have been. It has useful known features like generics, discriminated unions and pattern matching and useful new features like memory safety without garbage collection.
- billfruit 9y agoHaven't used QT in a long time.Have they done away the with ’moc' and code generation? I found it extremely annoying that while we were using QT we weren't actually using c++, but a strange, language that looked like c++, but was actually further processed by qt to generate the c++ code. Are they done with that shebang?
- symlinkk 9y agono
- workthrowaway27 9y agoNot sure why you're being downvoted, since your answer is correct.
- iKlsR 9y agoWithout moc their is no signal slots and the handy stuff you get from plopping Q_OBJECT in your derived classes. So it's not going anywhere.
- billfruit 9y agoCan't they figure out a way to do that in pure c++ yet? In other words why does C++ lack reflection, and only seems to have a half baked RTTI? Perhaps the QT guys and other c++ application programmers didn't lobby C++ standards committee strongly enough for that?
- dkersten 9y agoSure, but there's 1) a performance hit because things that can be done at compile-time currently, have to be done at runtime, and 2) syntactically verbose/cumbersome. They've decided that these things are not worth it to most people. 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...)
- billfruit 9y agoAnnoying thing with QT, the official pronunciation sounds like ’cute’, and some interviewers insist on calling it that.
- marsRoverDev 9y agoI know a former Qt dev who pronounced it 'cute', so I think it's a bit of a Gif vs Gif type situation.
- manyoso 9y agoLots of people in the company call it 'Q' 'T' and lots call it 'Cute' and there is no "official" way it is called.
- billfruit 9y agoSee Wikipedia: https://en.m.wikipedia.org/wiki/Qt_(software) https://en.m.wikipedia.org/wiki/Qt_(software), it says pronunciation is 'cute'.
- baldfat 9y agoOfficially / Corporately: Cute https://youtu.be/MakX3OSsDUQ?t=54s 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.
- j1elo 9y agoI recently attended a talk by one of the Qt developers, and he briefly mentioned that 'cute' is not an intentional cute name, instead it just comes from the way the letters in 'Qt' are said in norwegian language. As simple as that. Him not being norwegian, I cannot know if that is correct or just something that is said in their office in Oslo...
- deleted 9y ago[deleted]
- shaan7 9y agoQT = QuickTime :P
- mherrmann 9y agoI'm an indie dev and have been developing a cross-platform (Py)Qt app for the past 1.5 years (~2100 dev hrs) [0]. Given that Qt is cross-platform desktop development, it's very solid. But there are a lot of things one has to do that are not required for (say) web apps: * 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 http://eepurl.com/ddgpnf. [0]: https://fman.io https://fman.io [1]: http://www.pyinstaller.org http://www.pyinstaller.org [2]: https://fman.io/blog/google-omaha-tutorial/ https://fman.io/blog/google-omaha-tutorial/ [3]: https://sparkle-project.org/ https://sparkle-project.org/ [4]: https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm [5]: https://fman.io/blog/picking-technologies-for-a-desktop-app-in-2016/ https://fman.io/blog/picking-technologies-for-a-desktop-app-...
- inetknght 9y agoIs Qt 5.10 still stuck in the time prior to C++11? Does it have clear pointer ownership and move semantics?
- gusmd 9y agoQt has moved into C++11+ world for quite some time. IIRC 5.7 was an important step in that direction, and they keep moving that way. Move semantics are much better. Not sure what you mean by clear pointer ownership, though.
- jcelerier 9y agoThere is a single rule for pointer ownership in Qt: parents own children. The problem is that it is not enforced by the compiler :p
- inetknght 9y agoThat rule is not clear ownership. That rule is implied ownership and goes against modern C++ practices. 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.
- dndneux 9y agoI enjoy using QML together with Python 3 for the logic, with the PyOtherSide plugin: https://thp.io/2011/pyotherside/ https://thp.io/2011/pyotherside/
- shmerl 9y agoThis is also an interesting project, if you want to use Qt with Rust: https://phabricator.kde.org/source/rust-qt-binding-generator/ https://phabricator.kde.org/source/rust-qt-binding-generator...
- eql5 9y agoBTW, if you like both QML and Common Lisp, and want to reach for android, there's news: EQL5-Android https://gitlab.com/eql/EQL5-Android https://gitlab.com/eql/EQL5-Android
- vram22 9y agoAndy Brice has two successful desktop app products, Perfect Table Plan and HyperPlan [1], and both are written using C++ and Qt, IIRC; I read that on his blog [2], which I have been following for some time now. Lots of good info about product development and marketing there. [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. [2] https://successfulsoftware.net/ https://successfulsoftware.net/
- vram22 9y agoAnd seeing a few comments about toolkits being cross-platform, reminded me: his apps work on at least both Windows and Mac (not sure about Linux, but I do remember the Qt version I tried earlier works on Linux too).
- Koshkin 9y agoAs good as QT and KDE are, I cannot really explain the fact that the most popular Linux distributions seem to show preference for Gnome; is Gnome more stable? is the user experience provided by Gnome more "polished"? or, is it the K-isms that push them away? is Gnome less resource-hungry?
- wenc 9y agoIt started out as a political issue (KDE being dependent on Qt, and Qt not being GPL at the time). The history is here: https://www.kde.org/community/history/qtissue.php https://www.kde.org/community/history/qtissue.php 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.
- vram22 9y agoWhat Kubuntu version do you use? I've had the same thoughts as you about KDE vs. GNOME in the past (at earlier versions though, don't know about how they stack up currently).
- hannofcart 9y agoGlad to see the update. Most people associate Qt with GUIs which is unfortunate. 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!
- makmanalp 9y agoAlso the image/video stuff and the browser, all the stuff that's /so/ insanely annoying to make cross platform works without a hitch.
- j_s 9y agoIs there a quick link to supported media formats? I will see if I can find it. 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-does-qmediaplayer-support/3 https://forum.qt.io/topic/57675/which-file-formats-or-codecs... https://forum.qt.io/topic/63110/list-of-video-formats-qt-supports/7 https://forum.qt.io/topic/63110/list-of-video-formats-qt-sup...
- makmanalp 9y agoEr, sorry, yes, the video /formats/ are unfortunately defined by the available media encoder backends, but it's more that I don't have to write any platform or media backend specific code to e.g. show video from a webcam, have a video player control, or record and save audio, etc etc. So your code remains the same, all you need to do is bundle codecs when shipping, or make sure you use formats that the default media backends of most platforms support. This might help: https://wiki.qt.io/Qt_5.5.0_Multimedia_Backends 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.
- j_s 9y agoNovember 2017: https://news.ycombinator.com/item?id=15617359 https://news.ycombinator.com/item?id=15617359 >pknopf: This reminds me of the project I am currently working on. .NET/QML https://github.com/pauldotknopf/net-core-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.
- stratigos 9y agoR.I.P. QtWebkit
- DonHopkins 9y agoWhat JavaScript engine is Qt 5.10 using, and have there been any recent changes to that engine, or the way it's integrated with Qt?