Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

[Roland Hughes]

On 6/15/20 1:48 PM, interest-requ...@qt-project.org wrote:

Wow! They also have Windows 12
https://www.window11updates.com/windows-12-lite-download-linux-iso/
(must be*even better*  than Windows 11:-)


Now now kids.

https://answers.microsoft.com/en-us/windows/forum/windows_10-update/windows-11-release-date/7cb93133-ef3f-440a-840c-2f1044f34409

=

The schedule that has been previously stated is twice yearly major 
updates to Windows 10 and that Windows 10 will be the last version of 
Windows.


But what will happen after 14 October 2025? Microsoft said that 'Windows 
10 is the last version of Windows'.


=

By 14 October 2025 Windows will just be a desktop like KDE, Gnome, etc. 
and it will be running on top of Ubuntu. They've already started that 
work bringing Ubuntu into Windows 10.


This assumes Canonical doesn't get too greedy and Microsoft doesn't get 
a fart cross ways.


Microsoft surrendered the browser market, switching to Google Chrome 
libraries like Opera and others.


They've been surrendering desktop applications for a while, trying to 
push everyone to Office365 and "leasing." This has lead to a boom in 
LibreOffice and OnlyOffice use. WordPerfect, believe it or not, is 
rumored to be gaining users as well. WordPerfect, however, ditched their 
Linux version long ago so will probably be well and truly screwed in 2025.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

[Roland Hughes]

On 6/15/20 1:47 PM, Matthew Woehlke wrote:

On 15/06/2020 14.26, Jérôme Godbout wrote:
If your developer have hard time learning Qt3 to Qt5, I feel sorry 
for you


You have that backwards.


Kids who only learn the new stuff can't be hired to support the
old because they cannot even begin to function.


I suggest you hired from different schools.


While that may be a valid suggestion, it's well "known" that you can 
teach C programmers Java, but you can't teach Java programmers C. Most 
"skript kiddies" lack the technical foundations to understand "real" 
programming.


Unfortunately, not so many schools turn out programmers with the 
required backgrounds.


This is the equivalent of turning out "mathematicians" that can punch 
buttons on a calculator but don't know how to actually do math if you 
take away their gadgets.



Yeah.

What Matthew said.

It's like trying to teach someone who never took the training wheels off 
their bike how to ride a bike that can't ever have training wheels or go 
slow.


I hope to God I'm never connected to a Medical device that used QML. A 
better question would be "How did you even get that through the FDA 
approval process?"


A stable API is what is required for long term production. It will be 
interesting to see what your opinion is 10 years from now when the QML 
code you wrote last week will no longer run on the "current" QML VM.


Just how many times has someone re-arranged the header files in Qt just 
to make it more aesthetically pleasing? A lot. That minor little "tweak" 
busts builds wholesale.


As far as the "not a 3 OS world anymore" you are correct. It's a Yocto 
Linux build or a Windows build. That's the embedded medical device and 
industrial controller world. Under the "Windows" heading is WinCE, 
Windows Mobile, whatever that Windows 7 embedded thing is/was that many 
companies bought the source to, and the original flavor of Windows, DOS.


Hopefully, very soon now, the KDE community will announce what the 
post-Qt development tool set will be and the embedded world can not only 
move on, but get some stability back. From everything I've heard, we are 
all waiting for KDE to make the decision. Hopefully they will mandate 
the require API stability and header files not becoming Easter Egg hunts.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

[Matthew Woehlke]

On 15/06/2020 14.26, Jérôme Godbout wrote:

If your developer have hard time learning Qt3 to Qt5, I feel sorry for you


You have that backwards.


Kids who only learn the new stuff can't be hired to support the
old because they cannot even begin to function.


I suggest you hired from different schools.


While that may be a valid suggestion, it's well "known" that you can 
teach C programmers Java, but you can't teach Java programmers C. Most 
"skript kiddies" lack the technical foundations to understand "real" 
programming.


Unfortunately, not so many schools turn out programmers with the 
required backgrounds.


This is the equivalent of turning out "mathematicians" that can punch 
buttons on a calculator but don't know how to actually do math if you 
take away their gadgets.


--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

