subject:"\[Interest\] \[Development\] Windows 7 support will be dropped in Qt 6"



On 6/18/20 3:48 PM, Christoph Feck wrote:

We are all just waiting on KDE to pull the trigger and tell us what
library(ies) will be used in the post-Qt world. The current licensing
and royalty situation make Qt unusable going forward.

There is no post-Qt world from the KDE point of view. It is impossible
to port hundreds of applications to a different toolkit, and this is the
reason we secured the availability of Qt in source code form under a
free software license via written agreements.


It's not impossible, just look at all of the abandonware in KDE history now.

A lot of work, possibly. Depends on the chosen library. CopperSpice 
would shorten that effort. Something completely different would extend it.


Given the new licensing, dropping of Win7, announced year or so delay of 
OpenSource releasing, now is the perfect time. Begin the ports prior to 
the end of Qt 5 and before anything migrates to Qt 6.


As with KDE in the past, some packages will get ported and some will get 
abandoned.


Keep in mind KDE abandoned other things to choose Qt when Trolltech was 
around.


This is not without precedent. There will be a migration from Qt. Far 
too many people and customers are fed up.



--
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

2020-06-18 Thread Thiago Macieira

On Thursday, 18 June 2020 12:09:52 PDT Roland Hughes wrote:
> We need KDE (and many of those people watch this list) to publicly
> announce its decision well before Qt 6 comes out so we can all be well
> on the way porting before the end of Qt 5. Now is the obvious time for a
> complete and clean break.

The answer is: Qt.

There will be no change in libraries.

-- 
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

2020-06-18 Thread Christoph Feck


On 06/18/20 19:27, Roland Hughes wrote:

We are all just waiting on KDE to pull the trigger and tell us what
library(ies) will be used in the post-Qt world. The current licensing
and royalty situation make Qt unusable going forward.


There is no post-Qt world from the KDE point of view. It is impossible
to port hundreds of applications to a different toolkit, and this is the
reason we secured the availability of Qt in source code form under a
free software license via written agreements.

BG,
Christoph Feck

___
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



On 6/18/20 1:42 PM, Giuseppe D'Angelo wrote:

I've refrained from commenting in so far, but I think we're now passing
the threshold... could we please, everyone, STAY ON TOPIC on this
mailing list?


We currently are on topic.

qt-interest.

Yet another ill-informed decision on the direction of Qt. This, the 
dropping of support for Windows 7, when added to the licensing and 
royalty policies of Qt Company, and all the other ill-informed decisions 
guiding the course of Qt over the years (and multiple owners) is what 
many here don't understand.


Those without any schooling in celestial navigation are attempting to 
steer the ship at night.


We just need KDE to make its final announcement __AND SOON__ as to what 
new set of libraries will be the core KDE development so the medical 
device and industrial control world can take our customers, our product, 
our projects, and our money and leave Qt Company forever.


The rest of this conversation has been trying to explain to those 
steering the ship at night just how many reefs they hit and that no, 
water should not be coming over the main deck on a calm sea.


We need KDE (and many of those people watch this list) to publicly 
announce its decision well before Qt 6 comes out so we can all be well 
on the way porting before the end of Qt 5. Now is the obvious time for a 
complete and clean break.


I "hope" it will be CopperSpice because when I'm not being inundated 
with emails from this list and/or Quora that's where I'm focusing my 
efforts. If it is some other tool set then I will have to spin around in 
that direction, but the shortest hop appears to be CopperSpice. If KDE 
wants to make a major pole vault in a different direction then hopefully 
they would announce it later today giving everyone as much time as possible.


--
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

2020-06-18 Thread Jérôme Godbout

>>> But you created an object in C++; exposed it to worthless QML; being 
>>> worthless QML handed it off to JavaScript. Now three different garbage 
>>> collection systems believe they "own" it. On a gasping for its last breath 
>>> undersized processor to extend battery life, everything is fine because 
>>> garbage collection never runs. Move your code to a really good processor 
>>> and suddenly things crash all over. The object got deleted yet QML and 
>>> JavaScript each think they own it. When they try to reference (or double 
>>> delete) it fails.

