Re: [MACTCL] How to move forward with Tk-Cocoa event loop issues

[Kevin W. <kw...@co...>]

Hi Adrian,

> I really appreciate the work you are doing, and I understand wanting to clean up, cut losses, and move on, but I don't think it's good to sweep such bug reports under the rug.

Fair enough. I've re-opened the bug in question so that it will reappear 
in searches and for comments, but I've left its status as "won't fix" 
because I'm not persuaded that it is, in fact, fixable.

> We might not have the combination of time and expertise right now to fix these problems, but hopefully sooner or later we will.  At that time we'll want as clear descriptions of the issues as possible, and the simplest code available for reproducing them.  Closing bugs only makes them less visible and less likely to be found.  Duplicates will probably submitted, scattering useful information.  Or worse, the "it's as good as it's going to get, we're not going to fix it" message will discourage people from submitting bugs, trying to fix them, or, ultimately, from using Tk at all as a cross-platform solution.

It is indeed unfortunate that there are only a handful of folks with the 
combination of time, interest, and expertise to actively work on Tk at a 
low level. It's understandable, though, because the barrier to entry in 
terms of expertise is very high: it took me four or five years to 
develop any competence at all with Tk and Cocoa at the C level. And on 
the other side, there are other folks in this community with more 
expertise than me, but with less time and/or interest: they just want Tk 
to work but don't want to have to dig deeply into its internals. In this 
regard I am especially grateful to you for the patches you've recently 
submitted.

As far as choosing another cross-platform framework instead of Tk, I 
also understand this argument, but I choose Tk anyway because it's 
easier to extend than any other cross-platform framework. Adding 
Services support, AppleScript support, etc. is comparatively easy in Tk: 
imagine trying to do something similar with PyQt or wxPython. First 
you'd have to dig deeply into the C++ library, then you'd have to figure 
out how to wrap that functionality in the higher-level framework. 
Doable, but very, very hard, I imagine. It's why I've stayed with Tk 
despite its problems.

It would certainly be wonderful if we got some new blood in the 
community to work on Tk. One reason I am pessimistic about this is, 
apart from Tk lacking the "cool factor" and the Mac-specific bugs being 
a turnoff, Tk's C API is increasingly becoming an undocumented "black 
art." The best extant resource on Tk's C API that I've seen is Brent 
Welch's book, which I learned a lot from, but which only goes through Tk 
8.4 and is going on ten years old. The recent new edition of Osterhout's 
book skips over Tk's C API with the assertion that "since so few people 
work on it, it's not of interest here." Ridiculous.

> I don't object to systematically documenting the best ways for working around Tk-Cocoa's problems, but let's leave open bugs open and put efforts into creating minimal reproduction scripts if nothing else.  (Side note, I tried on and off for more than a year to "work around" Tk-Cocoa's bugs, before going the route of altering my application's functionality on the Mac platform to get it out the door.)
>
I'm sorry for the trouble you had with your own app. And yes, I'll leave 
the bug open.

Thanks for the feedback,
Kevin


-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com