[Jérôme Godbout]

Yeah API between major version is going to change, because, yeah the world is 
evolving and better concept become available, if you thing all the API changes 
are for idevice only, your saying but I beg to differ. I really like where they 
are heading. QWidgets is hard to maintain and is one reason it's mostly left as 
is, because it require a lots to maintain the native GUI on each platform so 
new platforms require a lot of effort to be added (this is no more a 3 OS only 
world anymore, those days have been over, move on). 

Qml (I have made 3D medical CAD application desktop, and it run flawlessly), I 
for one have ditch QWidgets and I don't plan to look back to the pain of 
connecting everything by hand, error prone and make way to many hard to 
maintain code. Qt bindings is coming to C++ and this will also be a huge 
welcome from me. The changes that was made is exactly to adapt to the world, 
and multiple platform out there. Qml also open the door to Qt for MCU, to Web 
assembly ... I fail to see why the iDevice is a concern, they are expending the 
allowed paltforms and this is good for a cross platform framework to do so.

If your developer have hard time learning Qt3 to Qt5, I feel sorry for you, 
your team is probably weak (but this is my personnal opinion). They must have a 
hard time with C++11 to C++17 too. I have port application from Qt3 to Qt4 back 
in the days, from PPC to x86. From Qt4 to Qt5. The new code mostly felt cleaner 
in the end. Nobody is force to update from major version if that suite you. If 
you used an unsupport OS, you probably still used the lastest framework that 
were designed to support those, don'T expect Qt to support OS that aren't event 
supported by the manufacturer anymore. You cannot take such a told in the long 
run. But if you feel like the project has gone side way and you prefer the 
alternative fork, this is what open source is for. 


-->1) Kids who only learn the new stuff can't be hired to support the old 
because they cannot even begin to function.
- We do have people from 22 to over 50, they code from embedded mcu C to Qt5 
without problems, I suggest you hired from different schools.

--> 2) If someone decides to pull the plug on their really old embedded OS in 
favor of a roll-your-own Yocto Linux build, they can't even bring their code 
forward. The entire cross-platform aspect of Qt has been abandoned. It's only 
cross-platform for "the cool kids."
- Far from it, I found Qt more open to platform (MCU, embedded, web...). What 
is wrong with rolling out Yocto? for embedded system this is a good way. If the 
OS is deprecated and unsupported, continue to use the tools that were going 
along with it and stay frozen into time with it if you want. 

-->*No core API changes that break backward compatibility. *
- They mostly have minor changes between minor version or not even at all. 
Those are between major Qt version and let's face it, it's normal to make thing 
evolve, just like C++ is evolving too. I manage to maintain few application 
from 5.6 to 5.15 in the past few years, the most problems I got was with 
Android/iOS and the Play/App Store requirements, the Qt was easy to and mostly 
smooth.

My opnion, doesn't reflect any cie but my own.

-Original Message-
From: Roland Hughes  
Sent: June 15, 2020 12:06 PM
To: Jérôme Godbout ; interest@qt-project.org; Thiago 
Macieira 
Subject: Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

You completely miss the point.

Qt has been prone to sweeping API changes mostly due to the fact they keep 
chasing the iDiot phone market. If that is the market they want, fine, but they 
had best fess up now so everyone else can go somewhere else.

You can't take someone who learned via Qt 5 and have them work in Qt 3 because 
it is night and day different.

You can change an awful lot without going down the full clinical trial path. IT 
ALL DEPENDS ON RISK.

That device I linked went through some kind of enhancement approval path. I 
don't know what it replaced exactly, but I do know the previous device did not 
use Linux or Qt. I know because I worked on that project.

When you get out into the world of industrial controls, they don't have the FDA 
level of certification. They do have 20-50 year lifespans though. These are 
things with a base price of half a million going well up past $5-$6 million. 
They have a minimum 30 year life span, most are closer to 50. Many of them are 
running DOS, WinCE, and the embedded version of Windows 7. It's bad enough that 
Qt keeps dropping everything the industrial and medical world needs in pursuit 
of the iDiot phone market, BUT ADDING INSULT TO INJURY THEY KEEP MAKING 
SWEEPING API CHANGES. This means two things:

1) Kids who only learn the new stuff can't be hired to support the old because 
they cannot even begin to function.

2) If someone decides to pull the plug on their really old embedded OS in favor 
of a roll-your-own Yocto Linux build, they 

Re: [Interest] Connecting signal handler to Qt application - async-handler-safety

[Thiago Macieira]

On segunda-feira, 15 de junho de 2020 04:06:28 PDT Giuseppe D'Angelo via 
Interest wrote:
> On Linux you can also use signalfd(2) to achieve the same without the
> burden of a custom signal handler.

No, you can't, because you need to block the signal using pthread_sigmask in 
all threads, otherwise the kernel may prefer delivering the signal instead of 
using the signalfd. Qt has a few background threads (like the QHostInfo thread 
pool) that you don't have access to.

signalfd is a misfeature. Don't use it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Connecting signal handler to Qt application - async-handler-safety

[Thiago Macieira]

On segunda-feira, 15 de junho de 2020 03:58:12 PDT Bernhard Lindner wrote:
> I wrote a logging application containing a signal handler that is registered
> using std::signal(). The handler receives signals like SIGFPE, SIGSEGV,
> etc.
> 
> Now I would like to connect that handler to some Qt based logging code.
> Unfortunately I could not find a portable solution to do that.
> 
> Are there any functions in Qt that are considered async-handler-safe?

Absolutely none. Please restrict your use in the signal handler to only the 
functions listed here:
https://man7.org/linux/man-pages/man7/signal-safety.7.html

> I'm especially looking for a way to send a (queued) signal. Other portable
> ways to wake the application from the event loop would be fine as well.

The simplest solution for this is to write some from the signal handler 
information to a pipe. It can be just a single byte to wake up the event loop. 
Then the main Qt event loop will pick that up via QSocketNotifier and act 
accordingly.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

[Roland Hughes]

You completely miss the point.

Qt has been prone to sweeping API changes mostly due to the fact they 
keep chasing the iDiot phone market. If that is the market they want, 
fine, but they had best fess up now so everyone else can go somewhere else.


You can't take someone who learned via Qt 5 and have them work in Qt 3 
because it is night and day different.


You can change an awful lot without going down the full clinical trial 
path. IT ALL DEPENDS ON RISK.


That device I linked went through some kind of enhancement approval 
path. I don't know what it replaced exactly, but I do know the previous 
device did not use Linux or Qt. I know because I worked on that project.


When you get out into the world of industrial controls, they don't have 
the FDA level of certification. They do have 20-50 year lifespans 
though. These are things with a base price of half a million going well 
up past $5-$6 million. They have a minimum 30 year life span, most are 
closer to 50. Many of them are running DOS, WinCE, and the embedded 
version of Windows 7. It's bad enough that Qt keeps dropping everything 
the industrial and medical world needs in pursuit of the iDiot phone 
market, BUT ADDING INSULT TO INJURY THEY KEEP MAKING SWEEPING API 
CHANGES. This means two things:


1) Kids who only learn the new stuff can't be hired to support the old 
because they cannot even begin to function.


2) If someone decides to pull the plug on their really old embedded OS 
in favor of a roll-your-own Yocto Linux build, they can't even bring 
their code forward. The entire cross-platform aspect of Qt has been 
abandoned. It's only cross-platform for "the cool kids."



What we really need is for KDE to announce what their new development 
library is. The desktop, medical, and industrial device world will move 
their money and resources to that library and Qt will be left with 
nothing but the phone market. The "new" choice must promise the following:


*No core API changes that break backward compatibility. *

They can add optional parameters to the end of a parameter list, but no 
class name changes, no method name changes, no dropping of methods.


They can add new classes, but everything that was there in 2019/2020 has 
to still be there in 2050.


The insult added to the injury of Qt dropping operating systems is they 
change sh*t willy-nilly without even the slightest thought given to the 
installed base. The people who aren't starting over every six months.



On 6/15/20 10:10 AM, Jérôme Godbout wrote:

This is exactly my point, that device is STILL on Qt3 because you don't want to 
go all over that certifications/testing just for changing a Qt versions. You 
can enchance it, but you will need to proof the changes impacts have been cover 
in testings and no risk have been added. Those system, nearly never get update 
libs or anything at large because you have to retests and recertify the whole 
thing. Just changing the model of an harddrive into a machine make a need to 
recertify. So those device will never care if the bleeding edge Qt doesn't 
support their platform. They are fixed with known version of differents libs 
that are known to be workign together and tested.

Those device are not using anything bleeding edge, so let alone runing any 
Windows 7 or Windows 10 with Qt6 in the near time. If anything into those 
domain start using Qt6 it will probably be a new design or a new version that 
will need to be certified all over again anyway, so the upgrade path is not 
there.

-Original Message-
From: Roland Hughes 
Sent: June 15, 2020 10:11 AM
To: Jérôme Godbout ; interest@qt-project.org; Thiago Macieira 

Subject: Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

I seriously beg to differ.

In America "upgrades" and field patches have a completely different certification path 
than "shiny new device." What has to be certified is based on the extent of the changes 
and how well the FDA documentation is filled out.

That OS/2 Qt3 medical device I get an email about ever 18 months or so continues to get 
enhancements. Changing to even Qt for or Linux would push it to "shiny new 
device" depending on the assessed risk level.

A patient monitor like this one

https://www.welchallyn.com/en/products/categories/patient-monitoring/vital-signs-devices/connex-spot-monitor.html

Has a completely different risk level than say, an infusion pump.

I have worked on products that just added new features to existing lines. In 
America it happens all of the time.


On 6/15/20 8:33 AM, Jérôme Godbout wrote:

I have work for medical devices for over 10 years and used Qt from 4.x to 5.8 
(move out to IoT lately), designing system and software. Cie who do that, did 
it wrong, you have to ensure your software will run and you maintaint it, but 
in no way you will add any new features (you will need to certify again!). You 
keep a system images that can recreate the exact same output (OS, build tools, 
...), you 

Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

[Jérôme Godbout]

This is exactly my point, that device is STILL on Qt3 because you don't want to 
go all over that certifications/testing just for changing a Qt versions. You 
can enchance it, but you will need to proof the changes impacts have been cover 
in testings and no risk have been added. Those system, nearly never get update 
libs or anything at large because you have to retests and recertify the whole 
thing. Just changing the model of an harddrive into a machine make a need to 
recertify. So those device will never care if the bleeding edge Qt doesn't 
support their platform. They are fixed with known version of differents libs 
that are known to be workign together and tested.

Those device are not using anything bleeding edge, so let alone runing any 
Windows 7 or Windows 10 with Qt6 in the near time. If anything into those 
domain start using Qt6 it will probably be a new design or a new version that 
will need to be certified all over again anyway, so the upgrade path is not 
there.

-Original Message-
From: Roland Hughes  
Sent: June 15, 2020 10:11 AM
To: Jérôme Godbout ; interest@qt-project.org; Thiago 
Macieira 
Subject: Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

I seriously beg to differ.

In America "upgrades" and field patches have a completely different 
certification path than "shiny new device." What has to be certified is based 
on the extent of the changes and how well the FDA documentation is filled out.

That OS/2 Qt3 medical device I get an email about ever 18 months or so 
continues to get enhancements. Changing to even Qt for or Linux would push it 
to "shiny new device" depending on the assessed risk level.

A patient monitor like this one

https://www.welchallyn.com/en/products/categories/patient-monitoring/vital-signs-devices/connex-spot-monitor.html

Has a completely different risk level than say, an infusion pump.

I have worked on products that just added new features to existing lines. In 
America it happens all of the time.