You don't need to  make your object all be declare into Qml, only the Gui 
should be in Qml in a normal design, keep your controler, models and everything 
else into C++. You also can check and change the ownership of each object from 
C++ or to Javascript if you want to swing them. Nothing too difficult there. 
The Qml object follow the parent just like any other QObject. QQmlEngine 
interpret the declarative code (and soon will compile it to C++ into Qt6), what 
wrong with it? If you have double delete, you have bad design or you have 
mutliple owner of an object (just like you can do with C++ and the unique_ptr, 
shared_ptr). Qml only simplify the writing of connection between the GUI and 
the core of the application (business logic, true code). Normally if your 
application is well design, you can strip the Qml layer and make a command line 
interface without change to your core code or you can swap the Qml layer with 
QWidgets one (and take a close look at how much more code you will need to 
achieve the same results and reactivity).

The extra mile to expose the C++ object to meta is not great but also offer 
other options, Qt meta allow a lot of reflection to C++. One day we can get 
ride of it when the C++ refelection make it to the standard (there something on 
the near horizon fromwhat I saw), but I would not put too much effort on it 
until they do, no need to rewrite 3x the meta/moc.

As for RAM usage I agree, device have become very hungry, but on the other hand 
you can make something consume a lot of ram and still run quickly, nobody want 
to pay top dollars to optimize the assembly anymore, the RAM price is so cheap 
compre to developr time price, the resulting business will easily go screw 
optimization and just crank up the specs of the hardware (this is often cheaper 
and make more sense business wise).

-Original Message-
From: Interest  On Behalf Of Roland Hughes
Sent: June 18, 2020 1:27 PM
To: Matthew Woehlke ; interest@qt-project.org
Subject: Re: [Interest] [Development] Windows 7 support will be, dropped in Qt 6

On 6/18/20 11:17 AM, Matthew Woehlke wrote:
> On 18/06/2020 11.11, Roland Hughes wrote:
>> Could someone from such a background learn enough C syntax to write a 
>> student C program like this one?
>> [example program elided]
>
> Maybe. To the point various others are making, just because someone 
> hasn't learned the fundamentals doesn't mean they're incompetent.
>
> OTOH, not everyone can learn competence. The point is, *you just don't 
> know*.

The point is we are the sum of our training and experience. Without the formal 
training there is an incredibly high probability one will end up in an AGILE 
shop instead of a Software Engineering shop. In an AGILE shop, their 
"experience" won't be good stuff promoting professional growth.

As to "various others making" I get this via digest unless someone direct 
includes me. I will see the "various others making" at some point over the next 
few days when I have time to look at the digest. Trying to add Debian build 
support to Gede right now. Not a difficult thing, just needs focus.

>
>> Could that same person write a page swapping system for a Linux-like 
>> OS from scratch? No.
>
> Again, *maybe*. Not, perhaps, without learning the fundamentals first, 
> but as noted, just because they haven't learned *yet* doesn't mean 
> they can't. But, again, there are plenty of people that can muddle 
> through basic stuff with "training wheels" languages that *can't* 
> grasp the fundamentals well enough for such tasks, and that's the 
> point you (Roland) and I are making.

I guess I should have added "in under a year." There is a time thing on the 
front end too, I just don't want to put any thought into what it is right now. 
The longer you spend in an AGILE shop where nobody was professionally trained, 
the more bad practices and habits you pick up. 
There comes a tipping point where you physically can't go back and learn the 
fundamentals because they are contrary to what you do each and every day.

