Minimum Supported Versions

[Ian McInerney]

I was wondering, what are the minimum supported versions for the various platforms/libraries required for wxWidgets?

Specifically, is there a minimum supported OSX version and GTK 2 version (e.g. a version below which we don't have to conditionally check for when writing code using functions introduced later).

[Catalin]

On Friday, 24 April 2020, 21:38:57 EEST, Ian McInerney wrote:

> Specifically, is there a minimum supported OSX version and GTK 2 version

It depends on the wxW that you're going to work with, but for the latest code it should be here: https://docs.wxwidgets.org/trunk/page_introduction.html#page_introduction_requirements

Regards,
C

[Vadim Zeitlin]

On Fri, 24 Apr 2020 11:38:51 -0700 (PDT) Ian McInerney wrote:

IM> I was wondering, what are the minimum supported versions for the various
IM> platforms/libraries required for wxWidgets?
IM>
IM> Specifically, is there a minimum supported OSX version and GTK 2 version

There are, but you're not going to like how old/low they are... For macOS,
we're definitely going to increment it sooner or later and if there is a
good reason to require something newer than the still supported (more or
less, see https://github.com/wxWidgets/wxWidgets/pull/1793) 10.7, let's do
it.

For GTK 2 I'm conflicted: on one hand, 2.6 is very, very old. OTOH we
stayed on it for so many years that it's almost a pity to increase the
requirements now instead of just waiting until we stop supporting GTK 2
entirely.

Regards,
VZ

[Ian McInerney]

Luckily the functions I am using are OSX 10.6+ and GTK 2.6+.

The OSX 10.6+ allows me to rewrite the wxDirDialog using the newer interface and add the hidden/multiple selection options I have been working on. Same thing for GTK (2.6+ is needed for the hidden option).

-Ian

[Catalin]

On Friday, 24 April 2020, 22:15:37 EEST, Vadim Zeitlin wrote:

> For GTK 2 I'm conflicted: on one hand, 2.6

BTW, there are places where version is slightly confusing:
"2.0" :
    https://docs.wxwidgets.org/trunk/plat_gtk_install.html#gtk_errors_simple
    https://docs.wxwidgets.org/trunk/plat_gtk_install.html#gtk_options
    https://docs.wxwidgets.org/trunk/page_port.html#page_port_wxgtk
"GTK+ 2.x.y, where x is an even number":
    https://docs.wxwidgets.org/trunk/plat_gtk_install.html#gtk_libs_gui

Regards,
C

[Vadim Zeitlin]

On Fri, 24 Apr 2020 19:42:20 +0000 (UTC) 'Catalin' via wx-dev wrote:

C> On Friday, 24 April 2020, 22:15:37 EEST, Vadim Zeitlin wrote:
C>
C> > For GTK 2 I'm conflicted: on one hand, 2.6
C>
C> BTW, there are places where version is slightly confusing:
C> "2.0" :
C>     https://docs.wxwidgets.org/trunk/plat_gtk_install.html#gtk_errors_simple
C>     https://docs.wxwidgets.org/trunk/plat_gtk_install.html#gtk_options

This document is embarrassingly out of date (I wonder who even knows about
egcs nowadays), it practically needs to be rewritten from scratch.

C>     https://docs.wxwidgets.org/trunk/page_port.html#page_port_wxgtk

This needed to be updated even before the changes of

https://github.com/wxWidgets/wxWidgets/commit/44ba9d1d071d4beb555f0e621ea54416935d2b0b

but now needs it even more so... I'll try to do it if Paul doesn't beat me
to it in the near future.

C> "GTK+ 2.x.y, where x is an even number":
C>     https://docs.wxwidgets.org/trunk/plat_gtk_install.html#gtk_libs_gui

This actually seems correct, even if relatively useless. But just about
everything here needs to be rewritten anyhow, as mentioned above.

Regards,
VZ

[Stefan Csomor]

Hi

Am 24.04.20, 21:15 schrieb "Vadim Zeitlin" <wx-...@googlegroups.com im Auftrag von va...@wxwidgets.org>

For macOS, we're definitely going to increment it sooner or later and if there is a
good reason to require something newer than the still supported (more or
less, see https://github.com/wxWidgets/wxWidgets/pull/1793) 10.7, let's do
it.

I'd like to raise this issue again, and suggest we raise it to 10.9 Mavericks (Xcode 6.2) at least, sooner or later I'd like to raise it to 10.11. That way we can reduce the complexity and systems supported quite a bit, apart from the obvious reduction of fallbacks in our usage of 'new API'. The different aspects

- with 10.9 and Xcode 6 we have clang 3.5, which means we have sufficient c++11 and c++14 support, we don't have to support the old GCC/libstdc++

- When building for 10.15 Catalina and having to notarize apps we need to build with the hardened runtime, this also means a minimal deployment version of 10.9 or greater.

- We don't need 32 bit builds anymore.

- for all macOS Systems between 10.8 and 10.11 the hardware requirements are the same, this means any system running 10.8 can be updated at least to 10.11 as well, so we don't loose hardware even if we go to a newer macOS version than 10.9

- 10.10 has the cleaner flat GUI, no skeomorphism anymore, so in the places where we are drawing ourselves, we look more 'native' than in the more complex 10.9. also eg 10.10 has a proper AVPlayerView, so our media control is native

- 10.11 does not have the focus on new features but rather on improvements and refinements, also in the different APIs, from animations to full screen

Thanks for your feedback,

Stefan

[Vadim Zeitlin]

On Wed, 6 May 2020 21:29:39 +0000 Stefan Csomor wrote:

SC> I'd like to raise this issue again, and suggest we raise it to 10.9
SC> Mavericks (Xcode 6.2) at least, sooner or later I'd like to raise it to
SC> 10.11.

Personally I don't mind, i.e. I don't have any projects still targeting
anything older than 10.10, and there is no real problem with changing the
minimal requirement to 10.11 for this one neither.

SC> That way we can reduce the complexity and systems supported quite a
SC> bit, apart from the obvious reduction of fallbacks in our usage of 'new
SC> API'. The different aspects
SC>
SC> - with 10.9 and Xcode 6 we have clang 3.5, which means we have
SC> sufficient c++11 and c++14 support, we don't have to support the old
SC> GCC/libstdc++
SC>
SC> - When building for 10.15 Catalina and having to notarize apps we need
SC> to build with the hardened runtime, this also means a minimal
SC> deployment version of 10.9 or greater.

This seems a pretty convincing argument.

SC> - We don't need 32 bit builds anymore.
SC>
SC> - for all macOS Systems between 10.8 and 10.11 the hardware
SC> requirements are the same, this means any system running 10.8 can be
SC> updated at least to 10.11 as well, so we don't loose hardware even if
SC> we go to a newer macOS version than 10.9
SC>
SC> - 10.10 has the cleaner flat GUI, no skeomorphism anymore, so in the
SC> places where we are drawing ourselves, we look more 'native' than in
SC> the more complex 10.9. also eg 10.10 has a proper AVPlayerView, so our
SC> media control is native
SC>
SC> - 10.11 does not have the focus on new features but rather on
SC> improvements and refinements, also in the different APIs, from
SC> animations to full screen

As I said, I don't have any real problems with requiring 10.11, but the
arguments for it, especially over 10.10, seem to be somewhat less
convincing. FWIW I count 4 WX_IS_MACOS_AVAILABLE(10,9) checks, 12 checks for
10.10 and only 4 checks for 10.11 (and, just for comparison, also 10 checks
for 10.14). So maybe we should compromise on 10.10 for now?

According to

https://gs.statcounter.com/os-version-market-share/macos/desktop/worldwide

there are ~3% of users on 10.10 (and 2% for all the previous versions
combined).

Anyhow, again, if you think going directly to 10.11 is worth it, let's do
it. To me it looks like we could settle at 10.10 without losing too much
for now, but the decision is yours.

Thanks,
VZ

[Stefan Csomor]

Hi Vadim

Thanks, for your feedback.

As I said, I don't have any real problems with requiring 10.11, but the
arguments for it, especially over 10.10, seem to be somewhat less
convincing. FWIW I count 4 WX_IS_MACOS_AVAILABLE(10,9) checks, 12 checks for
10.10 and only 4 checks for 10.11 (and, just for comparison, also 10 checks
for 10.14). So maybe we should compromise on 10.10 for now?

According to

https://gs.statcounter.com/os-version-market-share/macos/desktop/worldwide

there are ~3% of users on 10.10 (and 2% for all the previous versions
combined).

Anyhow, again, if you think going directly to 10.11 is worth it, let's do
it. To me it looks like we could settle at 10.10 without losing too much
for now, but the decision is yours.

Perfect, thanks.

Ok, let's aim to put this at 10.10 for now, I'm fine with that.

As for 10.11: Improvements in Testing (Xcode 7 brings UITesting) and API refinements might help us, but I can add this conditionally first. So we can see what the implications might be.

Also I'd like to look into cross-debugging from xcode 7 (10.11) an application running under 10.10, to find out whether we can increase Xcode requirements independently from SDK deployment choices (the last time I did this was in 1995 for "Copland" :-)

Best,

Stefan

[Vadim Zeitlin]

On Thu, 7 May 2020 07:09:01 +0000 Stefan Csomor wrote:

SC> Ok, let's aim to put this at 10.10 for now, I'm fine with that.

Will you do the necessary changes or should I make them?

SC> As for 10.11: Improvements in Testing (Xcode 7 brings UITesting)

I never understood the deal with UI testing (nor also the changes of
https://github.com/wxWidgets/wxWidgets/pull/1456 and how do they help us
and what should be done with this PR), but if it can allow us to run the
(existing) UI tests under Mac, it would certainly be extremely useful and
more than justify requiring 10.11.

Regards,
VZ