On 6/15/20 8:33 AM, Jérôme Godbout wrote:
> I have work for medical devices for over 10 years and used Qt from 4.x to 5.8 
> (move out to IoT lately), designing system and software. Cie who do that, did 
> it wrong, you have to ensure your software will run and you maintaint it, but 
> in no way you will add any new features (you will need to certify again!). 
> You keep a system images that can recreate the exact same output (OS, build 
> tools, ...), you patch the bug that's all you should do. New features will be 
> done into a new system that will need to be certify all over again.
>
> Upgrading to Qt6 for already certified devices is a no go, no matter what for 
> them. This is totally irrelevent. You only upgrade tools and libs when you 
> create a new system (version, design, etc) that will be certified again.
>
>
> -Original Message-
> From: Interest  On Behalf Of Roland Hughes
> Sent: June 13, 2020 11:08 AM
> To: interest@qt-project.org; Thiago Macieira 
> Subject: Re: [Interest] [Development] Windows 7 support will be dropped in Qt 
> 6
>
> Medical devices are certified with their manufacturing process.
> Certification of something like a surgical robot can take 5+ years of 
> clinical trials. That is _after_ you have done all of your internal 
> development and cadaver trials.
>
> On 6/13/20 5:00 AM, interest-requ...@qt-project.org wrote:
>>> That's partially for their own peace of mind and stability, but along
>>> with that, many tool vendors take quite a while to certify their
>>> offerings, both hardware and software, which gives people another
>>> reason to stay behind.
>> More than two years?
> --
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593
>
> http://www.theminimumyouneedtoknow.com
> http://www.infiniteexposure.net
> http://www.johnsmith-book.com
> http://www.logikalblog.com
> http://www.interestingauthors.com/blog
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

[Roland Hughes]

I seriously beg to differ.

In America "upgrades" and field patches have a completely different 
certification path than "shiny new device." What has to be certified is 
based on the extent of the changes and how well the FDA documentation is 
filled out.


That OS/2 Qt3 medical device I get an email about ever 18 months or so 
continues to get enhancements. Changing to even Qt for or Linux would 
push it to "shiny new device" depending on the assessed risk level.


A patient monitor like this one

https://www.welchallyn.com/en/products/categories/patient-monitoring/vital-signs-devices/connex-spot-monitor.html

Has a completely different risk level than say, an infusion pump.

I have worked on products that just added new features to existing 
lines. In America it happens all of the time.



On 6/15/20 8:33 AM, Jérôme Godbout wrote:

I have work for medical devices for over 10 years and used Qt from 4.x to 5.8 
(move out to IoT lately), designing system and software. Cie who do that, did 
it wrong, you have to ensure your software will run and you maintaint it, but 
in no way you will add any new features (you will need to certify again!). You 
keep a system images that can recreate the exact same output (OS, build tools, 
...), you patch the bug that's all you should do. New features will be done 
into a new system that will need to be certify all over again.

Upgrading to Qt6 for already certified devices is a no go, no matter what for 
them. This is totally irrelevent. You only upgrade tools and libs when you 
create a new system (version, design, etc) that will be certified again.


-Original Message-
From: Interest  On Behalf Of Roland Hughes
Sent: June 13, 2020 11:08 AM
To: interest@qt-project.org; Thiago Macieira 
Subject: Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

Medical devices are certified with their manufacturing process.
Certification of something like a surgical robot can take 5+ years of clinical 
trials. That is _after_ you have done all of your internal development and 
cadaver trials.

On 6/13/20 5:00 AM, interest-requ...@qt-project.org wrote:

That's partially for their own peace of mind and stability, but along
with that, many tool vendors take quite a while to certify their
offerings, both hardware and software, which gives people another
reason to stay behind.

More than two years?

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

[Jérôme Godbout]

I have work for medical devices for over 10 years and used Qt from 4.x to 5.8 
(move out to IoT lately), designing system and software. Cie who do that, did 
it wrong, you have to ensure your software will run and you maintaint it, but 
in no way you will add any new features (you will need to certify again!). You 
keep a system images that can recreate the exact same output (OS, build tools, 
...), you patch the bug that's all you should do. New features will be done 
into a new system that will need to be certify all over again.

Upgrading to Qt6 for already certified devices is a no go, no matter what for 
them. This is totally irrelevent. You only upgrade tools and libs when you 
create a new system (version, design, etc) that will be certified again.


-Original Message-
From: Interest  On Behalf Of Roland Hughes
Sent: June 13, 2020 11:08 AM
To: interest@qt-project.org; Thiago Macieira 
Subject: Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