>
> To be fair, I might be in the latter category. I don't recall
> *formally* learning much about memory management (although there was 
> some gene

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



On 6/18/20 11:17 AM, Matthew Woehlke wrote:

On 18/06/2020 11.11, Roland Hughes wrote:
Could someone from such a background learn enough C syntax to write a 
student C program like this one?

[example program elided]


Maybe. To the point various others are making, just because someone 
hasn't learned the fundamentals doesn't mean they're incompetent.


OTOH, not everyone can learn competence. The point is, *you just don't 
know*.


The point is we are the sum of our training and experience. Without the 
formal training there is an incredibly high probability one will end up 
in an AGILE shop instead of a Software Engineering shop. In an AGILE 
shop, their "experience" won't be good stuff promoting professional growth.


As to "various others making" I get this via digest unless someone 
direct includes me. I will see the "various others making" at some point 
over the next few days when I have time to look at the digest. Trying to 
add Debian build support to Gede right now. Not a difficult thing, just 
needs focus.




Could that same person write a page swapping system for a Linux-like 
OS from scratch? No.


Again, *maybe*. Not, perhaps, without learning the fundamentals first, 
but as noted, just because they haven't learned *yet* doesn't mean 
they can't. But, again, there are plenty of people that can muddle 
through basic stuff with "training wheels" languages that *can't* 
grasp the fundamentals well enough for such tasks, and that's the 
point you (Roland) and I are making.


I guess I should have added "in under a year." There is a time thing on 
the front end too, I just don't want to put any thought into what it is 
right now. The longer you spend in an AGILE shop where nobody was 
professionally trained, the more bad practices and habits you pick up. 
There comes a tipping point where you physically can't go back and learn 
the fundamentals because they are contrary to what you do each and every 
day.





To be fair, I might be in the latter category. I don't recall 
*formally* learning much about memory management (although there was 
some generic algorithms stuff); nevertheless, my first professional 
job was pure C and I managed well enough. I'd like to think I'm 
competent, if not amazing.


You are probably way better than I. The point is when you take someone 
from a training wheels environment where all memory manage is handled 
for them and drop them into C or any other language where formal 
training really is required; they don't have memory "leaks" in their 
programs they have memory rivers. Most will attempt the Microsoft 
solution; "Throw hardware at it!" Suddenly the Television remote control 
they are working on needs 24Gig of RAM so it can go a month between reboots.





As an example, I don't consider deleteLater a major source of 
headaches (and most of my stuff *does* run on reasonably modern 
machines). Almost always if I use deleteLater, it's because I *know* 
that I can't just delete it *now*. I'm aware of needing to ensure that 
objects are either a) not deleted while in use, or b) are always 
referenced through *checked* weak pointers.


But you created an object in C++; exposed it to worthless QML; being 
worthless QML handed it off to JavaScript. Now three different garbage 
collection systems believe they "own" it. On a gasping for its last 
breath undersized processor to extend battery life, everything is fine 
because garbage collection never runs. Move your code to a really good 
processor and suddenly things crash all over. The object got deleted yet 
QML and JavaScript each think they own it. When they try to reference 
(or double delete) it fails.


One cannot safely add virtual machines (plural) to a compiled language 
if one or more tools used in the compiled language provide some 
level/type of garbage collection.


We are all just waiting on KDE to pull the trigger and tell us what 
library(ies) will be used in the post-Qt world. The current licensing 
and royalty situation make Qt unusable going forward.


--
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

2020-06-18 Thread Giuseppe D'Angelo via Interest

I've refrained from commenting in so far, but I think we're now passing 
the threshold... could we please, everyone, STAY ON TOPIC on this 
mailing list?


Thank you,
--
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

2020-06-18 Thread Matthew Woehlke


On 18/06/2020 11.11, Roland Hughes wrote:
Could someone from such a background learn enough C syntax to write a 
student C program like this one?

[example program elided]


Maybe. To the point various others are making, just because someone 
hasn't learned the fundamentals doesn't mean they're incompetent.


OTOH, not everyone can learn competence. The point is, *you just don't 
know*.


Could that same person write a page swapping system for a Linux-like OS 
from scratch? No.


Again, *maybe*. Not, perhaps, without learning the fundamentals first, 
but as noted, just because they haven't learned *yet* doesn't mean they 
can't. But, again, there are plenty of people that can muddle through 
basic stuff with "training wheels" languages that *can't* grasp the 
fundamentals well enough for such tasks, and that's the point you 
(Roland) and I are making.


When one comes from the scripting/interpreted language background; 
especially if they never got a degree from a good school that taught 
them proper fundamentals of software development; that is the training 
wheels never off the bike.


Put them on C. No garbage collection. Requires proper understanding of 
the fundamentals, especially Application Design, System Architecture, 
and Data Structures. Basically it requires the skill to ride a bike that 
goes very fast and can never have training wheels put on it.


Yup... Some can figure it out. Some won't.

To be fair, I might be in the latter category. I don't recall *formally* 
learning much about memory management (although there was some generic 
algorithms stuff); nevertheless, my first professional job was pure C 
and I managed well enough. I'd like to think I'm competent, if not amazing.


