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

Roland Hughes roland at logikalsolutions.com
Thu Jun 18 19:27:25 CEST 2020

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 

> 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


More information about the Interest mailing list