Re: [Interest] the path forward - that 7 year thing - was willy-nilly
On 26/3/21 6:38 am, Roland Hughes wrote: According to the FDA fact sheet. https://www.fda.gov/about-fda/fda-basics/fact-sheet-fda-glance There are currently 25,864 registered FDA medical device facilities. Not one of them can change a single approved process without going through the FDA approval process for said change. That is __NOT__ a sprint nor is it cheap. Within the past 18 months a drug manufacturer in high priced California put out a cattle call for a PDP 11/44 (might have been 24) system manager. Those machines were last made around 1978. There is a group of them still making necessary drugs in California. Once something is in place it stays there because it is incredibly expensive to replace. Qt's horizon is about 7 years. That's 8 years too short. Anything coded to Qt 3.x needs to ported first to 4.8, before going to 5.0. Once you're in the 5.x series, port to 5.15 and fix the warnings. Once you're clean in a working build, port to Qt 6. There is no one who went to a good school for their IT degree where they made the person take Cost Accounting ever going to utter that as a valid path forward. There is no MBA, even from a shit school like Keller, that is going to sign off on such a project. I really don't understand your arguments Roland. You say you need Qt support for 15 years, but you can't actually change one bit of your software without FDA approval, so presumably this means you aren't upgrading Qt anyway. Then after 15 years you want to work on a new model of the device, starting with your existing code, and you expect it to compile with the latest Qt unchanged? Someone else was talking about support for RHEL 6. Why do you expect to use the latest Qt with an ancient OS? Is it reasonable to expect to use new Qt with an ancient OS? I see that the latest Microsoft Visual C++ compiler toolset (v142) doesn't support building for Windows XP. You can still use an older compiler. That seems like a reasonable compromise. Hamish ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Qt 5.15 meta-qt5 yocto build
Hi, Am trying to build qt5.15.2 with eglfs and opengl es2 without wayland and x11 using yocto on TI AM3358 device incorder to run QtQuick and QtQuickControls. It builds fine if I use linuxfb as platform plugin to run Qt c++ widgets. Added below in conf: DISTRO_FEATURES_append = " opengl" DISTRO_FEATURES_remove = "x11 wayland" Added below in qtbase_git.bbappend: PACKAGECONFIG[gold-linker] = "-use-gold-linker,-no-use-gold-linker" PACKAGECONFIG[sql-plugin-sqlite] = "-system-sqlite -plugin-sql-sqlite,-no-sql-sqlite,sqlite3" PACKAGECONFIG[qml-debug] = "-qml-debug,-no-qml-debug" PACKAGECONFIG[qreal-float] = "-qreal float," PACKAGECONFIG += "gles2" PACKAGECONFIG_append= "eglfs sql-plugin-sqlite freetype fontconfig icu accessibility glib harfbuzz pcre qreal-float tslib" PACKAGECONFIG_remove = "xcb linuxfb pulseaudio tools iconv alsa dbus gold-linker evdev openssl" However, it throws below errors after building qtbase through yocto: .../../../../git/config.tests/unix/opengles2/opengles2.cpp:38:25: fatal error: GLES2/gl2.h: No such file or directory compilation terminated. Makefile:177: recipe for target 'opengles2.o' failed make: *** [opengles2.o] Error 1 Makefile:177: recipe for target 'opengles2.o' failed make: *** [opengles2.o] Error 1 OpenGL ES 2.0 disabled. It uses https://github.com/meta-qt5/meta-qt5 with the above changes in conf and qtbase_git.bbappend. Any thoughts on how to resolve the same if I need to add any includes in any mkspecs or any changes in bbappend ? Best Regards, Ramakanth ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] the path forward - that 7 year thing - was willy-nilly
On Thursday, 25 March 2021 12:38:56 PDT Roland Hughes wrote: > > Qt's horizon is about 7 years. > > That's 8 years too short. For this industry, sure. But it's not Qt's promise. The fact that some industries require a higher standard of support or coding practices or stability does not immediately mean that it must be done in all software. It doesn't make economical sense for Qt to provide support for 15 years. If you need Qt for that long, you should engage a consultancy that will sell you that contract, the same way that Red Hat sells support for RHEL 6 for 14 years total (2010-2024). > > Anything coded to Qt 3.x needs to ported first to 4.8, before going to > > 5.0. > > Once you're in the 5.x series, port to 5.15 and fix the warnings. Once > > you're clean in a working build, port to Qt 6. > > There is no one who went to a good school for their IT degree where they > made the person take Cost Accounting ever going to utter that as a valid > path forward. > > There is no MBA, even from a shit school like Keller, that is going to > sign off on such a project. That might be, but they may have a bigger cost instead when they need to port to what is current at the time. > > people when those releases were made and the warnings added? > > Watching production systems continue to run and generate revenue or save > lives, sometimes both. Until management makes a decision to update, > there is nothing for them to do. I call that shortsighted: failing to learn from innovation and predict future changes. It saves money in the short term, as you readily state, no doubt. > That is spoken like someone who has always worked in the > x86-wanna-be-a-real-computer-when-I-grow-up hacking on the fly world. In > the regulated world, whether you ship a product or not doesn't matter. > The development process requires you create The Four Holy Documents up > front.. You have a full QA team with a formal and documented as executed > testing plan. Full formal code review with secretary and official form > filing. A full formal test by an authorized third party of the device > off the actual and formally certified production line. It can't be a > one-off or a "pilot" line. It has to be *the* line that will produce > units for sale. I've never doubted that what you're saying does happen, in some industries. I'm saying that there are a lot of others where what you're saying does not happen. Those generate far more money for the actors involved here. And if you look at my email address, you'll realise that "x86-wanna-be-a-real- computer" is insulting. > > Like I said, I can't help if feedback wasn't given at the time that there > > was time to accept such feedback. You may say that going away for 15 > > years and then complaining is acceptable in some industries. It clearly > > isn't in this. > It clearly *is* the case and the reason companies are abandoning Qt > wholesale. That's not a valid conclusion. I can accept that in some industries what you're saying is true. I can even accept that in those industries Qt was in use and now some companies in that industry (even all of them) are abandoning Qt. But you're making a generalisation to all industries. That is not a valid conclusion from the facts stated. In fact, you yourself are saying that there are "wannabe" industries where it isn't the case. > > So stop the FUD. > > It's not FUD as others have pointed out. You didn't even know the stuff > Andre' needed was shot out of the saddle so quit claiming FUD. The > process is far more Willy-Nilly than measured. The decisions aren't > based on polling the customers and stuff is shot out of the saddle > without any viable replacement. It's not done polling customers because that is not the process. But there is a process. Again, you may not like the process, but there is one and therefore it's not willy-nilly. I do not deny we've removed stuff. I am asking that you stop calling it willy- nilly because: > https://www.merriam-webster.com/dictionary/willy-nilly > > 1*: *by compulsion *: *without choice > > 2 *: *in a haphazard or spontaneous manner Neither applies. > >Wikipedia says RHEL 6 ELS will be supported through 2024. Red Hat must be > > making a good chunk of money from customers like yours to still support > > kernel 2.6.32. > > This is another huge section of the market you don't take into account when > deprecating. Not exactly. We took them into account and concluded that the cost of supporting RHEL 6 outweighed the benefits. I know it's painful for those who can't upgrade. > The embedded systems world ***has*** to have a long life stability path. > Right now you are chasing the phone market where six months is ancient > history. *That* is why companies with deep pockets are abandoning Qt > wholesale. The embedded systems world is also evolving into IoT. Not all companies and devices, clearly, but there's a very big industry that does connect to the Internet and therefore must
Re: [Interest] the path forward - that 7 year thing - was willy-nilly
Breaking this off into its own topic. Roping in some of Andre' and Scott Bloom too. On Wednesday, 24 March 2021 09:58:50 PDT André Pönitz wrote: The exact opposite is the correct thing: - deprecation messages while compiling the source code are correct - messages to the mailing list are not sufficient Sorry, this assumes that "user" people constantly compile their application against Qt dev branch to notice. That is obviously not the case. And once it is already merged or even released it's practically to late. On 3/25/21 6:00 AM, interest-requ...@qt-project.org wrote: On Wednesday, 24 March 2021 04:48:08 PDT Roland Hughes wrote: On 3/24/21 6:00 AM,interest-requ...@qt-project.org wrote: The exact opposite is the correct thing: - deprecation messages while compiling the source code are correct - messages to the mailing list are not sufficient No, it's not. It only seems correct if you live in a world where nothing lasts six months. Out in the real product world you create some product using Qt 3.x or 4.2. That product goes to production where it remains for 7-15+ years. I stand by what I said and I live in the real world. You clearly live in a different, also real world. I don't doubt any of the claims you make are true. I do doubt that they are the majority or even significant. The majority of the uses I am familiar with last much shorter than 7 years. At the very least, there are opportunities in those 7 years to do incremental progress or keep up with the latest. According to the FDA fact sheet. https://www.fda.gov/about-fda/fda-basics/fact-sheet-fda-glance There are currently 25,864 registered FDA medical device facilities. Not one of them can change a single approved process without going through the FDA approval process for said change. That is __NOT__ a sprint nor is it cheap. Within the past 18 months a drug manufacturer in high priced California put out a cattle call for a PDP 11/44 (might have been 24) system manager. Those machines were last made around 1978. There is a group of them still making necessary drugs in California. Once something is in place it stays there because it is incredibly expensive to replace. Qt's horizon is about 7 years. That's 8 years too short. Anything coded to Qt 3.x needs to ported first to 4.8, before going to 5.0. Once you're in the 5.x series, port to 5.15 and fix the warnings. Once you're clean in a working build, port to Qt 6. There is no one who went to a good school for their IT degree where they made the person take Cost Accounting ever going to utter that as a valid path forward. There is no MBA, even from a shit school like Keller, that is going to sign off on such a project. You've got all warnings you needed to make progress in each of those steps. You may not like some of those changes. Then I suggest that you should have complained when Qt 5.15 became available with those warnings. And do note about half of the warnings were introduced before 5.15, so where were those people when those releases were made and the warnings added? Watching production systems continue to run and generate revenue or save lives, sometimes both. Until management makes a decision to update, there is nothing for them to do. That PDP 11 story I told you earlier, it's not a one-off. They aren't the only ones maintaining FDA approved manufacturing lines established in the late 1960s to mid 1970s. Confidentiality agreements will force people to clam up, but just about every pain reliever and antibiotic ointment you take for granted being on a store shelf from aspirin to cold formula has such a line. If it has been on the market 30+ years, unless the production was sent off-shore, the same line will be making it. Until management makes a decision to update/replace something, there is nothing for them to do. Now the product needs to be redeveloped/enhanced because the benefits now outweigh the costs of spin-up. That's why you need to do it incrementally and you shouldn't wait to do it. Keep up to date in those 15 years, even if you don't actually release a new product with those updated versions. That is spoken like someone who has always worked in the x86-wanna-be-a-real-computer-when-I-grow-up hacking on the fly world. In the regulated world, whether you ship a product or not doesn't matter. The development process requires you create The Four Holy Documents up front.. You have a full QA team with a formal and documented as executed testing plan. Full formal code review with secretary and official form filing. A full formal test by an authorized third party of the device off the actual and formally certified production line. It can't be a one-off or a "pilot" line. It has to be *the* line that will produce units for sale. Every iteration whether you ship it or not. Why? Turn on an old episode of NCIS and watch when Abby hands Gibbs or one of the other members an evidence bag. They've got to sign
Re: [Interest] Android OpenSSL EVP
Ok, sorry for the noise, the solution was not so hard, just needed to also
specify the libs per arch on top of the android extra libs
LIBS += \
$$OPEN_SSL_PATH/Android/$$ANDROID_TARGET_ARCH/libcrypto_1_1.so \
$$OPEN_SSL_PATH/Android/$$ANDROID_TARGET_ARCH/libssl_1_1.so
From: Interest on behalf of Jérôme Godbout
Date: Thursday, March 25, 2021 at 3:05 PM
To: Qt Interest
Subject: [Interest] Android OpenSSL EVP
Hi,
anyone have use OpenSSL EVP interface under Android? I manage to make it work
under MacOS, Windows, Linux, but under Android I can add the OpenSSL lib, I
compiled them for each arch (x86, x86_64, armv7, armv8) and I add all the libs
with (I use Qt 5.15.2 only for this):
INCLUDEPATH+= $$OPEN_SSL_PATH/include
ANDROID_EXTRA_LIBS += \
$$OPEN_SSL_PATH/Android/armeabi-v7a/libcrypto_1_1.so \
$$OPEN_SSL_PATH/Android/armeabi-v7a/libssl_1_1.so \
$$OPEN_SSL_PATH/Android/arm64-v8a/libcrypto_1_1.so \
$$OPEN_SSL_PATH/Android/arm64-v8a/libssl_1_1.so \
$$OPEN_SSL_PATH/Android/x86/libcrypto_1_1.so \
$$OPEN_SSL_PATH/Android/x86/libssl_1_1.so \
$$OPEN_SSL_PATH/Android/x86_64/libcrypto_1_1.so \
$$OPEN_SSL_PATH/Android/x86_64/libssl_1_1.so
This work to use OpenSSL, but I cannot use the EVP, header are added, it fail
at link time of the Qt application. I’m not even sure what Qt does with
ANDROID_EXTRA_LIBS and how can the C++ code can link against the current arch
lib?
Any way to do this that will work on each arch? This is how I compiled my libs
btw (under MacOS):
#!/bin/bashVERSION=1.1.1j
ANDROID_SDK_HOME=/Users/Shared/AndroidSDK
export ANDROID_NDK_HOME=$ANDROID_SDK_HOME/ndk/21.1.6352462
if [ ! -f "openssl-$VERSION.tar.gz" ]; then
wget https://www.openssl.org/source/openssl-$VERSION.tar.gz
fi
for arch in "armeabi-v7a" "arm64-v8a" "x86" "x86_64"
do
pushd .
rm -fr $arch
mkdir $arch
rm -fr openssl-$VERSION
tar xf openssl-$VERSION.tar.gz
cd openssl-$VERSIONcase $arch in
armeabi-v7a)
ANDROID_API=16
CONFIG_ARCH="arm"
;;
x86)
ANDROID_API=16
CONFIG_ARCH="x86"
;;
arm64-v8a)
ANDROID_API=21
CONFIG_ARCH="arm64"
;;
x86_64)
ANDROID_API=21
CONFIG_ARCH="x86_64"
;;
esac
ANDROID_TOOLCHAIN=""
for host in "linux-x86_64" "linux-x86" "darwin-x86_64" "darwin-x86"
do
if [ -d "$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/$host/bin" ]; then
ANDROID_TOOLCHAIN="$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/$host/bin"
break
fi
doneexport PATH="$ANDROID_TOOLCHAIN":"$PATH"./Configure shared
android-${CONFIG_ARCH} -D__ANDROID_API__=${ANDROID_API} || exit 1
make dependmake -j$(nproc) SHLIB_VERSION_NUMBER= SHLIB_EXT=_1_1.so
build_libs || exit 1
llvm-strip --strip-all libcrypto_1_1.so
llvm-strip --strip-all libssl_1_1.so
cp libcrypto_1_1.so ../$arch || exit 1
cp libssl_1_1.so ../$arch || exit 1
popd
done
Jérôme Godbout, B. Ing.
Software / Firmware Team Lead
O: (418) 682-3636 ext.: 114
C: (581) 777-0050
godbo...@dimonoff.com
[signature_868826015]
[Interest] Android OpenSSL EVP
Hi,
anyone have use OpenSSL EVP interface under Android? I manage to make it work
under MacOS, Windows, Linux, but under Android I can add the OpenSSL lib, I
compiled them for each arch (x86, x86_64, armv7, armv8) and I add all the libs
with (I use Qt 5.15.2 only for this):
INCLUDEPATH+= $$OPEN_SSL_PATH/include
ANDROID_EXTRA_LIBS += \
$$OPEN_SSL_PATH/Android/armeabi-v7a/libcrypto_1_1.so \
$$OPEN_SSL_PATH/Android/armeabi-v7a/libssl_1_1.so \
$$OPEN_SSL_PATH/Android/arm64-v8a/libcrypto_1_1.so \
$$OPEN_SSL_PATH/Android/arm64-v8a/libssl_1_1.so \
$$OPEN_SSL_PATH/Android/x86/libcrypto_1_1.so \
$$OPEN_SSL_PATH/Android/x86/libssl_1_1.so \
$$OPEN_SSL_PATH/Android/x86_64/libcrypto_1_1.so \
$$OPEN_SSL_PATH/Android/x86_64/libssl_1_1.so
This work to use OpenSSL, but I cannot use the EVP, header are added, it fail
at link time of the Qt application. I’m not even sure what Qt does with
ANDROID_EXTRA_LIBS and how can the C++ code can link against the current arch
lib?
Any way to do this that will work on each arch? This is how I compiled my libs
btw (under MacOS):
#!/bin/bashVERSION=1.1.1j
ANDROID_SDK_HOME=/Users/Shared/AndroidSDK
export ANDROID_NDK_HOME=$ANDROID_SDK_HOME/ndk/21.1.6352462
if [ ! -f "openssl-$VERSION.tar.gz" ]; then
wget https://www.openssl.org/source/openssl-$VERSION.tar.gz
fi
for arch in "armeabi-v7a" "arm64-v8a" "x86" "x86_64"
do
pushd .
rm -fr $arch
mkdir $arch
rm -fr openssl-$VERSION
tar xf openssl-$VERSION.tar.gz
cd openssl-$VERSIONcase $arch in
armeabi-v7a)
ANDROID_API=16
CONFIG_ARCH="arm"
;;
x86)
ANDROID_API=16
CONFIG_ARCH="x86"
;;
arm64-v8a)
ANDROID_API=21
CONFIG_ARCH="arm64"
;;
x86_64)
ANDROID_API=21
CONFIG_ARCH="x86_64"
;;
esac
ANDROID_TOOLCHAIN=""
for host in "linux-x86_64" "linux-x86" "darwin-x86_64" "darwin-x86"
do
if [ -d "$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/$host/bin" ]; then
ANDROID_TOOLCHAIN="$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/$host/bin"
break
fi
doneexport PATH="$ANDROID_TOOLCHAIN":"$PATH"./Configure shared
android-${CONFIG_ARCH} -D__ANDROID_API__=${ANDROID_API} || exit 1
make dependmake -j$(nproc) SHLIB_VERSION_NUMBER= SHLIB_EXT=_1_1.so
build_libs || exit 1
llvm-strip --strip-all libcrypto_1_1.so
llvm-strip --strip-all libssl_1_1.so
cp libcrypto_1_1.so ../$arch || exit 1
cp libssl_1_1.so ../$arch || exit 1
popd
done
Jérôme Godbout, B. Ing.
Software / Firmware Team Lead
O: (418) 682-3636 ext.: 114
C: (581) 777-0050
godbo...@dimonoff.com
[signature_868826015]
Re: [Interest] The willy-nilly deletion of convenience, methods
On Thursday, 25 March 2021 07:40:00 PDT Matthew Woehlke wrote: > Wow, you *totally* misunderstood that. > > QList in Qt5 is mostly fine (and there's always QVector if needed). > > Qt 6 got rid of a useful container type. I didn't misunderstand you. I'm disputing your assertions. QList in Qt 5 was *not* mostly fine. It was mostly wrong and would have become even more wrong in Qt 6. QStringList would have been wholly bad because sizeof(QString) == 3 * sizeof(void*). And QList's design in trying to guess what the best storage strategy was flawed, leading to silent binary incompatibilities and possible data loss if you used Q_DECLARE_TYPEINFO to make your type use QList efficiently. But even flawed designs can have some uses, I agree. It's just not strong enough to warrant being the default container type for Qt and being called QList. The *name* had to be freed. As I said, we can bring back the container, in a fixed form. It will most definitely not have the hybrid model where it tries to guess which way is best (that was the design flaw). If you want stability of references by way of pointers, use this; if you don't care, use QList. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] [Qt3d] Rendering 3D object with 2D coordinates
On Mon, Mar 22, 2021 at 10:55 AM Alex john wrote:
> Transform {
> id: trefoilMeshTransform
> translation:Qt.vector3d(Qt.vector2D(100, 100)).unproject(
> modelView ,mainCam.projectionMatrix, forwardRenderer.viewportRect)
> property real theta: 0.0
> property real phi:0.0
> property real roll: 0.0
> rotation: fromEulerAngles(theta, phi, roll)
> scale: root.scale
> }
I used the following function to get the 3d coordinates using the 2d,
by refering to the source code
https://code.woboq.org/qt5/qtbase/src/gui/math3d/qvector3d.cpp.html#_ZNK9QVector3D9unprojectERK10QMatrix4x4S2_RK5QRect
I need to render the 3d cube exactly where the Rectangle{x:100, y:100}
renders however there is lot of offset and I think the calculations is
somewhere going wrong. Can clue ?
function projectPointsto3d(){
var ptX = 100
var ptY = 100
var windowPt = Qt.vector4d(ptX,ptY,1,1)
var mat = mainCam.projectionMatrix.times(mainCam.viewMatrix)
var inverse = mat.inverted()
var normalize = Qt.vector4d(1,1,1,1)
windowPt.x = (windowPt.x -
forwardRenderer.viewportRect.x)/forwardRenderer.viewportRect.width
windowPt.y = (windowPt.y -
forwardRenderer.viewportRect.y)/forwardRenderer.viewportRect.height
windowPt = windowPt.times(2).minus(normalize)
var a = inverse.times(windowPt)
var division = a.w (if i use (1/a.w) teh 3d values will be
very high and I do not see object)
a = a.times(division)
return a.toVector3d()
}
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
On 24/03/2021 18.25, Thiago Macieira wrote: On Tuesday, 23 March 2021 09:02:04 PDT Matthew Woehlke wrote: On 23/03/2021 11.44, Volker Hilsheimer wrote: I wished I had seen the level of energy y’all are putting right now into this email thread over the last two years when we discussed where to go with Qt 6, and when the work actually happened. IIRC, I complained plenty about QList at the time. I wouldn't be surprised if I complained about QHash also. And lo and behold, QList and QHash are completely rewritten for Qt 6, because of the major complaints that existed against them, especially against QList. Wow, you *totally* misunderstood that. QList in Qt5 is mostly fine (and there's always QVector if needed). Qt 6 got rid of a useful container type. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