As an example, I don't consider deleteLater a major source of headaches 
(and most of my stuff *does* run on reasonably modern machines). Almost 
always if I use deleteLater, it's because I *know* that I can't just 
delete it *now*. I'm aware of needing to ensure that objects are either 
a) not deleted while in use, or b) are always referenced through 
*checked* weak pointers.


(Right now I'm working on unit tests for a non-Qt signal/slot system 
that needs to handle race conditions between the signal being emitted or 
destroyed at the same time the receiver is destroyed. Fun times, but not 
a problem outside of my experience, as it would be for someone that only 
knows Java/Python/etc.)


--
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


Sorry, Internet was down much of yesterday.

On 6/17/20 5:00 AM, interest-requ...@qt-project.org wrote:
Sorry but I must chime in here, since both Roland and Matthew brought 
this point up.

it's well "known" that you can teach C programmers Java, but you can't

teach Java programmers C

How is that well known? What studies can you provide for this?
Currently it just sounds like elitism at its finest to me if I'm honest.
I started with Java, and can now write C pretty well. Most of my local
universities teach Java, do you want to imply those people will never
ever be able to learn C? I have a few friends that started in Java, some
even staying there for years before moving on to C, C++, Rust, Haskell, etc.


Not elitism, just the reality of the journey.

Sorry to have to re-paste this, but the "Where do I start" question 
comes up at least 5 times per day with slightly different wording so 
I've just stuck the response in a document file.




The school matters. You want one offering the following:

*Programming Logic (sans any programming language)*. Just flow charting 
and later pseudocode. If they are teaching Pascal or some other language 
in their logic class toss their brochure in the trash bin. You need to 
learn how to “see” a solution.


*Data Structures (sans any programming language)*. Some places will 
dovetail this into the logic class. Whether that is okay or not depends 
on how fast the class is learning. It is important to understand 
conceptually/visually how stacks, queues, and the like work. They are 
part of your logic tools.


*System Architecture (sans any programming language)*. You need to 
understand the full ecosystem of software. There is oceans more to data 
processing than the x86 and your laptop. You need to conceptually 
understand how something as large and complex as the IRS income tax 
processing system is put together. There are a lot of pieces. There is 
no cookie cutter solution. What you have to learn here is not only the 
differences between the tech, /but the why behind the choices/. There is 
a reason it is cheaper for some companies to buy and use 
MQSeries/Websphere than use a “free” OpenSource product. There is a 
reason you have to use a Tandem, Cray, or IBM. You have to understand 
the reasons.


*Application Design/Architecture (sans any programming language)*. After 
you understand the ecosystem you can learn how to correctly design your 
applications. No language should be taught here. This is more the focus 
of system flow diagrams and architectural choices. Will you use a 
relational database? If so, which one?Why? Does this application need a 
touch screen? Why? If this program is for intense data entry should the 
user ever have to touch the mouse after the program is launched? Why?


*Relational Database Use and Design (will require SQL and whatever 
language is used for stored procedures.)*You might need/want to take 
this before Application Design/Architecture. The vast majority of 
programmers currently working in IT know /nothing/about this topic. If 
you see someone promoting MVVM, you know beyond a shadow of a doubt they 
know nothing about the care, feeding, and use of a relational database.


No data is of any value without a relation.

25

What’s that? It’s a number, but what does it mean? People pushing MVVM 
thing that should be an object, all by itself, floating around in 
computer memory able to appear in random locations on the screen. To me 
that sounds like a virus, not an application architecture.


Jane Smith, 25, Sarasota, FL

Now we have some idea about what 25 means. The relation is what gives it 
meaning. Without the relation it has no meaning.


-

I cut it down to about half the response. While there are some schools 
still taking the proper course, teaching the fundamentals without 
teaching a language in them; most take the quick and dirty path. They 
will use Pascal or some language like it in both Logic and Data 
Structures. The students learn Pascal, not the subject.


Many courses don't even teach the fundamentals anymore. They just jump 
shiny new students into script-kiddie languages hacking out Web pages on 
day one.


In America, most large municipalities require electricians, plumbers, 
and many other "trades" workers to be licensed and bonded. Obtaining a 
license requires passing a training program and certification exam. This 
is because people's lives depend on what they make.


For many years a B.S. in Computer Information Systems (or the handful of 
other titles) was our certification that we had been taught and 
understood the fundamentals. Run-for-profit schools started playing fast 
and loose with the coursework.


