From: Kevin W. <kw...@co...> - 2012-09-25 22:12:23
|
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 |
From: Jeff H. <je...@ac...> - 2012-09-25 23:04:56
|
Hi Kevin, First off, thanks for the effort on this. My short $.02 is an ambivalent -1 on keeping any carbon-based support going forward. People can refer to 8.5.11 and preceding versions if they want to try and make it work. Jeff On 25/09/2012 3:12 PM, Kevin Walzer wrote: > 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 > > |
From: Adrian R. <adr...@gm...> - 2012-09-26 01:24:55
|
I can't say I am remotely happy with the continued inferiority of the Cocoa version in important respects to the Carbon version. But that said I don't think keeping the Carbon code around serves much purpose, let alone makes it likely for this situation to improve. Folks needing the Carbon port can continue to use tag checkouts of whatever version of 8.6 or 8.5 that last had the code (sounds like 8.5.11 and 8.6b3). -Adrian On 2012/09/25, at 19:03, Jeff Hobbs <je...@ac...> wrote: > Hi Kevin, > > First off, thanks for the effort on this. > > My short $.02 is an ambivalent -1 on keeping any carbon-based support > going forward. People can refer to 8.5.11 and preceding versions if > they want to try and make it work. > > Jeff > > On 25/09/2012 3:12 PM, Kevin Walzer wrote: >> 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 >> >> > > ------------------------------------------------------------------------------ > 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 > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac |
From: Gerald W. L. <ger...@gm...> - 2012-09-26 01:53:28
|
I'll throw my vote in with Jeff -- 8.5.11+ == Cocoa, 8.5.11 == Carbon. Of course it would be great if we could just push 8.6 out. On 9/25/12 6:03 PM, Jeff Hobbs wrote: > Hi Kevin, > > First off, thanks for the effort on this. > > My short $.02 is an ambivalent -1 on keeping any carbon-based support > going forward. People can refer to 8.5.11 and preceding versions if > they want to try and make it work. > > Jeff > > On 25/09/2012 3:12 PM, Kevin Walzer wrote: >> 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 >> >> > ------------------------------------------------------------------------------ > 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 > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac -- +------------------------------------------------------------------------+ | Gerald W. Lester | |"The man who fights for his ideals is the man who is alive." - Cervantes| +------------------------------------------------------------------------+ |
From: Christopher S. M. <br...@ma...> - 2012-09-26 01:52:07
|
On Sep 25, 2012, at 6:12 PM, Kevin Walzer wrote: > 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. Cool, thanks for the efforts! > 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. Kill it. It's a dead-end development path, a distraction, unnecessary complexity, and will consume limited resources to keep it preserved in any capacity. Revision control holds what got removed if someone needs it. > 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. Putting on a project management hat, Tk (and Tcl to a lesser degree) really needs all the help it can to increase development velocity. That means reducing overhead, eliminating redundancies, reducing complexity, and employing time-savory refactorings. Getting rid of the Carbon code does that wholesale and lets efforts be rightly focused on the Cocoa work going forward. It's an all-around win. Cheers! Sean |
From: Steve L. <st...@di...> - 2012-09-26 02:15:51
|
On 25/09/2012, at 8:51 PM, Christopher Sean Morrison <br...@ma...> wrote: > > On Sep 25, 2012, at 6:12 PM, Kevin Walzer wrote: > >> 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. > > Cool, thanks for the efforts! > >> 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. > > Kill it. It's a dead-end development path, a distraction, unnecessary complexity, and will consume limited resources to keep it preserved in any capacity. Revision control holds what got removed if someone needs it. > >> 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. > > Putting on a project management hat, Tk (and Tcl to a lesser degree) really needs all the help it can to increase development velocity. That means reducing overhead, eliminating redundancies, reducing complexity, and employing time-savory refactorings. Getting rid of the Carbon code does that wholesale and lets efforts be rightly focused on the Cocoa work going forward. It's an all-around win. +1 Steve |
From: Torsten B. <re...@ma...> - 2012-09-26 09:00:36
|
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...@co...>: > 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 > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac |
From: Kevan H. <ha...@br...> - 2012-09-26 18:18:15
|
Dear Kevin, I support your plan to drop Carbon and concentrate upon Cocoa. Our software is very sensitive to event loop problems. I will be happy to report any such problems in detail as part of the Cocoa effort. So far as I can tell, the Cocoa version will run on OSX10.4. Can you confirm this for me? I have some old machines doing data acquisition in my laboratory that run 10.4 and 10.5, and I see no reason to retire them. Thank you for maintaining Tk-Cocoa. Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/ |
From: Hans-Christoph S. <ha...@at...> - 2012-09-26 19:17:09
|
I'll throw in my two cents: I think its also a good idea to simplify Tk by removing Carbon. .hc On 09/26/2012 01:55 PM, Kevan Hashemi wrote: > Dear Kevin, > > I support your plan to drop Carbon and concentrate upon Cocoa. Our > software is very sensitive to event loop problems. I will be happy to > report any such problems in detail as part of the Cocoa effort. > > So far as I can tell, the Cocoa version will run on OSX10.4. Can you > confirm this for me? I have some old machines doing data acquisition in > my laboratory that run 10.4 and 10.5, and I see no reason to retire them. > > Thank you for maintaining Tk-Cocoa. > > Yours, Kevan > |
From: Kevin W. <kw...@co...> - 2012-10-02 01:46:39
|
Hi Kevan, On 9/26/12 1:55 PM, Kevan Hashemi wrote: > So far as I can tell, the Cocoa version will run on OSX10.4. Can you > confirm this for me? I have some old machines doing data acquisition in > my laboratory that run 10.4 and 10.5, and I see no reason to retire them. Sorry for not responding to this. Cocoa requires 10.5 minimum. There were some significant changes in the Objective-C runtime on that version of OS X, and it's the first OS version to fully support 64-bit. If you need to support 10.4, stick with Carbon. Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Kevin W. <kw...@co...> - 2012-10-02 02:16:33
|
On 9/26/12 4:33 AM, Torsten Berg wrote: > 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. That seems to be the consensus of everyone--I haven't seen a single comment in favor of keeping Carbon, although I understand many folks are not 100% comfortable with the state of Cocoa. I've started another thread on one of the core issues facing Cocoa, and am working on closing some of the other bugs we've discussed. With that said, I'll take this discussion to the Tcl-Core mailing list with the report that the consensus of the Tcl-Mac community is to drop Carbon. Thanks to all for their input. -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Jeff H. <je...@ac...> - 2012-10-02 03:37:39
|
On 2012-10-01, at 6:46 PM, Kevin Walzer <kw...@co...> wrote: > On 9/26/12 1:55 PM, Kevan Hashemi wrote: >> So far as I can tell, the Cocoa version will run on OSX10.4. Can you >> confirm this for me? I have some old machines doing data acquisition in >> my laboratory that run 10.4 and 10.5, and I see no reason to retire them. > > Sorry for not responding to this. > > Cocoa requires 10.5 minimum. There were some significant changes in the > Objective-C runtime on that version of OS X, and it's the first OS > version to fully support 64-bit. > > If you need to support 10.4, stick with Carbon. And keep it off the internet. Apple is sticking with the current + last support model, so even 10.6 is on the last set of security patches before it's obsolescence from a support perspective. Jeff |
From: Kevan H. <ha...@br...> - 2012-10-02 15:14:43
|
Kevin wrote: > If you need to support 10.4, stick with Carbon. Okay. That's easy enough to do. Jeff wrote; > And keep it off the internet. Apple is sticking with the current + > last support model, so even 10.6 is on the last set of security > patches before it's obsolescence from a support perspective. Rats. I find that a bit depressing. They make a computer so robust that it is still going after ten years, and then drop software support. Your, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/ |
From: Kevin W. <kw...@co...> - 2012-09-26 14:17:51
|
Hi Torsten, On 9/26/12 4:33 AM, Torsten Berg wrote: > 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. I plan to revisit the event loop stuff in the near future and see if I can figure it out. Believe me, I am very frustrated with the performance of Tk-Cocoa, and have attempted to address it in the past--the lack of progress is not for lack of trying, it's just very complicated. I appreciate what a hard job Daniel Steffen had to do in integrating two such disparate frameworks (Tk and Cocoa). If there are other open bugs, it would be very helpful if you can identify them so I can take a look. Example scripts illustrating the problem are even better, but at a minimum please post the bug numbers here. When I assumed actively maintaining Tk-Cocoa last year, I went through years worth of open bugs, fixed a lot that were low-hanging fruit, closed others as obsolete, and committed patches to some when patches were provided; I also added a large section of documentation to the Tk man pages on the tk:mac commands. I thought that cleaned things up substantially, but perhaps there are issues I've missed. More recently I've just focused on keeping the backport up-to-date. Adrian Robert has submitted several extremely helpful patches to fix issues he's identified; Adrian, thank you again. In the meantime, thanks to all for the feedback, and feel free to add more. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Torsten B. <re...@ma...> - 2012-09-26 19:38:30
|
Dear Kevin, > If there are other open bugs, it would be very helpful if you can > identify them so I can take a look. Example scripts illustrating the > problem are even better, but at a minimum please post the bug numbers here. OK, let's then try to identify and subsequently remove as many bugs in Tk-Cocoa as we can possibly find. So let me start with this bug: https://sourceforge.net/tracker/?func=detail&aid=3572016&group_id=12997&atid=112997 Regards, Torsten |
From: Kevin W. <kw...@co...> - 2012-09-28 13:35:45
|
Hi Torsten, > > OK, let's then try to identify and subsequently remove as many bugs in Tk-Cocoa as we can possibly find. So let me start with this bug: > > https://sourceforge.net/tracker/?func=detail&aid=3572016&group_id=12997&atid=112997 > This bug seems to be an example of event loop issues--I'm working on a fix that I hope will address this, and a few other issues. I'll provide an update after I do further testing. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Peter C. <pc...@wo...> - 2012-09-27 14:58:16
|
On 26/09/12 6:12 AM, Kevin Walzer wrote: > 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. A reluctant yes from me too. The event loop issues have been show stoppers for a couple of my older apps, but, Cocoa is really the only way forward. With the "security" stuff in Mountain Lion to make the Mac App Store the only trusted software source by default, I can't see Apple keeping Carbon around for much longer than they have to. |
From: Linus N. <li...@fa...> - 2012-09-28 06:03:25
|
We are still using 8.5 (and not the most recent one either) with Carbon for our application and it's working pretty well for us. The main thing preventing us from switching to 8.6 Cocoa is the lack of printing support, which we have with Carbon through the MacCarbonPrint extension. We still do (of course) not see Carbon as a future friendly platform and are trying to come up with ways of transitioning… Suggestions from anyone on the whole printing problem would be very appreciated. This being said, I don't mind you stopping the development on the Carbon version as long as I can still get a hold of the old source code. Linus farmerswife.com On 26 sep 2012, at 00:12, Kevin Walzer <kw...@co...> wrote: > 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 |
From: Steven <ste...@ya...> - 2012-09-28 06:42:11
|
It seems that while people mainly agree that Carbon is deprecated, and to simplify new Wish builds to only support Cocoa, many are quite happy to - or have to - stick with Carbon because Cocoa is not quite ready. Probably Tcl/Tk development isn't so speedy that getting the latest version is very important anyway. For those who don't ship their own framework, Is there an easy way to see if the utilized Wish/Tk is built with Carbon or Cocoa ? That way, an App known to not work with Cocoa can just bail out with a meaningful error message, rather than fail a gruesome death. Currently i'm just resolving symbolic links and doing an "otool -L" on the end binary, but this is a little hard from inside the App. Steven >________________________________ > From: Linus Nyberg <li...@fa...> >To: kw...@co... >Cc: "tc...@li... List" <tc...@li...> >Sent: Friday, 28 September 2012 3:38 PM >Subject: Re: [MACTCL] Drop Carbon support from Tk-Aqua? > > >We are still using 8.5 (and not the most recent one either) with Carbon for our application and it's working pretty well for us. The main thing preventing us from switching to 8.6 Cocoa is the lack of printing support, which we have with Carbon through the MacCarbonPrint extension. >We still do (of course) not see Carbon as a future friendly platform and are trying to come up with ways of transitioning… Suggestions from anyone on the whole printing problem would be very appreciated. >This being said, I don't mind you stopping the development on the Carbon version as long as I can still get a hold of the old source code. > > >Linus >farmerswife.com > > >On 26 sep 2012, at 00:12, Kevin Walzer <kw...@co...> wrote: > >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 > >------------------------------------------------------------------------------ >Got visibility? >Most devs has no idea what their production app looks like. >Find out how fast your code is with AppDynamics Lite. >http://ad.doubleclick.net/clk;262219671;13503038;y? >http://info.appdynamics.com/FreeJavaPerformanceDownload.html >_______________________________________________ >Tcl-mac mailing list >tc...@li... >https://lists.sourceforge.net/lists/listinfo/tcl-mac > > > |
From: Kevin W. <kw...@co...> - 2012-09-28 13:46:23
|
On 9/28/12 2:42 AM, Steven wrote: > For those who don't ship their own framework, Is there an easy way to see > if the utilized Wish/Tk is built with Carbon or Cocoa ? > That way, an App known to not work with Cocoa can just bail out > with a meaningful error message, rather than fail a gruesome death. > Currently i'm just resolving symbolic links and doing an "otool -L" on > the end binary, > but this is a little hard from inside the App. The standard way is to parse the output of [winfo server .]--if the string includes "AppKit," it's Cocoa. -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Torsten B. <re...@ma...> - 2012-09-28 09:25:31
|
Hi, and here is the next serious bug: Tk crashes on copy and cut operation in the text widget https://sourceforge.net/tracker/?func=detail&aid=3572695&group_id=12997&atid=112997 Regards, Torsten > Dear Kevin, > > >> If there are other open bugs, it would be very helpful if you can >> identify them so I can take a look. Example scripts illustrating the >> problem are even better, but at a minimum please post the bug numbers here. > > OK, let's then try to identify and subsequently remove as many bugs in Tk-Cocoa as we can possibly find. So let me start with this bug: > > https://sourceforge.net/tracker/?func=detail&aid=3572016&group_id=12997&atid=112997 > > > > Regards, Torsten > ------------------------------------------------------------------------------ > How fast is your code? > 3 out of 4 devs don\\\'t know how their code performs in production. > Find out how slow your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219672;13503038;z? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Tcl-mac mailing list > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac |
From: Adrian R. <adr...@gm...> - 2012-09-28 11:24:08
|
That crash looks suspiciously like one that was posted and fixed here on the list a month or so ago. (And prompted the whole merge and discussion we are having now.) Are you testing against latest fossil? Also when posting the bug reports, please run a debug-built Tcl/Tk if you can, so that files and line numbers will show up in the trace. thanks, Adrian On 2012/09/28, at 5:23, Torsten Berg <re...@ma...> wrote: > Hi, > > and here is the next serious bug: Tk crashes on copy and cut operation in the text widget > > https://sourceforge.net/tracker/?func=detail&aid=3572695&group_id=12997&atid=112997 > > Regards, Torsten > > >> Dear Kevin, >> >> >>> If there are other open bugs, it would be very helpful if you can >>> identify them so I can take a look. Example scripts illustrating the >>> problem are even better, but at a minimum please post the bug numbers here. >> >> OK, let's then try to identify and subsequently remove as many bugs in Tk-Cocoa as we can possibly find. So let me start with this bug: >> >> https://sourceforge.net/tracker/?func=detail&aid=3572016&group_id=12997&atid=112997 >> >> >> >> Regards, Torsten >> ------------------------------------------------------------------------------ >> How fast is your code? >> 3 out of 4 devs don\\\'t know how their code performs in production. >> Find out how slow your code is with AppDynamics Lite. >> http://ad.doubleclick.net/clk;262219672;13503038;z? >> http://info.appdynamics.com/FreeJavaPerformanceDownload.html >> _______________________________________________ >> Tcl-mac mailing list >> tc...@li... >> https://lists.sourceforge.net/lists/listinfo/tcl-mac > > > ------------------------------------------------------------------------------ > Got visibility? > Most devs has no idea what their production app looks like. > Find out how fast your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219671;13503038;y? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Tcl-mac mailing list > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac |
From: Steven <ste...@ya...> - 2012-09-28 11:38:19
|
> and here is the next serious bug: Tk crashes on copy > and cut operation in the text widget This bug is known, and fixed in 8.5 i think. http://sourceforge.net/tracker/?func=detail&aid=3555211&group_id=12997&atid=112997 I think we should make it more prominent that tk cocoa is unstable. Otherwise the tracker is just getting overloaded with things like this: http://sourceforge.net/tracker/?func=detail&aid=3569637&group_id=12997&atid=112997 Tk Cocoas instability drove me mad for weeks until i realised what was happening. S. |
From: Torsten B. <re...@ma...> - 2012-09-28 12:49:18
|
Hi, oh, sorry, I must have missed that one. I thought 8.6b3 published 9 days ago would be the most recent version including all fixes but that seems not to be the case then. I tested against latest fossil (as of today) and can confirm the bug is not there anymore. So, sorry for making noise here ... I referenced the fix and closed the ticket. Regards, Torsten Am 28.09.2012 um 13:23 schrieb Adrian Robert <adr...@gm...>: > That crash looks suspiciously like one that was posted and fixed here on the list a month or so ago. (And prompted the whole merge and discussion we are having now.) Are you testing against latest fossil? Also when posting the bug reports, please run a debug-built Tcl/Tk if you can, so that files and line numbers will show up in the trace. > > thanks, > Adrian > > > > On 2012/09/28, at 5:23, Torsten Berg <re...@ma...> wrote: > >> Hi, >> >> and here is the next serious bug: Tk crashes on copy and cut operation in the text widget >> >> https://sourceforge.net/tracker/?func=detail&aid=3572695&group_id=12997&atid=112997 >> >> Regards, Torsten >> >> >>> Dear Kevin, >>> >>> >>>> If there are other open bugs, it would be very helpful if you can >>>> identify them so I can take a look. Example scripts illustrating the >>>> problem are even better, but at a minimum please post the bug numbers here. >>> >>> OK, let's then try to identify and subsequently remove as many bugs in Tk-Cocoa as we can possibly find. So let me start with this bug: >>> >>> https://sourceforge.net/tracker/?func=detail&aid=3572016&group_id=12997&atid=112997 >>> >>> >>> >>> Regards, Torsten |
From: Adrian R. <adr...@gm...> - 2012-09-28 14:39:03
|
Hmm, I'm also surprised the fix did not make it into 8.6b3. It definitely should have. Was that branched a long time ago and more recent fixes did not make it in? On 2012/09/28, at 8:49, Torsten Berg <re...@ma...> wrote: > Hi, > > oh, sorry, I must have missed that one. I thought 8.6b3 published 9 days ago would be the most recent version including all fixes but that seems not to be the case then. I tested against latest fossil (as of today) and can confirm the bug is not there anymore. So, sorry for making noise here ... > > I referenced the fix and closed the ticket. > > Regards, Torsten > > > Am 28.09.2012 um 13:23 schrieb Adrian Robert <adr...@gm...>: > >> That crash looks suspiciously like one that was posted and fixed here on the list a month or so ago. (And prompted the whole merge and discussion we are having now.) Are you testing against latest fossil? Also when posting the bug reports, please run a debug-built Tcl/Tk if you can, so that files and line numbers will show up in the trace. >> >> thanks, >> Adrian >> >> >> >> On 2012/09/28, at 5:23, Torsten Berg <re...@ma...> wrote: >> >>> Hi, >>> >>> and here is the next serious bug: Tk crashes on copy and cut operation in the text widget >>> >>> https://sourceforge.net/tracker/?func=detail&aid=3572695&group_id=12997&atid=112997 >>> >>> Regards, Torsten >>> >>> >>>> Dear Kevin, >>>> >>>> >>>>> If there are other open bugs, it would be very helpful if you can >>>>> identify them so I can take a look. Example scripts illustrating the >>>>> problem are even better, but at a minimum please post the bug numbers here. >>>> >>>> OK, let's then try to identify and subsequently remove as many bugs in Tk-Cocoa as we can possibly find. So let me start with this bug: >>>> >>>> https://sourceforge.net/tracker/?func=detail&aid=3572016&group_id=12997&atid=112997 >>>> >>>> >>>> >>>> Regards, Torsten > |