[Torsten Berg <reincke@ma...>]

Hi,

I do have some projects that are still using Carbon, mainly because of the issues with the event loop in Tk-Cocoa. They use the most recent version of Tk 8.5. For these projects it is important to also have TclOO, zlib and png support which is guaranteed via packages for Tk 8.5. From that perspective, I do not expect any new significant feature that will be thrown into Tk 8.5 and which I will need in those projects forcing me to update to an even newer Tk 8.5.x version but still requiring Carbon. So it will be OK for me to just stop Carbon's lifetime with Tk 8.5.12. Much more important is to get Tcl 8.6 out of the beta stadium and published.

All my new projects try to use Tk 8.6 anyways and then need to cope with the event loop problems in Tk-Cocoa.

I am not really sure about some possible packages for Mac relying on Carbon. Fortunately, tktreectrl (which I am currently testing and trying to use as a replacement for tablelist in situations where the event loop thing is too annoying) is already for both Carbon and Cocoa but there might be others around. These could be the most problematic as they would not allow developers to switch to Tk 8.6 at all. But this is, in a way, independent of dropping Carbon in Tk 8.5.

I am, however, a bit uneasy about the current development of Tk-Cocoa since there is no-one around to help us getting further. How many years could it take before the event loop is fixed? I see some 4-5 other bugs listed in the SF tracker that are open for years now and with no fix in sight and I see a few other issues regularly when writing Tk code using Tk-Cocoa (yes, I should really try and make them reproducible and report them). Unfortunately, my Objective C and Cocoa knowledge is far too limited to be of any help here and it is difficult for me to ask the community to develop Tk-Cocoa further without really being able to help personally.

Having said that, I can only support dropping Carbon now, so we can get on with making Tcl and Tk on the Mac a vivid language with a modern look and feel.

Thanks for all your effort to make that happen,

Torsten




Am 26.09.2012 um 00:12 schrieb Kevin Walzer <kw@...>:

> Hi all,
> 
> After extensive discussion on the Tcl-Core mailing list, we've done a 
> full merge of the Tk-Cocoa backport into the main branch of Tk 8.5, so 
> that it will more closely track development in 8.6 and not require the 
> complexity of maintaining a separate branch. Going forward, Tk 8.5 as 
> well as Tk 8.6 will be based on Cocoa.
> 
> As a result of this, the question of what to do with the older Carbon 
> version of Tk--in both 8.5 and 8.6--has arisen.
> 
> When Tk-Cocoa was first merged into Tk 8.6/trunk a few years ago, it was 
> decided to set up a separate "Carbon" subdirectory in the Tk source 
> tree, which someone could build using an "--enable-carbon" switch during 
> the configure phase. It probably would not be too hard to set up 
> something similar for 8.5.
> 
> However, I'm not aware of any Tk 8.6-based projects that make a point of 
> using Carbon, nor am I aware of any in 8.5; ActiveState switched 
> ActiveTcl to the Cocoa-based version a couple of years ago, and the 
> version of Tk that Apple ships with OS X has been Cocoa-based since 
> 10.6. Most projects simply go with Cocoa because that is now the most 
> widely-supported version; if a project is using Carbon, it is likely by 
> happenstance (an older build of Tk, for instance).
> 
> Adding to these observations is the fact that that the Carbon version is 
> increasingly hard to build on recent versions of OS X, especially in a 
> 64-bit environment.  I've heard reports that it won't build at all on 
> 10.8 (can't confirm that myself as I'm still on Lion); Apple has moved 
> from deprecating to actively removing some part of the Carbon framework 
> from OS X. No significant work has been done on the Carbon version of Tk 
> for about five years, since Daniel Steffen began working on the Cocoa port.
> 
> Based on all this, from my perspective it makes little sense to continue 
> supporting the Carbon version of Tk. It seems at this point just to take 
> up space in the Tk source tree, but is not used anywhere that I can see. 
> My vote would be to remove it from both 8.5 and 8.6, set the line of 
> demarcation on Carbon at Tk 8.5.12, and move forward.
> 
> However, I think it make sense to discuss this issue more before 
> proceeding with such a change. In the Tcl chatroom I volunteered today 
> to start a conversation on this issue on the Tcl-Mac list, and based on 
> the feedback here, will also discuss the issue on Tcl-Core.
> 
> I will also fully acknowledge that the Cocoa port is not perfect, 
> specifically with regard to performance and integration between the Tk 
> and Cocoa event loops; the Carbon version is superior in this respect, 
> and a few years ago a couple of people mentioned on this list that they 
> prefer the Carbon version for that reason. Until Daniel Steffen or 
> someone else with more expertise than me has time to dive into the 
> event-loop integration questions,  the Cocoa port will continue to have 
> this issue. Nonetheless, these factors in my view do not outweigh the 
> facts that the Carbon port is now obsolete, cannot build in a 64-bit 
> environment, and is unsupported in every major binary distribution of Tk 
> on the Mac. I believe that Tk would not suffer by removing that code 
> from the source tree in both 8.5 and 8.6.
> 
> Comments are not only welcome but invited. If there is a clear 
> constituency for keeping the Carbon port around, we need to be aware of 
> that.
> 
> Thanks,
> Kevin
> 
> 
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Tcl-mac mailing list
> tcl-mac@...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac