[PD-dev] performance of different Wish versions

Sun Jul 16 11:11:24 CEST 2023

Maybe I do agree with you, actually. I just naturally try to push back on the "macOS is always changes and sucks" statements that come now and then from people who don't even use the platform. You original state was not one of these and I share the frustration (especially after the key handing patch pain).

I think the point is more that, in our case, we are a bit unlucky in that this platform simply doesn't get the attention as much as other platforms for Tk. I certainly don't want to do Tk dev work unless I have to and, if it is as a point to where nobody is even trying to fix it any more, well,  we should accelerate the generalized GUI comm interfaces in the core. ;) I just don't want to be quick to "jump ship" when 1. you, I, and IOhannes are likely the *only* ones to have any interest in doing the work for this while 2. there are *lots* of people using macOS and Pd. None of us need a large development responsibility when, I at least, am not paid to work on Pd in general.

As someone who has developed native macOS and iOS apps, the APIs are pretty stable via Obj-C/ Swift and the version handling at runtime is relatively good. OTOH that's probably a different story with C though, considering it doesn't have the same kind of runtime flexibility. My point here is that it's not as bad as it is often portrayed *if* you do it the "Apple way" otherwise you are on your own. ;P

One option would be to back port the important differences we need in Pd to 8.6.11 and release Pd with this Wish version for now, although that might be tricky as newer macOS versions come out.

> On Jul 16, 2023, at 10:07 AM, Sebastian Shader <sebfumaster at aol.com> wrote:
> 
> 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) <https://core.tcl-lang.org/tk/tktview/f642d7c0f4> 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 at 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 at lists.iem.at <mailto:pd-dev-request at lists.iem.at> wrote:
> > 
> > From: Sebastian Shader <sebfumaster at aol.com <mailto:sebfumaster at aol.com>>
> > To: "pd-dev at lists.iem.at" <pd-dev at lists.iem.at <mailto:pd-dev at lists.iem.at>>
> > Subject: [PD-dev] performance of different Wish versions
> > Message-ID: <22683916.267738.1689344746296 at mail.yahoo.com <mailto:22683916.267738.1689344746296 at 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.

--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230716/c2b845ee/attachment-0001.htm>