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

[MACTCL] any one else notice the archives on this list are now ridiculously hard to read? CSS change?

[James B. <jam...@ma...>]

The archive pages aren't wrapping the text. So I go here to something I've posted in the past:

http://sourceforge.net/mailarchive/message.php?msg_id=29569661

and I can see anything after midway into my second sentence since it's clipped off. There are no scroll bars. I tried the latest Safari and Firefox on the mac and Firefox on windows all have the same problem. With Chrome on windows I can at least drag-select-scroll to see the clipped text, which works but is awful.

 I did notice that some posts seem to have hard line breaks, in these modern times what's up with that? Did we go back 20 years in text display technology and I  need to type ~v!Gfmt before I post now?

Cheers,
 - James

PS
I don't really use /usr/bin/mail to post  ;-)

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

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

Dear Kevin,

> What I'd like to do, instead, is assemble some best practices.

I find your argument convincing. As it is, my applications already have 
serious problems with the Tcl event loop, and the Tk/Carbon event loop, 
almost all of which I have worked around by trial and error through 
insertion of update, update idletasks, vwaits and after commands. These 
commands do not, in my experience, do exactly what the TclTk 
documentation tells me they should do, but they almost always seem to 
fix the problem.

Every now and then, however, there comes an event-loop problem that I 
can't fix. The screen freezes during TCPIP communication, for example, 
and these I have submitted as bug reports and they have been fixed. So I 
imagine that the same thing will happen with the Tk/Cocoa event loop.

If we have a list of best practices, then people like you, who end up 
doing the bug fixes, can first point to this list before you spend your 
time looking into something that is supposed to be a bug. Thus I think 
this list of best practices is a good idea, and I accept the compromise 
you propose.

 From your subsequent answer to Adrian:

 > And on
 > the other side, there are other folks in this community with more
 > expertise than me, but with less time and/or interest: they just want 
 > Tk to work but don't want to have to dig deeply into its internals.

Yup, that's me. You are maintaining this code and also using it 
yourself. Looking at your portfolio of applications, it seems to me that 
you are firmly invested in TclTk on the Mac. Your investment gives your 
proposal a guarantee in my mind.

Yours, Kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://alignment.hep.brandeis.edu/

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

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

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/

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

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

Hi Adrian,

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

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

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

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

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

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

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

Thanks for the feedback,
Kevin


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

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

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

Hi Kevin,

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

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

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

-Adrian



On 2012/10/01, at 22:12, Kevin Walzer <kw...@co...> wrote:

> Hi all,
> 
> I just closed bug #3028676 
> (https://sourceforge.net/tracker/index.php?func=detail&aid=3028676&group_id=12997&atid=112997). 
> This is my reference bug for the Tk-Cocoa event loop issues, because 
> Lars Hellström (the OP) did a lot of investigating to isolate the source 
> of the problem, and Daniel Steffen (das, the author of the Tk-Cocoa 
> port) added some very useful points about his design intent.
> 
> Let me quote from my comments there:
> 
> ---
> Adding an "update" command to the core procedure in the sample script
> sidesteps the problem entirely.
> 
> I realize that this script was put together to assemble the core issue,
> that is, incoming Tcl events overloading the Cocoa/Tk event loop and
> causing it to lock up, but the fact is that careful management of the event
> loop with occasional workarounds like "update" or "after" can avoid many of
> the issues that are commonly reported.
> 
> I've spent a lot of time reading both das's code and the relevant docs (Tcl
> and CoreFoundation), and given the complexity of the task, I've concluded
> that the current implementation is good enough, albeit far from optimal.
> das had previously committed a significant update to the notifier, see
> https://sourceforge.net/mailarchive/message.php?msg_id=23324050, that
> addressed truly showstopper issues with its performance. Now it is slow and
> pone to occasional lockups, but in most cases these can be worked around.  I
> seldom see any issues with the event loop in my own applications because I
> work around the most common issues; it's been a long time since I've had a
> user complaint about a lockup because of event loop issues.
> 
> It seems clear that the Tk/Cocoa event loop is slower, more fragile, and
> more complex than the Carbon implementation; however, the ultimate
> responsibility for this lies with Apple's decision to deprecate Carbon and
> force Cocoa integration. Cocoa has many advantages, but it is not a natural
> fit for Tk the way that Carbon, which operated at the same low level of
> abstraction as Tk's C API, was.
> 
> Therefore, I've decided to close this bug, and will spend a bit of time
> deciding how to document the limitations of Tk-Cocoa's event loop and best
> practices for working around them.
> ---
> 
> At this point I don't think it's fruitful to try to improve the event 
> loop integration. Frankly, given the enormity of the task, I think the 
> work Daniel Steffen did single-handed on Tk-Cocoa is just amazing, and 
> I'm grateful for his efforts. The event loop code is some of the 
> gnarliest of the source tree, and based on bug reports, Daniel pushed it 
> forward from showstopping slow/crashprone to Barely Good Enough. 
> (That's not faint praise but rather high praise based on the difficulty 
> of the task.) As I say in my comment above, I seldom see event loop 
> issues in my own apps because I simply work around them wherever 
> possible (calls to update, after, update idletasks, etc.). It takes some 
> trial and error, but once I have a working solution, I don't have to 
> revisit it.
> 
> What I'd like to do, instead, is assemble some best practices. What do 
> you all do to work around these issues? Perhaps we can assemble a thread 
> here, and then post some ideas/code to the wiki. Or somewhere else? The 
> Tk man pages? Or both?
> 
> I'll start with a common solution in my apps: when an app has a sudden 
> error and throws up an error dialog (via the "bgerror" command), earlier 
> versions of Tk-Cocoa would lock up and prevent the dialog from drawing. 
> My solution was to re-define the "bgerror" command to write errors to 
> the console. (This is actually more useful in my view.)
> 
> #handle errors in Tk
> proc bgerror {args} {
>     exec syslog -s -l Error "PacketStream: An error occurred: $args"
> }
> 
> This issue has since been fixed, but I stopped worrying about it after 
> finding a viable workaround.
> 
> Other comments on this issue are appreciated.
> 
> --Kevin
> 
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Tk-Cocoa bugs

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

On 10/2/12 6:57 AM, Torsten Berg wrote:
> Just curious what the limitation is here.

I couldn't track down the issue in Tk itself, so I looked at Cocoa 
mailing lists to see if Cocoa developers had ever encountered a similar 
issue. The solution proposed on one Cocoa list was the solution I 
adopted here.

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

Re: [MACTCL] Tk-Cocoa bugs

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

Hi Kevin,

thank you very much for looking into this. Does this mean it is impossible right now to fix this in way it was working in Tk 8.5, i.e. disable menus during modal dialog and re-enabling them afterwards? Why is that? Just curious what the limitation is here.

Thanks again, 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
>> 
> 
> Fix committed on this bug for both trunk and 8-5-main-branch. The solution was to leave the menu items enabled even during a modal dialog--not optimal, but the alternative (menu being entirely disabled) is unacceptable.
> 
> Thanks for the bug report.
> 
> --Kevin
> 
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com

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

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

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

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

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

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

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

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

Hi all,

I just closed bug #3028676 
(https://sourceforge.net/tracker/index.php?func=detail&aid=3028676&group_id=12997&atid=112997). 
This is my reference bug for the Tk-Cocoa event loop issues, because 
Lars Hellström (the OP) did a lot of investigating to isolate the source 
of the problem, and Daniel Steffen (das, the author of the Tk-Cocoa 
port) added some very useful points about his design intent.

Let me quote from my comments there:

---
Adding an "update" command to the core procedure in the sample script
sidesteps the problem entirely.

I realize that this script was put together to assemble the core issue,
that is, incoming Tcl events overloading the Cocoa/Tk event loop and
causing it to lock up, but the fact is that careful management of the event
loop with occasional workarounds like "update" or "after" can avoid many of
the issues that are commonly reported.

I've spent a lot of time reading both das's code and the relevant docs (Tcl
and CoreFoundation), and given the complexity of the task, I've concluded
that the current implementation is good enough, albeit far from optimal.
das had previously committed a significant update to the notifier, see
https://sourceforge.net/mailarchive/message.php?msg_id=23324050, that
addressed truly showstopper issues with its performance. Now it is slow and
pone to occasional lockups, but in most cases these can be worked around.  I
seldom see any issues with the event loop in my own applications because I
work around the most common issues; it's been a long time since I've had a
user complaint about a lockup because of event loop issues.

It seems clear that the Tk/Cocoa event loop is slower, more fragile, and
more complex than the Carbon implementation; however, the ultimate
responsibility for this lies with Apple's decision to deprecate Carbon and
force Cocoa integration. Cocoa has many advantages, but it is not a natural
fit for Tk the way that Carbon, which operated at the same low level of
abstraction as Tk's C API, was.

Therefore, I've decided to close this bug, and will spend a bit of time
deciding how to document the limitations of Tk-Cocoa's event loop and best
practices for working around them.
---

At this point I don't think it's fruitful to try to improve the event 
loop integration. Frankly, given the enormity of the task, I think the 
work Daniel Steffen did single-handed on Tk-Cocoa is just amazing, and 
I'm grateful for his efforts. The event loop code is some of the 
gnarliest of the source tree, and based on bug reports, Daniel pushed it 
forward from showstopping slow/crashprone to Barely Good Enough. 
(That's not faint praise but rather high praise based on the difficulty 
of the task.) As I say in my comment above, I seldom see event loop 
issues in my own apps because I simply work around them wherever 
possible (calls to update, after, update idletasks, etc.). It takes some 
trial and error, but once I have a working solution, I don't have to 
revisit it.

What I'd like to do, instead, is assemble some best practices. What do 
you all do to work around these issues? Perhaps we can assemble a thread 
here, and then post some ideas/code to the wiki. Or somewhere else? The 
Tk man pages? Or both?

I'll start with a common solution in my apps: when an app has a sudden 
error and throws up an error dialog (via the "bgerror" command), earlier 
versions of Tk-Cocoa would lock up and prevent the dialog from drawing. 
My solution was to re-define the "bgerror" command to write errors to 
the console. (This is actually more useful in my view.)

#handle errors in Tk
proc bgerror {args} {
     exec syslog -s -l Error "PacketStream: An error occurred: $args"
}

This issue has since been fixed, but I stopped worrying about it after 
finding a viable workaround.

Other comments on this issue are appreciated.

--Kevin

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

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

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

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

Re: [MACTCL] Tk-Cocoa bugs

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

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
>

Fix committed on this bug for both trunk and 8-5-main-branch. The 
solution was to leave the menu items enabled even during a modal 
dialog--not optimal, but the alternative (menu being entirely disabled) 
is unacceptable.

Thanks for the bug report.

--Kevin

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

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

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

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
> 

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

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

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

Re: [MACTCL] Deprecated Cocoa methods

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

On 9/27/12 2:42 PM, Torsten Berg wrote:

> Apple says, the method 'runModal' should be used instead. This is a method that existed since Mac OS X 10.0 and as such would not cause any trouble with Tk-Cocoa running on older versions of OS X.
>
> What is the feeling in the Tcl community? Should we keep using deprecated methods until Apple removes them or should we actively try to maintain the code and update these methods when such issues are emerging?
>

My take is that given the other remaining issues with Tk-Cocoa and my 
own available time, updating deprecated methods is low priority. In 
response to another suggestion on this thread, I also am reluctant to 
load up Tk with a lot of OS-version-dependent API calls: the baseline 
supported version of Tk-Cocoa is 10.5 and that's where it should stay 
absent some huge reason to move it. (The shift to 64-bit and the 
significant changes in Objective-C with 10.5 merited such a baseline shift.)

One deprecated method that I haven't figured out how to address yet is 
garbage collection: Apple seems to be aggressively deprecating it in 
favor of automatic reference counting (ARC), and I haven't delved into 
the implications of this for Tk. It may not be necessary to worry about 
at all because Daniel Steffen designed Tk-Cocoa to support both GC and 
standard memory management, but it's something I will have to look at at 
some point.

If someone wants to submit a patch or two to address deprecated calls 
and they can be applied without breaking the 10.5 baseline of 
support--i.e., they don't require wrapping in an #ifdef to specify a 
later version of OS X--then I would be happy to review and include those.

--Kevin


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

Re: [MACTCL] Tk-Cocoa bugs

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

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

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

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

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

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

[Steven <ste...@ya...>]

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

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

[Adrian R. <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
>> ------------------------------------------------------------------------------
>> 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

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

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

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

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

[Steven <ste...@ya...>]

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

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

[Linus N. <li...@fa...>]

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

Re: [MACTCL] Deprecated Cocoa methods

[Clifford Y. <cli...@gm...>]

On Thu, Sep 27, 2012 at 2:42 PM, Torsten Berg <re...@ma...> wrote:

> What is the feeling in the Tcl community? Should we keep using deprecated methods until
> Apple removes them or should we actively try to maintain the code and update these
> methods when such issues are emerging?

Personally my opinion would be to start working on removing deprecated
calls as soon as they are deprecated  (or if not removing them,
conditionalizing them to be used only on earlier releases where that's
the only option) - there could be non-trivial issues to figure out and
that way Tcl/Tk doesn't get caught with an unsupported Mac OSX
release.

CY

[MACTCL] Deprecated Cocoa methods

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

Hi,

I had a look into the code for the dialogs on the Mac (tkMacOSXDialog.c) and found a Cocoa method there that has been marked deprecated by Apple for OS X 10.6. It is the method 'runModalForDirectory' that is used e.g. in the code for tk_getOpenFile:

http://developer.apple.com/library/mac/#documentation/cocoa/reference/ApplicationKit/Classes/NSOpenPanel_Class/DeprecationAppendix/AppendixADeprecatedAPI.html

Apple says, the method 'runModal' should be used instead. This is a method that existed since Mac OS X 10.0 and as such would not cause any trouble with Tk-Cocoa running on older versions of OS X.

What is the feeling in the Tcl community? Should we keep using deprecated methods until Apple removes them or should we actively try to maintain the code and update these methods when such issues are emerging?

I haven't looked if there are other methods in this category, but there might well be more.

Regards, Torsten

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

[Peter C. <pc...@wo...>]

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.