Today we have kids reading half (or less) of a "Teach Yourself How to Be 
Totally Useless in 24 Hours or Less" book and hanging their shingle out 
as a freelancer. It's the "trades" equivalent of someone buying a hammer 
and driving one nail then claiming they are a carpenter qualified to

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

2020-06-17 Thread Massimiliano Maini

 I have no real opinion on dropping or not the support for Win7, but I
don't get how the specific needs of some
industries (having people that can work on legacy/non-modern platforms
and/or languages) are related to the
rant against the fact Qt6 could drop Win7 support.

What are some asking ? For Qt6 not to evolve too much so that it
doesn't become too different from Qt3 ?!
We all stick to command prompts even for tasks that are better tackled with
a gui, because if we go gui then
some people won't like command prompt any more ?

I've worked in sectors where the platforms and tools lag behind the
bleeding edge by years when not decades.
These industries just have to pay enough to convince the ones that can
learn (or that already know) how to work
on their outdated platforms. It has always been like this, nothing new.

If you keep some VCR tapes with your wedding and your 20 years old VCR
breaks down, you're going to have
to pay silly money to get it repaired and, when not possible, even more to
get it rebuilt.
Up to you to decide if you want to pay when the VCR dies or if you want to
pay to move your videos to
something more recent before it dies.

But some seem to be asking everybody to not move to more recent stuff so
that they can still live with their VCR.
I'm not sure I agree on the principle.

Max.

On Wed, 17 Jun 2020 at 15:53, Matthew Woehlke 
wrote:

> On 16/06/2020 18.59, Jonathan Purol wrote:
> >> it's well "known" that you can teach C programmers Java, but you
> >> can't teach Java programmers C
> >
> > How is that well known? What studies can you provide for this?
>
> No studies, but it seems to be a common attitude among most or all
> technical professionals with which I've worked.
>
> That said, yes, there is some exaggeration there. Obviously, some people
> *can* learn "real" programming regardless of what they started out
> doing. The fact is, however, there are plenty more people that *can't*;
> people that can only perform certain tasks with the help of
> technological "crutches". For evidence, look no further than the large
> number of people that struggle with basic arithmetic.
>
> You may be blessed to not have to work with many of these people
> (indeed, they aren't the sort of people that make desirable employees in
> any case). What I was saying was intended to reflect Roland's point,
> which is that there are plenty of people that can muddle through
> "programming" tasks when you give them an "easy" language (e.g. "Qt6"
> QML + javascript) that are in over their heads if you ask them to do
> something in e.g. Qt3 + C++. Yes, there *are* people that can learn, but
> they are less common than the muddlers that can passably do the former
> job and are hopeless when it comes to the latter.
>
> I think the *real* point is that if none of your candidates already know
> "real" programming, it can be difficult to separate the ones with real
> underlying skill from the muddlers.
>
> > Most of my local universities teach Java, do you want to imply those
> > people will never ever be able to learn C?
> All of them? No. *Some* of them? Absolutely.
>
> > People can learn, people can change. All that's required is the
> > incentive to do so, which is probably where you should have put your
> > argument at instead: If Qt migrates away and drops win7 support, you
> > get fewer and fewer people over time that have the incentive to learn
> > the skills required to still develop for older versions.
>
> That was, indeed, part of the point.
>
> However, I also believe that not everyone is capable of every task, no
> matter how incentivized. (Plus, not everyone has the necessary
> determination.)
>
> --
> Matthew
> ___
> 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

2020-06-17 Thread Matthew Woehlke


On 16/06/2020 18.59, Jonathan Purol wrote:

it's well "known" that you can teach C programmers Java, but you
can't teach Java programmers C


How is that well known? What studies can you provide for this?


No studies, but it seems to be a common attitude among most or all 
technical professionals with which I've worked.


That said, yes, there is some exaggeration there. Obviously, some people 
*can* learn "real" programming regardless of what they started out 
doing. The fact is, however, there are plenty more people that *can't*; 
people that can only perform certain tasks with the help of 
technological "crutches". For evidence, look no further than the large 
number of people that struggle with basic arithmetic.


