Qt 6 To Ship With Package Manager For Extra Libraries

[phoronix]

Phoronix: Qt 6 To Ship With Package Manager For Extra Libraries

Adding to the list of changes coming with the Qt 6 toolkit, The Qt Company has now outlined their initial implementation of a package manager to provide additional Qt6 modules...

http://www.phoronix.com/scan.php?page=news_item&px=Qt-6-Package-Manager

[Ironmask]

Ugh, I wish Qt would just be a regular library. Qt is less of a windowing framework and more of an application framework, they make it hell to use it in any language not C++. I'm continuing to lose interest in it.

[Nth_man]

> Red Hat is helping out a ton, honestly Red Hat is going to have a lot more to do with getting Steam's market
> share up than Valve ever will, even with Proton
> -- Ironmask

Found the Red Hat employee.
(Upvoted 12 times at least: https://www.phoronix.com/forums/foru...28#post1157028)

[Ironmask]

> Red Hat is helping out a ton, honestly Red Hat is going to have a lot more to do with getting Steam's market
> share up than Valve ever will, even with Proton
> -- Ironmask

Found the Red Hat employee.
(Upvoted 12 times at least: https://www.phoronix.com/forums/foru...28#post1157028)

Wrong thread?

[Morty]

Qt is less of a windowing framework and more of an application framework,

Since Qt always have been an application framework, this comment does not make much sense.

they make it hell to use it in any language not C++.

Well the Qt Python bindings are more up to date and comprehensive than any other toolkit out there, so at least no hell there.

And other than C, and that does not make any sense anyway, Qt has lot of bindings for other languages avalible. And they, like the Python bindings, tend to be more up to date and comprehensive than the "competition". https://wiki.qt.io/Language_Bindings

So basicly, in most cases, less hell than the alternatives. Perhaps you support the old myth that C libraries are easier to make bindings for, therefore C libraries automaticly get better bindings? Even tho the developers of Qt bindings for years have shown this is not the case.

[berolinux]

Pretty much useless for us in the real world (we can just dnf/apt/pacman/... install any extensions we want...), but certainly a much needed feature for those in the world of crappy non-free operating systems.

[oleid]

Perhaps you support the old myth that C libraries are easier to make bindings for, therefore C libraries automaticly get better bindings? Even tho the developers of Qt bindings for years have shown this is not the case.

That's not a myth. Many non-scripting languages like haskell, go and rust cannot bind to c++. They either only support Qml (which is easy via it's C interface) or automatically generate c++ glue code with a C interface to wrap Qt.
AFAIR the Java bindings also use a C interface automatically generated from the c++ headers.

[Morty]

That's not a myth. Many non-scripting languages like haskell, go and rust cannot bind to c++. They either only support Qml (which is easy via it's C interface) or automatically generate c++ glue code with a C interface to wrap Qt.

Yet, still the Qt bindings in most cases is more up to date and cover more of the toolkit than "comparable" toolkits not written inn C++. The better bindings for the "easier" non-C++ toolkits does not exist, they are simply a mythical construct regulary used in post like the parent.

[oleid]

Yet, still the Qt bindings in most cases is more up to date and cover more of the toolkit than "comparable" toolkits not written inn C++.

In case you consider gtk+ comparable: its bindings are more up to date and cover all the toolkit.

Main reason : bindings are auto-generated using glib-introspection. This is possible, as the C interface is easy.

In python, for example, you don't have to write wrapper code for each library which supports "gi", you can simply load the description file.


Libostree, for example, can be used without any extra glue code. Just import the gi module, tell it to load ostree and be done.