yes, they've accepted our prs. But I'm not sure 'we' are up to keeping an entire gui toolkit up-to-date with API changes, in addition to pd itself. There's a reason that a gui toolkit is used, rather than building one from scratch. Sure, I can open issues to fix alpha channels for checkbuttons or help menu ordering issues (the latter of which I've helped fix on their end) but when it comes to event handling that scope becomes quite a bit larger.
And if we are up to doing dev work on tcl/tk and accepting that responsibility, then we should open some prs to make recent tcl/tk reasonably performant on macos. But that hasn't happened. It's great if someone could take on that job but as relatively small open source projects idk if anyone will.
The fact is that seemingly, newer versions of tcl/tk have pretty bad performance on macos. But the tcl/tk team doesn't even seem to be sure why the performance is bad.

Maybe we're calling 'update' inappropriately or something, but other than that it is tk's responsibility and they haven't solved the issue. (and imo the frequency of calling 'update' shouldn't be platform-dependent.. though that might be unavoidable..).
In addition, tk's own devs seem to reference an 'api churn' by macos: Tk Source Code: View Ticket (tcl-lang.org) so at least THEY agree that MacOS deprecates APIs more frequently than on the other main platforms.

I don't even mind MacOS deprecating things frequently, I just think a gui toolkit as old and small as tcl/tk is ill-equipped to adapt to it. Maybe their architecture just can't deal with it well either, and/or there is some kind of 'tech debt' in that regard? idk
Also personally I like tcl/tk, I just think MacOs isn't as well supported as it could be, and the MacOs devs often seem eager to take an 'it's not an issue' attitude even when whatever it is certainly is an issue. (but again, it's an open source project that may be too small to get enough support for these changes)

-seb

On Saturday, July 15, 2023 at 02:05:57 AM PDT, Dan Wilcox <danomatika@gmail.com> wrote:


I disagree with this assessment.

In recent years the macOS maintenance of Tk picked up quite a bit and it is *much better* than before. It was always reacting as opposed to staying on top of platform changes but they at least have integrated changes from our end for sticky things like the key handling issues.

I also disagree that macOS has “constantly changing” APIs and associated FUD. Most changes are well documented in advanced and major changes often leave deprecation mechanism in places for many years after (ie. Carbon). That these updates come as a surprise to open source developers who don’t keep up with all the minutia (myself much included) is not always Apples fault.

Should we stick with Tk forever? Possibly not, but I don’t see issues like this as always the next reason to drop it ASAP consider how difficult cross-platform development is due to platform differences. It’s disappointing but kinda “par for the course.”

enohp ym morf tnes
-----------
Dan Wilcox
danomatika.com
robotcowboy.com


> On Jul 15, 2023, at 9:18 AM, pd-dev-request@lists.iem.at wrote:
>
> From: Sebastian Shader <sebfumaster@aol.com>
> To: "pd-dev@lists.iem.at" <pd-dev@lists.iem.at>
> Subject: [PD-dev] performance of different Wish versions
> Message-ID: <22683916.267738.1689344746296@mail.yahoo.com>
> Content-Type: text/plain; charset="utf-8"
>
> From my brief interactions with making prs for tk, my impression was that Wish development on macos isn't very healthy.Probably partly due to MacOS changing APIs all the time and leaving developers to figure out how to migrate in the best way.
> There are a few different threads regarding performance issues with recent wish and MacOS, but unless someone investigates it and opens up a ticket with Tk to fix it it probably won't get fixed.
> Tcl/tk that isn't recent has some little things that don't really work on macos, so there's really nothing to be done on the pd side aside from switching to another gui toolkit entirely.