You may be blessed to not have to work with many of these people 
(indeed, they aren't the sort of people that make desirable employees in 
any case). What I was saying was intended to reflect Roland's point, 
which is that there are plenty of people that can muddle through 
"programming" tasks when you give them an "easy" language (e.g. "Qt6" 
QML + javascript) that are in over their heads if you ask them to do 
something in e.g. Qt3 + C++. Yes, there *are* people that can learn, but 
they are less common than the muddlers that can passably do the former 
job and are hopeless when it comes to the latter.


I think the *real* point is that if none of your candidates already know 
"real" programming, it can be difficult to separate the ones with real 
underlying skill from the muddlers.



Most of my local universities teach Java, do you want to imply those
people will never ever be able to learn C?

All of them? No. *Some* of them? Absolutely.


People can learn, people can change. All that's required is the
incentive to do so, which is probably where you should have put your
argument at instead: If Qt migrates away and drops win7 support, you
get fewer and fewer people over time that have the incentive to learn
the skills required to still develop for older versions.


That was, indeed, part of the point.

However, I also believe that not everyone is capable of every task, no 
matter how incentivized. (Plus, not everyone has the necessary 
determination.)


--
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

2020-06-16 Thread Jonathan Purol

Sorry but I must chime in here, since both Roland and Matthew brought
this point up.

> it's well "known" that you can teach C programmers Java, but you can't
teach Java programmers C

How is that well known? What studies can you provide for this?
Currently it just sounds like elitism at its finest to me if I'm honest.
I started with Java, and can now write C pretty well. Most of my local
universities teach Java, do you want to imply those people will never
ever be able to learn C? I have a few friends that started in Java, some
even staying there for years before moving on to C, C++, Rust, Haskell, etc.


> 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.

So.. Every child that ever learnt to ride a bike?
We all have to start somewhere after all, it just takes a little while.

I'm not disagreeing with your point. If you hire someone to do X, you'd
probably not want to hire someone that can do Y, but promises that they
can learn X really fast if you let them.

But the way this was portraied didn't seem quite right to me. People can
learn, people can change. All that's required is the incentive to do so,
which is probably where you should have put your argument at instead:
If Qt migrates away and drops win7 support, you get fewer and fewer
people over time that have the incentive to learn the skills required to
still develop for older versions.

Sincerely,
Jonathan Purol
___
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

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



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

2020-06-15 Thread 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

2020-06-15 Thread 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-ow

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 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

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

2020-06-15 Thread 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


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

2020-06-15 Thread 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



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] [Development] Windows 7 support will be dropped in Qt 6

2020-06-15 Thread 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

2020-06-15 Thread 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] [Development] Windows 7 support will be dropped in Qt 6

2020-06-15 Thread 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

2020-06-15 Thread 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

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

2020-06-14 Thread Roland Hughes



On 6/14/20 5:00 AM, Jonathan Purol wrote:

One possible solution that came to mind is that after the LTS is dropped
for Qt 5.15 it could be opened to the public for contributions with some
elected people as the maintainers, perhaps from larger companies that
are in close contact with the Qt company.
That way there would still be support for Qt 5.15, basically
indefinitely, without every single company needing to invest the same
amount of effort just to have a maintained version of their software
running.
That said, I am unsure if this would be a choice the Qt company would,
and even could make. There might be licensing issues or other things
prohibiting it.
Additionally there could be problems with the direction of the project.
Version 5.15 being controlled by few big players might lead to some very
off-scope specific features being implemented which could cause hassles
for less influential groups of people.


Your suggested compromise has already happened.

Qt was forked some time back as CopperSpice. https://www.copperspice.com/

It has diverged quite a bit since then. I'm only just starting to play 
with it as their licensing is "much goodlier."


Requires a C++17 compiler. Got rid of MOC. They don't physically state 
it, but the documentation has no mention of QML or JavaScript and 
dropping both of those would be a very good thing.


Supported platforms appears to go all the way back to Vista for Windows.

https://www.copperspice.com/docs/cs_overview/supported-platforms.html

I don't see Centos 5 on here which was mentioned in this thread, but 
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.


After I get done tweaking the Diamond editor to support themes and EDT 
keypad mode I want to try the Migration information out and port my 
XpnsQt project to XpnsCS.


https://github.com/copperspice/diamond

https://www.copperspice.com/docs/cs_overview/migration.html

https://sourceforge.net/projects/xpnsqt/

