Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technical Vision for Qt 6

blog.qt.io

Post reply on HN
Print view View original

111–120 of 184 posts

Re: Technical Vision for Qt 6

#111

Post by pjmlp »

Const-me wrote: post #65
pjmlp wrote: post #49

Earlier quoted context omitted.

For better or worse, pure C++ APIs have lost the war on GUI frameworks. Microsoft is the only consumer OS vendor that still supports C++ for doing full stack GUI apps, everyone else moved into a mix of C++ plus managed language or layout DSL.

> Microsoft is the only consumer OS vendor that still supports C++ for doing full stack GUI apps On modern Windows you have C++, and also layout DSL, specifically XAML. And that C++ is not particularly idiomatic, it’s IUnknown-derived interfaces. If you mean windows desktop, WinAPI uses quite a few DSLs. Dialog and menu resources are the most obvious, but there’s more: WMF/EMF vector graphics format, ribbon markup XM…

You are talking about Win32 legacy API, stuck in Windows XP feature level.

Modern Windows desktop UI, UWP aka WinUI, uses C++17 with a framework called C++/WinRT, that hides those IInspectable COM interfaces.

Yes there used to exit C++/CX and Windows Runtime Library, both now considered legacy and replaced by C++/WinRT.

Re: Technical Vision for Qt 6

#112

Post by oehtXRwMkIs »

Areading314 wrote: post #82

Have you considered rewriting it in Rust?

Honestly at this point they should just rewrite it in Javascript and focus on javascript bindings. Javascript is simply more productive and friendlier for devs to work with. This would allow Qt to compete with Electron for how well my hands are kept warm by my laptop during the winter.

Re: Technical Vision for Qt 6

#114

Post by cmaureir »

sime2009 wrote: post #80
jlarocco wrote: post #29

It's good to see language compatibility mentioned, and I hope they follow through with it. There were really fantastic Common Lisp bindings for Qt4, but they relied on a tool called "Smoke", which stopped working with Qt5. My understanding is Smoke was used to create the early Python binding, but a different mechanism was used for the Python bindings in Qt5. For some reason the new technique wasn't as easy to use fro…

Here's a quick history lesson. Long ago Smoke was created by one guy, Richard Dale, to do bindings for Ruby (QtRuby). Smoke was generic enough to be used for other languages like Lisp and also the .Net CLI. Language bindings other than Python didn't really catch on and the community needed to make it all viable and self sustaining didn't emerge. It was mostly one person's passion project and they didn't get any real…

And that binding generator is called Shiboken, which was motivated by boost::python and the same idea behind the binding generator written for Java in the old days (from QtJambi).

At the moment Shiboken is more general, and mature and can be used even for C++ projects (which are not related to Qt). https://wiki.qt.io/Qt_for_Python/Shiboken

Re: Technical Vision for Qt 6

#115

Post by shmerl »

oehtXRwMkIs wrote: post #113
shmerl wrote: post #48

They should add official Rust bindings.

is it possible to have safe bindings for something like Qt? never understood if that's a thing or not since I've heard FFI usage is inherently unsafe.

I assume if the logic is wrapped into something that handles it correctly, you can declare it as safe, even if inside it's unsafe.

Re: Technical Vision for Qt 6

#116

Post by mkl »

badsectoracula wrote: post #85

Does that mean all current KDE applications will soon become binary incompatible with the future KDE libraries that will be based on Qt 6?

KDE applications and KDE libraries will be updated together. How else could it be?

It won't be soon, either. Qt is aiming for a first release of Qt 6 by the end of 2020.

Re: Technical Vision for Qt 6

#118

Post by malkia »

4ad wrote: post #70
halflings wrote: post #60

Earlier quoted context omitted.

Would have hoped they would use bazel instead. It's open-source, and so much easier to deal with than CMake.

Are you kidding me, bazel is written in Java...

so what? Bazel spawns a server, the next invocation is really fast.

Re: Technical Vision for Qt 6

#119

Post by malkia »

halflings wrote: post #60
jupp0r wrote: post #12

Thanks for supporting CMake and deprecating qmake. Not that cmake is the best tool ever, but having to deal with several build systems in the same project has always been a nightmare.

Would have hoped they would use bazel instead. It's open-source, and so much easier to deal with than CMake.

Me too. I love bazel, for the plain syntax, sandwiches (deps between languages), determinism, just plain good stuff. I use it for all my new personal projects (linux/windows).

Re: Technical Vision for Qt 6

#120

Post by p2t2p »

stabbles wrote: post #39
dkersten wrote: post #9

"Make JavaScript an optional feature of QML." and "Support compiling QML to efficient C++ and native code." Yes! These two things are what's been on the very top of my wishlist ever since QML/QtQuick was first released.

I would love this! In fact the QML format would not even be a terrible way to write non-UI applications, I'd think. Something like MySqlDataBase { id: default_db host: ... } UserController { items_per_page: 20 formatter: UserFormatter {} repository: Repository { table: "users" database: default_db } } is definitely more easier to follow than the linear version auto default_db = std::make_shared ("..."); auto userform…

Been there, done that, SQL queries in JSP. Trust me, you don’t want your business and data access layers mixed with your presentation
Post reply on HN