tcl-mac — Q&A for Tcl on the Macintosh platform

[MACTCL] Tk-Cocoa bugs (was: Drop Carbon support from Tk-Aqua?)

[Torsten B. <re...@ma...>]

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

Re: [MACTCL] Drop Carbon support from Tk-Aqua?

[Hans-Christoph S. <ha...@at...>]

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
>

Re: [MACTCL] Drop Carbon support from Tk-Aqua?

[Kevan H. <ha...@br...>]

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/

Re: [MACTCL] Drop Carbon support from Tk-Aqua?

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

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

Re: [MACTCL] Drop Carbon support from Tk-Aqua?

[Torsten B. <re...@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...@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

Re: [MACTCL] Drop Carbon support from Tk-Aqua?

[Steve L. <st...@di...>]

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

Re: [MACTCL] Drop Carbon support from Tk-Aqua?

[Gerald W. L. <ger...@gm...>]

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|
+------------------------------------------------------------------------+

Re: [MACTCL] Drop Carbon support from Tk-Aqua?

[Christopher S. M. <br...@ma...>]

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

Re: [MACTCL] Drop Carbon support from Tk-Aqua?

[Adrian R. <adr...@gm...>]

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

Re: [MACTCL] Drop Carbon support from Tk-Aqua?

[Jeff H. <je...@ac...>]

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
>
>

[MACTCL] Drop Carbon support from Tk-Aqua?

[Kevin W. <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

Re: [MACTCL] [TCLCORE] Full merge of OS X Cocoa port to Tk 8.5 main branch?

[Jeff H. <je...@ac...>]

Following up on this, Kevin Walzer was willing to give this a pass for integration.

Kevin - note the branch that Jan created below.  Andreas can assist with code comparison and build testing.

Let us know if you need anything else.

See full thread for this at:

http://code.activestate.com/lists/tcl-core/11633/

Jeff

On 2012-08-09, at 1:10 AM, Jan Nijtmans <jan...@gm...> wrote:
> 2012/8/9 Jeff Hobbs <je...@ac...>
> Understood.  We would do the merge based on the assumption that only tk/macosx/* should change.  Any changes in other directories will be reviewed with extreme prejudice.
> 
> It can have a review branch as well for others prior to final merge.
> 
> Thanks! I already looked at some harmless differences, put them
> in core-8-5-branch.
> 
> So, let's do some experiment (see jn-cocoa-full-merge-8.5 branch).
> It is constructed from core-8-5-branch, but all generic/tk*.decls and
> macosx/* files are simply copied from the tk-cocoa-8-5-backport
> branch, and "make genstubs" run. Files removed from
> tk-cocoa-8-5-backport are removed here as well. The changes
> in the *.decls files are only in the macosx functions (I verified that!),
> so harmless for other platforms.
> 
> Therefore the jn-cocoa-full-merge-8.5 branch is guaranteed
> to build on other platforms (unix/windows/...), no-one will
> have any objection merging this to core-8-5-branch (and
> then merge-mark to tk-cocoa-8-5-backport and trunk,
> because everything is in there already). The cocoa build
> is probably broken, but who cares because it's not
> broken in tk-cocoa-8-5-backport. Then, let's look at the
> differences between jn-cocoa-full-merge and
> tk-cocoa-8-5-backport. It's only in 5 files:
> Files ../tk8.5/unix/configure and ./unix/configure differ
> Files ../tk8.5/unix/configure.in and ./unix/configure.in differ
> Files ../tk8.5/unix/Makefile.in and ./unix/Makefile.in differ
> Files ../tk8.5/unix/tcl.m4 and ./unix/tcl.m4 differ
> Files ../tk8.5/xlib/xgc.c and ./xlib/xgc.c differ
> 
> So, those are the only differences left need to be considered
> carefully.
> 
> I think this is the fasted way to get things done. It is
> better to do things on core-8-5-branch as much as
> possible, simply because then we don't have to
> ask people to look at other branches. Now is
> a good moment to do that: vacation time with
> little activity, just after the 8.5.12 release, so
> plenty of time for testing until 8.5.13.
> 
> How does that sound?
> 
> Regards,
>            Jan Nijtmans

[MACTCL] Registration Open for 19th Annual Tcl/Tk Conference (Tcl'2012)

[Andreas K. <and...@ac...>]

19th Annual Tcl/Tk Conference (Tcl'2012)
http://www.tcl.tk/community/tcl2012/

November 12 - 16, 2012
Sessions:
    National Museum of Health and Medicine Chicago
    175 W. Washington
    Chicago, IL 60602

Rooms:
    Holiday Inn Chicago Mart Plaza
    350 West Mart Center Drive
    Chicago, Illinois, USA

Map/Transport:
    https://maps.google.com/maps/ms?msid=204739899073144451536.0004c144222a9036c99f6&msa=0&ll=41.885266,-87.633734&spn=0.008443,0.018818 
    http://wiki.tcl.tk/28843#pagetoca7e55932


I am pleased to announce that registration for the Conference is now
open at

	http://www.tcl.tk/community/tcl2012/reg.html

To book a room at the conference hotel at reduced rates please follow
the instructions on that page. Note that the offer of reduced rates
expires on October 20. Book early.

Our schedule can be found at

	http://www.tcl.tk/community/tcl2012/schedule.html

Conference Committee

Clif Flynt              Noumena Corp					General Chair, Website Admin
Andreas Kupries         ActiveState Software Inc.			Program Chair
Cyndy Lilagan           Nat. Museum of Health & Medicine, Chicago	Site/Facilities Chair
Arjen Markus            Deltares
Brian Griffin           Mentor Graphics
Donal Fellows           University of Manchester
Gerald Lester           KnG Consulting, LLC
Jeffrey Hobbs           ActiveState Software Inc.
Kevin Kenny             GE Global Research Center
Larry Virden
Mike Doyle              National Museum of Health & Medicine, Chicago
Ron Fox                 NSCL/FRIB Michigan State University
Steve Landers           Digital Smarties

Contact Information     tcl...@go...


Tcl'2012 would like to thank those who are sponsoring the conference:

ActiveState Software Inc.
Buonacorsi Foundation
Mentor Graphics
Noumena Corp.
SR Technology
Tcl Community Association

[MACTCL] Pulling out of Mac App Store

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

Hi all,

Since I was (I believe) the first Tcl-Mac developer to get an app 
accepted into Apple's Mac App Store, it may be appropriate for me to 
announce here that I'm now pulling out of the App Store.

I explain the details at 
http://www.codebykevin.com/blosxom.cgi/2012/09/06#leaving-app-store, but 
the bottom line is that Apple's "sandbox" security restrictions make it 
too hard for my apps to do what I want them to do. The specific issue I 
ran into was that I couldn't exec "/usr/bin/open" to launch an e-mail 
client or web browser; while the "open" command can be configured to 
work with sandbox, at the deepest level Tcl writes a temp file to 
/private/tmp when launching a child process, and that is also a no-no 
under the sandbox guidelines.

A separate issue, not at present a concern but lurking on the margins, 
is that Tk-Cocoa also violates the App Store guidelines in many ways by 
calling into private Apple API's for drawing and window management; this 
was by design, emulating WebKit itself, and the only way I could work 
around it was by linking to Apple's system installation of the Tk 
frameworks. If Apple ever decides to remove Tk from its system 
libraries, I would be forced to withdraw my apps anyway.

The bottom line is that I consider the App Store guidelines too 
restrictive for me to develop the way I want, and for my apps to have 
the functionality I'd like; and I'm not the only developer withrawing 
from the App Store because of such concerns. If anyone else in on the 
list was contemplating submitting a Tk app to the App Store, it's useful 
to keep these things in mind.

(I had posted a tutorial on submitting a Tk app to the App Store--I'll 
leave it up for now, but may remove it in the future. Let me know if 
there's interest.)

Thanks,
Kevin

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

Re: [MACTCL] Tk 8.5.12.x crashes opening IDLE Preferences menu

[Adrian R. <adr...@gm...>]

Ditto.  Are there nightly builds of ActiveTcl anywhere so the existence of such bugs can be checked?  (Such might also help prevent really bad things making it into the release like last time, by triggering wider-spread testing.)

thanks,
Adrian


On 2012/09/05, at 9:51, Kevin Walzer <kw...@co...> wrote:

> On 9/5/12 4:09 AM, Ned Deily wrote:
>> Here's another regression with 8.5.12.x.  Using IDLE on OS X from a
>> Python that will link with ActiveTcl 8.5, attempting to open IDLE's
>> Preferences menu, either with the mouse (IDLE -> Preferences) or with
>> the keyboard accelerator (Cmd-`) causes an immediate crash in Tk.
> 
> I can't reproduce this; my build of Tk is current as of last month, when 
> we went through the last round of regressions that Neil reported. I 
> wonder if this is an example of the same bug and was fixed; I also don't 
> believe that there has been a release of ActiveTcl since then 
> incorporating the fix that Adrian submitted.
> 
> My means of testing this is simply to run a test script with this code:
> 
> proc tk::mac::ShowPreferences {} {
> 
> puts "foo"
> 
> }
> 
> Defining the procedure activates the menu items, and it works as expected.
> 
> --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

Re: [MACTCL] Tk 8.5.12.x crashes opening IDLE Preferences menu

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

On 9/5/12 4:09 AM, Ned Deily wrote:
> Here's another regression with 8.5.12.x.  Using IDLE on OS X from a
> Python that will link with ActiveTcl 8.5, attempting to open IDLE's
> Preferences menu, either with the mouse (IDLE -> Preferences) or with
> the keyboard accelerator (Cmd-`) causes an immediate crash in Tk.

I can't reproduce this; my build of Tk is current as of last month, when 
we went through the last round of regressions that Neil reported. I 
wonder if this is an example of the same bug and was fixed; I also don't 
believe that there has been a release of ActiveTcl since then 
incorporating the fix that Adrian submitted.

My means of testing this is simply to run a test script with this code:

proc tk::mac::ShowPreferences {} {

puts "foo"

}

Defining the procedure activates the menu items, and it works as expected.

--Kevin


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

[MACTCL] Tk 8.5.12.x crashes opening IDLE Preferences menu

[Ned D. <na...@ac...>]

Here's another regression with 8.5.12.x.  Using IDLE on OS X from a 
Python that will link with ActiveTcl 8.5, attempting to open IDLE's 
Preferences menu, either with the mouse (IDLE -> Preferences) or with 
the keyboard accelerator (Cmd-`) causes an immediate crash in Tk.  I 
assume what is special here is that IDLE uses the 
::tk::mac::ShowPreferences event (http://wiki.tcl.tk/12987).  The 
problem should be simple to reproduce: install the current ActiveTcl 
8.5.12.1 and any of the python.org 64-bit installers for 2.7.x, 3.2.x, 
and 3.3.0rc1 and then type /usr/local/idle2.7 or /usr/local/idle3.x and 
then type Cmd-`.  The current ActivePython 2.7.2.5 for OS X crashes as 
well (I didn't try the ActivePython 3.2).  Unfortunately, since only the 
most recent ActiveTcl is available to Community Edition users, unless 
you have saved copies of Active 8.5.11.1 or earlier, you are out of luck 
especially on OS X 10.6 where Apple's Tk 8.5 is fatally buggy.   Does 
anyone have a native Tk app that uses ::tk::mac::ShowPreferences that 
reproduces the crash as well?

Here's the initial part of the stack trace:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   Tk                              0x00000001011c4e6c 
TkpConfigureMenuEntry + 1923
1   Tk                              0x0000000101145ffe MenuWorldChanged 
+ 61
2   Tk                              0x000000010111fa99 RecomputeWidgets 
+ 47
3   Tk                              0x000000010111faa7 RecomputeWidgets 
+ 61
4   Tk                              0x000000010111faa7 RecomputeWidgets 
+ 61
5   Tcl                             0x0000000101091e81 TclServiceIdle + 
76
6   Tcl                             0x0000000101076432 Tcl_DoOneEvent + 
329
7   Tk                              0x0000000101140832 MapFrame + 42
8   Tcl                             0x0000000101091e81 TclServiceIdle + 
76
9   Tcl                             0x0000000101076432 Tcl_DoOneEvent + 
329
10  Tk                              0x0000000101116e26 Tk_TkwaitObjCmd + 
555
11  Tcl                             0x00000001010108ad 
TclEvalObjvInternal + 782
12  Tcl                             0x0000000101011a9f Tcl_EvalObjv + 66
13  _tkinter.so                     0x00000001007068cd Tkapp_Call + 189
14  org.python.python               0x00000001000c1e7d 
PyEval_EvalFrameEx + 25213

-- 
 Ned Deily,
 na...@ac...

Re: [MACTCL] OSX 10.8 gatekeeper issue

[Zbigniew D. <z....@gm...>]

Am 27.08.2012 12:22, schrieb Zbigniew Diaczyszyn:
> Am 23.08.2012 12:31, schrieb Kevin Walzer:
>> The default setting in 10.8 won't allow an app to run without being
>> signed by an Apple Developer ID.
>>
>> There are a couple of solutions:
>>
>> 1. Pay $99, join Apple's developer program, and get a developer ID.
>
> Ah, I don't know if it is the right account but I have got if for free:
>
> https://developer.apple.com/programs/register/
>
> So I will make some experiments with the tool "codedesign" ...

No, there won't be experiments. When I try to get a certificate Apple 
tells me:


"You do not have access to this page.

Either you not part of the program or do not have required priviliges to 
access this page"

Clicking further on I have been informed that enrolling to the Mac 
developer program needs $99 to be payed as annual fee.

On the long run no good perspective for public domain applications ...

Re: [MACTCL] OSX 10.8 gatekeeper issue

[Zbigniew D. <z....@gm...>]

Am 23.08.2012 12:31, schrieb Kevin Walzer:
> The default setting in 10.8 won't allow an app to run without being
> signed by an Apple Developer ID.
>
> There are a couple of solutions:
>
> 1. Pay $99, join Apple's developer program, and get a developer ID.

Ah, I don't know if it is the right account but I have got if for free:

https://developer.apple.com/programs/register/

So I will make some experiments with the tool "codedesign" ...

Re: [MACTCL] OSX 10.8 gatekeeper issue

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

On 8/26/12 4:28 AM, Wojciech Kocjan wrote:
> 2012/8/23 Kevin Walzer <kw...@co...>:
>> If you decide to go the Developer ID route, it's not hard to sign an app
>> with your certificate--it can be done from the command line using the
>> "codesign" tool.
>
> Question about that part - were you able to sign a tclkit binary -
> i.e. one with actual binary data and VFS at the end?

I'm not using a tclkit, but rather a standalone build of Wish (the Mac 
version supports this type of deployment), and I don't run into this 
issue--but what you're reported is interesting. I'm not sure there's 
another way to proceed other than the way you've found.

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

Re: [MACTCL] OSX 10.8 gatekeeper issue

[Wojciech K. <woj...@ko...>]

2012/8/23 Kevin Walzer <kw...@co...>:
> If you decide to go the Developer ID route, it's not hard to sign an app
> with your certificate--it can be done from the command line using the
> "codesign" tool.

Question about that part - were you able to sign a tclkit binary -
i.e. one with actual binary data and VFS at the end?

Maybe you are doing it differently than I am - and I have made something wrong.

For me codesign rejected this, and what is more interesting (and
scary), doing sdx mksplit, signing the head and packaging the binary
back worked - so only the head (binary code) is signed and modifying
VFS does not require signing again.

That is fine since OSX accepts it, but it is scary since anyone
grabbing my binary can modify VFS (i.e. throw in their application
instead) and still ship it as signed by me.

Again, I expect I am doing something wrong rather than signing the
head only being the right way to go.

Re: [MACTCL] OSX 10.8 gatekeeper issue

[Zbigniew D. <z....@gm...>]

Kevin and Tim, thank you for your hints

Zbigniew

Re: [MACTCL] OSX 10.8 gatekeeper issue

[Tim J. <tj...@to...>]

On Aug 23, 2012, at 3:31 AM, Kevin Walzer wrote:

> There are a couple of solutions:
> 
> 1. Pay $99, join Apple's developer program, and get a developer ID.
> 2. Tell users to adjust the security settings on their machines to allow 
> unsigned apps to run.

3. Tell the user to right-click on the app and they will be prompted with a different dialog allowing them to open the app.  That should only be required the first time.

But, Kevin's point 1 is still the best solution.

Tim

Re: [MACTCL] OSX 10.8 gatekeeper issue

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

On 8/23/12 2:31 AM, Zbigniew Diaczyszyn wrote:
> An user of my starpacked public domain Tcl/Tk 8.5.11 application wrote
> that it can't be launched on the new Lion Mountain and that a dialog box
> recommends to put it in the trash.
>
> Apparently this issue is caused by the new gatekeeper which will prevent
> to start programs that are not encrypted with a licensed Apple developer ID.
>
> A workaround is not to doubleclick the application but to rightclick and
> "open" it despite the warning message but this is just a workaround.
>
> Has anyone solved this issue?
>
> I wonder if a registration fee has to be payed and I have no idea how to
> encrypt a starpack with this developer ID.

The default setting in 10.8 won't allow an app to run without being 
signed by an Apple Developer ID.

There are a couple of solutions:

1. Pay $99, join Apple's developer program, and get a developer ID.
2. Tell users to adjust the security settings on their machines to allow 
unsigned apps to run.

Gatekeeper is actually a nice compromise between no security at all 
(harder to justify these days) and the App Store, which not only imposes 
signing requirements but also requires major compromises in 
functionality to operate in a sandboxed environment. (I have a couple of 
apps in the App Store, and some outside of it, for this reason.)

If you decide to go the Developer ID route, it's not hard to sign an app 
with your certificate--it can be done from the command line using the 
"codesign" tool.

Hope this helps,
Kevin

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

[MACTCL] OSX 10.8 gatekeeper issue

[Zbigniew D. <z....@gm...>]

An user of my starpacked public domain Tcl/Tk 8.5.11 application wrote 
that it can't be launched on the new Lion Mountain and that a dialog box 
recommends to put it in the trash.

Apparently this issue is caused by the new gatekeeper which will prevent 
to start programs that are not encrypted with a licensed Apple developer ID.

A workaround is not to doubleclick the application but to rightclick and 
"open" it despite the warning message but this is just a workaround.

Has anyone solved this issue?

I wonder if a registration fee has to be payed and I have no idea how to 
encrypt a starpack with this developer ID.