I wouldn't go so far as to say I expect the learning curve to be quick, 
especially since I'm helping with the farming now. It shouldn't be like 
starting over with a new library though. Just a lot of the really bad 
parts of Qt were removed and some new features added. There is a series 
on my geek blog for those interested.


https://www.logikalsolutions.com/wordpress/uncategorized/copperspice-and-diamond/

There can't be compromise Jonathan. It's a binary situation.

You either fully support Windows 7 for the embedded/industrial crowd 
that will be using it for at least another decade, or you don't and they 
stop paying, contributing, hiring, etc. when it comes to Qt.


Or you don't fully support it. Only half-ass it, kind of like happened 
with C++11 being supported as "the minimum" then when some fool (me) 
tried to compile using that standard on three different major Ubuntu 
releases he found that it didn't work and hadn't worked for quite some 
time. People using things that only existed in later standards version 
and they were just being checked in after code review because nobody 
ever built using C++11.


If one tries to "compromise" Windows 7 will end up going the exact same 
way in under six months and like far too many bugs that don't have to do 
with new and sexy, the bug will be allowed to rot in the backlog.


No development library can be all things to all people. Qt has been 
trying to do that. This is where it failed. It can either target "the 
cool kids toys" meaning they will have to do massive redevelopment every 
two years and bugs won't get fix -- OR -- they support "real industry" 
where products have lifespans of many decades requiring some support 
staff for their entire life which means if you have a reasonably priced 
support contract, you get many decades of revenue provided you actually 
do support and focus on the bug backlog.


(It's about time for "that guy again" to pop up. The one paying for a 
support contract who has critical bugs that have been in the backlog for 
years.)


I haven't physically spoken with anyone at CopperSpice, only done my own 
extremely limited research (and that blog post series will show just how 
limited) but the thing that intrigued me most of all was their 
"Subscription" pricing.


https://www.copperspice.com/subscriptions.html

For me personally, the bronze level of $100/month per seat is too much. 
For me as a contractor working on a medical device for someone, 
$100/month is more than reasonable. Some of my clients will probably 
bump to the Silver subscription of $350/month. I don't walk in the 
circles that would pay the $800/month 20 seat minimum subscription for a 
year, let alone years.


We always see "Just use 5.15." What I and others have been trying to 
convey here is that statement and many like it are made by people who 
don't understand real business. Real business isn't Apple.


I lived through this with the transition from Qt3 to Qt4

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

2020-06-14 Thread Thiago Macieira

On Saturday, 13 June 2020 00:20:46 PDT Konrad Rosenbaum wrote:
> (**)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.

The big difference here is that those are self-support systems. I do know of 
one big company that is running 2.6.32 on their Internet-connected servers. 
But they themselves are managing that kernel and applying security fixes as 
necessary. I don't have direct evidence of the userspace state, but I suspect 
it's the same: the software is constantly getting updated with fixes developed 
in-house or backported by their team, just not with features.

I suppose a company with enough money and enough of an installed base of 
Windows could get the same from Microsoft. That contract must be in the seven-
digit USD count.

-- 
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

2020-06-13 Thread Jonathan Purol

I am not nearly as invested with big business as the rest of the people
here and lack the experience most of you have.
However what currently seems to be happening is a back and forth of
"We need to progress, because technical debt and X"
"Yes but big companies can't progress because Y"
This has been repeating for the last few threads without seeming to go
anywhere. Don't get me wrong, I found it fascinating to read through but
I don't think it furthers the discussion at the moment. It would
surprise me greatly if Qt wasn't aware that some of their largest
clients are intrinsically depending on Windows 7.

So to get my naïve and inexperienced opinion in here:
Instead of continuing on the aforementioned cycle, why don't we see if
there could be some alternative route. Some sort of compromise.
It seems that neither continuing support for win7, nor dropping it is
satisfactory for any side.
To go by what Roland Hughes said, companies of that scale often want to
keep software for up to 30 years which would mean carrying win7 around
for up to 2039+, which is another 19 (!) years of maintenance. And at
some point this decision probably has to be made. As Oliver Wolff said:
> [...] dropping support for an OS is never ideal [...]