Medical devices are certified with their manufacturing process. 
Certification of something like a surgical robot can take 5+ years of clinical 
trials. That is _after_ you have done all of your internal development and 
cadaver trials.

On 6/13/20 5:00 AM, interest-requ...@qt-project.org wrote:
>> That's partially for their own peace of mind and stability, but along 
>> with that, many tool vendors take quite a while to certify their 
>> offerings, both hardware and software, which gives people another 
>> reason to stay behind.
> More than two years?

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

[Roland Hughes]

On 6/15/20 5:00 AM, Thiago Macieira wrote:

GCC didn't achieve a good C++17 support until GCC 7 (released in May 2017).
CentOS 5 reached EOL in March 2017. So there's no official devtoolset
containing GCC 7.


It wasn't until gcc 8 that they got "full" C++17 support at least as I 
read a while back.


There is always the old fashioned way.

https://gcc.gnu.org/wiki/InstallingGCC

I will admit I didn't pay incredibly close attention as to whether Scott 
was still supporting CentOS 5 or had finally gotten off it and up to 
CentOS 6. Someone else most likely faced this problem and did the port 
or wrote a blog post with good instructions about everything you need to 
do to build from scratch.


My God, someone ported GCC 7 to OS/2.

https://www.dropbox.com/s/o5skkve3nnlj2o0/gcc-7.1.0-os2-20170507.zip?dl=0

Unless the compiler physically needs something the OS cannot provide, 
where there is a will there is a way.


I've always found, when it came to distros not wanting to port something 
that they suddenly "want" when you throw money at them. I remember there 
was a number of around a million tossed around for these tools/products. 
That's a different universe than Joe Palluka and his freeware. The 
"maintainer" of devtools may have "no time or interest" in building a 
semi or fully official devtools 8 for CentOS 5. I guarantee if you offer 
$20-$30K for the task, one of them will have a "free weekend" suddenly 
come up.


At any rate, those of us in the medical device/embedded systems world 
have to make some hard decisions very soon because of the relentless 
pursuit of iDiot phones by the Qt project and the continual dropping of 
the platforms we are using. Not just the platform dropping, the sweeping 
API changes so you can't take a new Qt developer and have even the 
faintest hope of them being able to work with the old stuff. If all they 
know is QML and JavaScript, in this realm, they can't even be called Qt 
developers. Sorry, but that is reality. This particular world uses 
native binary.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Connecting signal handler to Qt application - async-handler-safety

