Part of the issue with wx is that we are using a legacy version of
wxpython.  I know there has been some motion towards getting the new
version of wxpython working with KiCad, but it does not seem like it
will be super easy.  There is no real guarantee that the next version
of wx will work with the legacy/non-maintained version of wxpython
we're using.

I consider getting away from this legacy version of wxpython
relatively critical so we don't get in trouble--for instance, if some
new OS release doesn't work with the legacy wxpython.

Adam Wolf

On Fri, Feb 9, 2018 at 8:27 AM, Wayne Stambaugh <> wrote:
> On 2/9/2018 1:41 AM, Carsten Schoenert wrote:
>> Am 09.02.2018 um 01:35 schrieb Jeff Young:
>>> Ping.
>>> Any thoughts on patching wxWidgets for other platforms?
>> If you are talking about other Linux platforms then please do this in a
>> way the user hasn't to deal with changes to system folders, this isn't
>> really possible nor usable on systems which using package managers for
>> dealing with installed software. And I know only LFS (Linux from
>> Scratch) which hasn't a package manager.
>> And, please upstream any changes, if upstream don't want to accept your
>> changes they probably have strong and good reasons to not apply your
>> changes (at least for this specific released version).
> I second this motion.  We really shouldn't be in the business of
> maintaining our own custom version of wxWidgets.  I relaize macos is a
> problem child for wx but we should be helping ourselves by getting wx to
> accept and maintain any issues that have not already been fixed
> upstream.  Hopefully the next release of wx will be a bit more usable on
> macos than the 3.0 branch and that the current situation of maintaining
> our own wx branch for macos is temporary.
> _______________________________________________
> Mailing list:
> Post to     :
> Unsubscribe :
> More help   :

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to