One possible solution that came to mind is that after the LTS is dropped
for Qt 5.15 it could be opened to the public for contributions with some
elected people as the maintainers, perhaps from larger companies that
are in close contact with the Qt company.
That way there would still be support for Qt 5.15, basically
indefinitely, without every single company needing to invest the same
amount of effort just to have a maintained version of their software
running.
That said, I am unsure if this would be a choice the Qt company would,
and even could make. There might be licensing issues or other things
prohibiting it.
Additionally there could be problems with the direction of the project.
Version 5.15 being controlled by few big players might lead to some very
off-scope specific features being implemented which could cause hassles
for less influential groups of people.

Sincerely,
Jonathan Purol
___
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



On 6/13/20 5:00 AM, Konrad Rosenbaum wrote:

Here is a challenge for you Thiago: on Monday contact the manufacturing
side of your company and ask them for a clean room tour in one of
Intel's many fabs - once there take a very close look at the control
screens of the machines in there, note the systems they are running.


Unless something changed dramatically in the past few years, you will 
find much of the process controlled by a DEC Alpha machine running 
OpenVMS. Story going around the industry, and I don't know if it is 
true, is that even Intel didn't upgrade to Itanium. When I wrote this book


https://www.theminimumyouneedtoknow.com/app_book.html

many copies were sold to people at Intel because an OS nobody in here 
cares about running on a chip that hasn't been made in roughly a decade 
or more is what controls the quality and production of all the chips 
Intel makes that Qt developers actually care about.


Now, if the real goal is to "only support the cool kids and their 
phones," that's fine. Man up and say that. Say it early so those paying 
for support and possibly paying royalties can stop paying those things 
and begin their transition to a different tool set. QML developers will 
just be screwed, but C++/Widget users can see if CopperSpice supports 
their platform


https://www.theminimumyouneedtoknow.com/app_book.html

and attempt a transition to it. Someone put a lot of effort into putting 
together this list of other options.


https://philippegroarke.com/posts/2018/c++_ui_solutions/

They did leave Zinc off it. I can understand though. The screenshots 
posted at the OpenZinc page have a very 1990s look to them.


http://openzinc.com/Screenshots.html


--
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



On 6/13/20 5:00 AM, Filip Piechocki wrote:

Hi,
for me not updating a system, software etc for many years is just equal to
building a technical debt. Any serious company should be aware that this
will finally kick them in their butt, should have measure the potential
cost and decide where is the point where they should switch. If a company
decides to not care about this then someone else will decide for them for
example by dropping support for their OS/hardware/whatever.
Backwards compatibility is nice but the world (especially IT world) is
moving forward and lagging behind is a potential risk and cost.


Honestly, I can see how one would think that; but the truth is it almost 
never does.


I worked on the trading floor system for the Chicago Stock Exchange 
multiple times. This "temporary" system started out on PDP 11 hardware 
running either RSTS or RSX OS (I forget which, could have even been 
RT-11). That was the 1970s. In the 1980s it moved to VAX hardware and 
OpenVMS quite easily actually because the BASIC compiler strove to be 
backward compatible. In the 1990s it moved to the Alpha. When the 
Itanium processor came out it moved to that. Do you know when they 
finally retired this "temporary" system? When they got rid of the 
trading floor just a few years ago.


With a proper business model, technical debt never has to be paid.

That FDA regulated company in California running a 1970s era PDP will 
run it until the business becomes unprofitable (or not profitable 
enough) then they will shut the line down. If there ever comes a time 
when they can no longer scrounge up parts or physically cannot find 
_anyone_ willing to train on how to run the thing, then and only then, 
they will set up a new line with current tech in some other location, 
usually off-shore. They probably already have such a line. This one will 
simply be scrapped once it can no longer function.


This is the reality of industry.

You can always find someone willing to be trained for the proper amount 
of money and that proper amount of money is always less than starting 
over. You only "upgrade" when you physically can't make it work anymore 
or a federal regulation forces you.



--
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



On 6/13/20 5:00 AM, Konrad Rosenbaum wrote:

(*)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.


When I bought a Toyota Camry hybrid several years ago the brand new 
Toyota dealership was still running DOS to process vehicle sale and all 
work-orders. The rep didn't know what it was written in, but having used 
DataBoss during the DOS days I will say the screen and UI interaction 
looked _exactly_ like a DataBoss application.


https://www.drdobbs.com/code-generators/184415560


--
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