[Giuseppe D'Angelo via Interest]

Il 15/06/20 12:58, Bernhard Lindner ha scritto:


Are there any functions in Qt that are considered async-handler-safe?


No, as any of them may allocate memory.

See https://doc.qt.io/qt-5/unix-signals.html for the textbook solution 
(self pipe trick).


On Linux you can also use signalfd(2) to achieve the same without the 
burden of a custom signal handler.


HTH,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Connecting signal handler to Qt application - async-handler-safety

[Bernhard Lindner]

Hi!

I wrote a logging application containing a signal handler that is registered 
using
std::signal(). The handler receives signals like SIGFPE, SIGSEGV, etc.

Now I would like to connect that handler to some Qt based logging code.
Unfortunately I could not find a portable solution to do that.

Are there any functions in Qt that are considered async-handler-safe? 

I'm especially looking for a way to send a (queued) signal. Other portable ways 
to wake
the application from the event loop would be fine as well.

-- 
Best Regards,
Bernhard Lindner

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

[Henry Skoglund]

On 2020-06-15 12:37, Florian Bruhin wrote:

On Thu, Jun 11, 2020 at 06:02:53PM +, Jérôme Godbout wrote:

or Windows 11 by the time Qt 6 and you get your application ready "Microsoft
will release Windows 11 on July 29, 2020, and will be available to the
general public."

Do you have a source for that? I'm assuming it's
https://www.window11updates.com/ which is a hoax.

Florian

Wow! They also have Windows 12 
https://www.window11updates.com/windows-12-lite-download-linux-iso/

(must be *even better* than Windows 11 :-)
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

[Florian Bruhin]

On Thu, Jun 11, 2020 at 06:02:53PM +, Jérôme Godbout wrote:
> or Windows 11 by the time Qt 6 and you get your application ready "Microsoft
> will release Windows 11 on July 29, 2020, and will be available to the
> general public."

Do you have a source for that? I'm assuming it's
https://www.window11updates.com/ which is a hoax.

Florian

-- 
m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org 
   https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/


signature.asc
Description: PGP signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Getting QGraphicsView from within a mouse event

[Giuseppe D'Angelo via Interest]

Il 15/06/20 03:26, Nicholas Yue ha scritto:
The return widget object does not have a viewport() method from looking 
at the QWidget - docs 


void AttributeItem::mousePressEvent(QGraphicsSceneMouseEvent* event)
{
     if (event->button()==Qt::LeftButton)
     {
         QWidget *w = event->widget();
     } else
         QGraphicsItem::mousePressEvent(event);
}


Sorry, what I meant is the other way around: the widget returned *is* 
the viewport() of your QGraphicsView. (So, typically, getting the parent 
widget of that widget will give you QGV you're looking for.)


HTH,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

[Oliver Wolff]

Hi,

On 13.06.2020 09:20, Konrad Rosenbaum wrote:

On 2020-06-12 02:44, Hamish Moffatt wrote:

On 12/6/20 10:17 am, Scott Bloom wrote:

Why is Win7 being dropped?  I (my company) has gotten burned pretty
hard by the dropping of CentOS 6, similar reasons listed for win7..


It's funny that there's so much discussion about dropping Windows 7
which was released 11 years ago.

Yet Qt 5.15 already dropped macOS prior to 10.13, which is not even 3
years old. And Qt trunk requires 10.14, which is only 2 years old.
This is really a major PITA.



 From an industry perspective: I have seen lots of machines running all
kinds of outdated versions of Windows(*) or rather old versions of
RedHat or embedded Linux(**), but it has been a very very long time
since I have seen a machine running some Apple product of any version.
I.e. there are plenty of Windows users who have the bucks to demand long
term support for their systems, the same cannot be said for Apple users.

(*)if you walk into a running factory it is pretty normal to find a
large portion of the machines running XP, I would not be surprised to
find a W2k machine or even a machine running DOS in a factory that has
been running for 15 years. New factories will have plenty of machines
running Win7, because new OSes is simply not what the machine suppliers
care about most.


The topic of some machines that are running medieval versions of windows 
in some factory seems to come up again and again. While these use cases 
are valid, you also state that the companies "do not touch these running 
systems". So the big question that remains here is the following: Why 
would anyone update Qt on a machine like that? They have been happily 
been running DOS for the last decade and longer. On other systems they 
are using Windows XP or Windows 7. If you cannot update the operating 
system for these systems and are stuck with an unsupported OS, being 
"stuck" with an unsupported Qt version does not sound like a dealbreaker 
to me.


How many of these machines would get a Qt update if Qt 6 supported 
Windows 7?


Olli



(**)you will regularly find machines running a 2.6 kernel, some may even
run 2.4. Many GUIs look suspiciously Motif-like and if you get to see
the window manager behind the full-screen GUI it may look eerily CDE-ish
or FVWM-like.

Industry is willing to pay large amounts of support and maintenance
costs for the machines they run - this is what keeps people like Roland
and me well fed. Unless you can find a large industry or two that care
about legacy MacOS and are willing to pay tons of money for support, it
will stay bleeding edge because maintenance cost goes up exponentially
with the number of systems you have to support.



     Konrad



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

[Thiago Macieira]

On domingo, 14 de junho de 2020 10:55:20 PDT Roland Hughes wrote:
> Requires a C++17 compiler. 

> given the wide range of gcc versions I'm guessing nobody tried until
> Centos 8 and you probably could get things to compile for Centos 5.

Those two statements are contradictory. Getting a C++17-capable compiler 
working on CentOS/RHEL 5 is going to be very difficult.

GCC didn't achieve a good C++17 support until GCC 7 (released in May 2017). 
CentOS 5 reached EOL in March 2017. So there's no official devtoolset 
containing GCC 7.

I'm pretty sure the version of Qt they forked from already didn't support 
CentOS 5.

If you meant CentOS 6 instead, that's another story.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest