[Development] Windows 7 support will be dropped in Qt 6
kevin.kofler at chello.at
Tue Jun 16 12:08:32 CEST 2020
Edward Welbourne wrote:
> So my bad, I said our product would only work on an ancient O/S or two,
> when it could indeed to made to work on a whole bunch of more modern
> systems *on which it would be irrelevant* - and thus not worth the
> significant effort of porting to, because anyone developing apps for
> those newer systems would look at our feature set and decide to use
> something that actually makes good use of the shiny new features of the
> O/S they're targeting.
What "shiny new features"? All that a real-world application such as KWrite
really needs from the operating system has been there at least since the
1990s, possibly since the 1970s.
> In particular, where an old O/S doesn't support some feature present in
> a newer O/S, a cross-platform toolkit that tries to provide the same
> features everywhere is left with an uncomfortable choice between
> kludging together for the old system some kind of emulation of what the
> new provides, or having a limited feature-set on the old system. At
> some point - instead of claiming to be cross-platform but failing to
> have the full feature-set on a nominally supported platform, while also
> supporting a mess of kludges to implement, for that platform, features
> every newer the O/S provides for us - it becomes more sensible (and more
> honest) to own up to not really supporting that platform any more.
Often, you will find that modern versions of GNU/Linux distributions
actually implement the desired feature using a cross-platform Free Software
library that you can just use to provide the feature on older operating
systems including proprietary ones (such as Windows 7). At least as long as
the application developer is not allergic to the LGPL for some reason.
Of course, it depends on the individual feature, but I would need to know
what features you are talking about to go into technical details.
> While evaluation of the pros and cons does involve garnering information
> about how users shall be affected, the means of doing that is not - nor
> should it be - having the highly self-selecting group of folk who notice
> the evaluation task "vote" on whether it's worth it or not. A broader
> overview of users is required, without the *huge* bias against change
> that this would entail.
You are making an implied assumption there that the people opposed to
breaking changes would be just a vocal minority. There is no evidence to
support that claim.
> Better for those working on the issue to consult sales and product
> managers, who routinely talk to a somewhat broad cross-section of users.
> Not a perfect sample, but statistically less biased than those watching
> Jira closely enough to notice this task.
That sample, on the other hand, is inherently and obviously biased against
the community using the LGPL version of Qt, because that community will
obviously never talk to your sales and product managers. But I get more and
more the impression that getting rid of that community is actually in the Qt
More information about the Development