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

Re: [MACTCL] Commits to improve drawing in Tk-Cocoa after removal of private API's

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

Dear Lars,

> % after 500 {incr epoch}; vwait epoch; set epoch

Thank you for pointing that out: I have after commands being executed
during vwaits myself, so I was mistaken about them.

> and also like you're using far-from-recommended programming 
> practices.

I have done very well using far from recommended practices.

> [vwait]s are resolved in reverse order of initialisation, because 
> each is a recursive invokation of the event loop.

And why would a vwait give rise to a recursive invokation of the event
loop, when it could simply pass control to a pre-existing event loop?
Having one event loop keeping track of all vwaits and afters and
call-backs would, in my estimation, be far easier to write. And indeed,
I have written such things for embedded systems and been delighted by
how well they perform.

> The first advice on using [vwait] tends to be to avoid that.

Do you mean avoid using vwaits all-together? I guess that is what I have
done, but it seems a pity.

Yours, Kevan

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

Re: [MACTCL] [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's

[Lars H. <Lar...@re...>]

Kevan Hashemi skrev 2014-09-25 16.17:
> Dear Kevin,
>
> Thank you for all the work you are doing to keep Tk going on MacOS.
>
>> Re-engineering either of these foundational parts of Tcl would, as I
>> understand it, go far beyond adjusting a platform-specific
>> implementation of the current API
>
> Indeed it would. But the Tcl event loop has one severe limitation, and I
> believe it's the one Michiel is referring to. I had to build my own
> event loop on top of Tcl's, because Tcl's would not do the job.
>
> The problem with Tcl's event loop is that pending "vwaits" are resolved
> strictly in reverse order of initiation, and "after" events are ignored
> during an active vwait.

That sounds very much like a misunderstanding, and also like you're using 
far-from-recommended programming practices.

[vwait]s are resolved in reverse order of initialisation, because each is a 
recursive invokation of the event loop. The first advice on using [vwait] 
tends to be to avoid that. And [after] events are being serviced during a 
[vwait], since how else could the following terminate?

% after 500 {incr epoch}; vwait epoch; set epoch
1
% after 500 {incr epoch}; vwait epoch; set epoch
2

Your premises appear to be flawed.


Lars Hellström

Re: [MACTCL] [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's

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

Dear Kevin,

> Are these issues specific to Tcl/Tk on the Mac, or to Tcl itself? 

They are core issues with Tcl itself, on all platforms, and they are 
intentional. But the main event loop does perform graphics updates more 
agressively than "vwait" and "after", and Michiel informs me that there 
is a separate graphics event loop in tkMacOSXNotifer.c and 
tclMacOSXNotifier.c, which you say was designed by Daniel Steffen. So I 
doubt very much that this graphics event loop is plagued by the same 
limitation as the Tcl core event loop.

Nevertheless, when a 2 GHz dual-core machine cannot draw windows fast 
enough, my guess is that something dysfunctional is going on in the 
communication with the OS. That's quite apart from the problem of the 
drawing being correct once it is complete. You say that the private APIs 
had fixed these problems, which suggests that the problems were not with 
the fundamentals of tkMacOSXNotifer.c and tclMacOSXNotifier.c.

Are there places in the new API-free implementation where one large 
action has been broken into a large number of smaller actions?

Yours, Kevan


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

Re: [MACTCL] [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's

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

Dear Kevin,

Thank you for all the work you are doing to keep Tk going on MacOS.

> Re-engineering either of these foundational parts of Tcl would, as I 
> understand it, go far beyond adjusting a platform-specific 
> implementation of the current API

Indeed it would. But the Tcl event loop has one severe limitation, and I 
believe it's the one Michiel is referring to. I had to build my own 
event loop on top of Tcl's, because Tcl's would not do the job.

The problem with Tcl's event loop is that pending "vwaits" are resolved 
strictly in reverse order of initiation, and "after" events are ignored 
during an active vwait.

Suppose I am capturing images from a server on the Internet as fast as I 
can. As soon as one comes in, I post and "after" event to the Tcl event 
loop. While waiting for each image to arrive, Tcl is in its vwait state, 
servicing call-backs, but not  "after" events, nor will it do anything 
about other "vwaits" that have terminated. If, during this thge image 
capture vwait, I happen to press a button on another window that asks 
for the temperature of the camera, this other data acquisition process 
begins, but it cannot terminate because the server is busy capturing an 
image. So it vwaits. But of course the original image capture is what's 
holding things up, and that won't terminate until this vwait has 
terminated, which won't happen until it itself has terminated. So we're 
stuck.

There's a name to this kind of stoppage, but I can't remember what it is.

All the event loop has to do is return control to whatever vwait or 
after event occurs first, and all will be well. There are problems 
associated with such an open-ended event loop, but they are handled with 
a little discipline, and the resulting structure is far more versatile 
and efficient.

If Tcl has to "vwait" for Cocoa, and Cocoa is assuming that many 
requests for action come in at the same time, then I can see that the 
interaction between Tcl and Cocoa cannot work within the Tcl event loop.

 > I find it hard to imagine that there would be
> much support for changing the event loop (this would require a large 
> effort across every platform)

I have written several event loops in my time, one of them in assembler. 
They are not complicated compared to the kind of detailed graphics code 
you have been working on. But I agree that there is no chance of the Tcl 
core team changing the way the event loop is done. I am sure they have 
many reasons to prefer the strict reverse-order vwait system, although I 
can't tell you what those reasons might be.

Is it possible to build your own graphics event loop with which to 
interact with Cocoa? I of course speak from a position of near-complete 
ignorance of the problems you are faced with, so forgive me if I have 
wasted your time.

Yours, Kevan

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

Re: [MACTCL] [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's

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

On 9/25/14, 10:21 AM, Michiel de Hoon wrote:
> The only changes would be needed in tclMacOSXNotify.c and in tkMacOSX*.c (mainly tkMacOSXNotify.c).
> Regarding threading: I think we agree there. I am suggesting to use the event loop instead of a thread to monitor file descriptor events.

I'd be interested to hear your suggestions for tkMaCOSXNotify.c. My 
understanding is that this is mainly a hook into tclMacOSXNotifier.c, 
which is quite complex.

Anything involving threading is currently outside my skill set, so I 
will defer to those more expert than myself on this.

--Kevin

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

Re: [MACTCL] [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's

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

Hi Kevan,

On 9/25/14, 10:17 AM, Kevan Hashemi wrote:
> Dear Kevin,
>
> Thank you for all the work you are doing to keep Tk going on MacOS.
>
>> Re-engineering either of these foundational parts of Tcl would, as I
>> understand it, go far beyond adjusting a platform-specific
>> implementation of the current API
>
> Indeed it would. But the Tcl event loop has one severe limitation, and I
> believe it's the one Michiel is referring to. I had to build my own
> event loop on top of Tcl's, because Tcl's would not do the job.
>
> The problem with Tcl's event loop is that pending "vwaits" are resolved
> strictly in reverse order of initiation, and "after" events are ignored
> during an active vwait.
>
Are these issues specific to Tcl/Tk on the Mac, or to Tcl itself? The 
former perhaps can be addressed, but the latter is an architectural 
issue that is above my pay grade.

> Is it possible to build your own graphics event loop with which to
> interact with Cocoa? I of course speak from a position of near-complete
> ignorance of the problems you are faced with, so forgive me if I have
> wasted your time.

The relevant code is in tkMacOSXNotifer.c (which integrates Tk and 
Cocoa) and more foundationally in tclMacOSXNotifier.c (which provides 
the Mac-specific implementation of the event loop).

The notifier under Cocoa seems a lot more complex than Carbon. According 
to Daniel Steffen, it switches between an embedded and an external 
notifier. If a simpler notifier can be built, I have no idea. I'm 
assuming no, because much smarter people than myself (Daniel Steffen in 
particular) came up with the current implementation.

--Kevin


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

Re: [MACTCL] [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's

[Michiel de H. <mjl...@ya...>]

Hi Kevin,

I am not suggesting changing any features of Tcl or Tk itself.
The only changes would be needed in tclMacOSXNotify.c and in tkMacOSX*.c (mainly tkMacOSXNotify.c). 
Regarding threading: I think we agree there. I am suggesting to use the event loop instead of a thread to monitor file descriptor events.

Best,
-Michiel.

--------------------------------------------
On Thu, 9/25/14, Kevin Walzer <kw...@co...> wrote:

 Subject: Re: [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of	private API's
 To: "Michiel de Hoon" <mjl...@ya...>, "tc...@li... List" <tc...@li...>, "Tcl Core List" <tcl...@li...>
 Date: Thursday, September 25, 2014, 10:34 PM
 
 Hello Michiel,
 
 Thank you for your feedback. I
 am certainly happy to hear your thoughts 
 about further improving Tk-Cocoa, but I did
 need to touch on a couple of 
 things
 immediately:
 
 > 1) In Tk,
 the design of the event loop (in particular, processing
 events in the event loop rather than in the callbacks);
 
 Tk is building on Tcl's
 event loop, which is a core feature of the language.
 
 > 2) In Tcl, the use of a
 separate thread to monitor file descriptor events.
 
 Tcl supports but does not
 require threading, and in fact threading is 
 often unnecessary because of the event loop.
 
 Re-engineering either of these
 foundational parts of Tcl would, as I 
 understand it, go far beyond adjusting a
 platform-specific 
 implementation of the
 current API (which is what I have been working 
 on). While I'm not a member of the TCT
 (Tcl's core governing committee) 
 and
 can't speak for them, I find it hard to imagine that
 there would be 
 much support for changing
 the event loop (this would require a large 
 effort across every platform) or for adding
 threading as a required 
 component.
 
 Tcl's inventor, John
 Osterhout, argued that threads are a bad idea in 
 most instances because of their complexity, and
 advocated event loops:
 
 http://www.cs.utah.edu/~regehr/research/ouster.pdf
 
 I realize that threads are
 very commonly used today, and are a standard 
 part of the Cocoa programmer's toolkit, but
 some increasingly prominent 
 software
 projects (cf. node.js)  are discovering what Tcl has known
 for 
 two decades: event loops are powerful.
 I have only done a little 
 threaded
 programming myself, and have generally avoided it because
 Tcl's 
 event loop makes it unnecessary
 for my needs.
 
 Just a few
 ideas to consider. Looking forward to your thoughts.
 
 Thanks,
 Kevin
 
 -- 
 Kevin
 Walzer
 Code by Kevin/Mobile Code by Kevin
 http://www.codebykevin.com
 http://www.wtmobilesoftware.com
 

Re: [MACTCL] [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's

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

Hello Michiel,

Thank you for your feedback. I am certainly happy to hear your thoughts 
about further improving Tk-Cocoa, but I did need to touch on a couple of 
things immediately:

> 1) In Tk, the design of the event loop (in particular, processing events in the event loop rather than in the callbacks);

Tk is building on Tcl's event loop, which is a core feature of the language.

> 2) In Tcl, the use of a separate thread to monitor file descriptor events.

Tcl supports but does not require threading, and in fact threading is 
often unnecessary because of the event loop.

Re-engineering either of these foundational parts of Tcl would, as I 
understand it, go far beyond adjusting a platform-specific 
implementation of the current API (which is what I have been working 
on). While I'm not a member of the TCT (Tcl's core governing committee) 
and can't speak for them, I find it hard to imagine that there would be 
much support for changing the event loop (this would require a large 
effort across every platform) or for adding threading as a required 
component.

Tcl's inventor, John Osterhout, argued that threads are a bad idea in 
most instances because of their complexity, and advocated event loops:

http://www.cs.utah.edu/~regehr/research/ouster.pdf

I realize that threads are very commonly used today, and are a standard 
part of the Cocoa programmer's toolkit, but some increasingly prominent 
software projects (cf. node.js)  are discovering what Tcl has known for 
two decades: event loops are powerful. I have only done a little 
threaded programming myself, and have generally avoided it because Tcl's 
event loop makes it unnecessary for my needs.

Just a few ideas to consider. Looking forward to your thoughts.

Thanks,
Kevin

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

Re: [MACTCL] [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's

[Michiel de H. <mjl...@ya...>]

Hi Kevin,

First of all, great to hear that you have been working on the Tk-Cocoa code.

I am not surprised though that the performance after removing the private API's is less than ideal.
Previously I looked in detail at the Tk and Tcl code for Mac. It seems that this code (as you suggest) stays close to the Unix/X11 origins, and doesn't always follow the design principles one would follow for a Cocoa program written from scratch.

The two biggest issues I see are:
1) In Tk, the design of the event loop (in particular, processing events in the event loop rather than in the callbacks);
2) In Tcl, the use of a separate thread to monitor file descriptor events.

Once these two fundamental issues are fixed, you may find that you get good performance without having to use the private API's. If you are interested, let me know and we can talk about the details.

Thanks,
-Michiel.


--------------------------------------------
On Thu, 9/25/14, Kevin Walzer <kw...@co...> wrote:

 Subject: [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of	private API's
 To: "tc...@li... List" <tc...@li...>, "Tcl Core List" <tcl...@li...>
 Date: Thursday, September 25, 2014, 9:50 AM
 
 Hello all,
 
 I've done another round of commits this week in Tk-Cocoa to
 improve its 
 drawing performance after the removal of the private Cocoa
 NSView API's.
 
 I must be candid: removing the private API's did result in a
 degradation 
 of Tk's drawing performance under Cocoa. Rendering that was
 snappy and 
 accurate became glitchy, slow, and laggy, with weird
 artifacts like 
 buttons scrolling outside their container window and
 scrollbars 
 appearing in two different places when a window was
 remapped. Sometimes 
 widgets would not remap after a window resized, and in a few
 instances 
 too much resizing would cause a crash.
 
 The last few commits, with some input from Marc Culler, have
 attempted 
 to address the worst of these issues. The button and
 scrollbar issues 
 have been fixed, and some improvement in rendering with
 window resizing 
 and resizing of child windows is now in place. For instance,
 I've added 
 some code to skip over some drawing operations in window
 resizing, which 
 has smoothed things out a bit. Basic user interfaces, such
 as the ones 
 in the Tk demo, render very well with little discernible
 loss of 
 performance. Stability seems fine.
 
 There is still some laggy drawing in more complex
 interfaces, such as 
 ones using paned windows and megawidgets like tablelist. An
 especially 
 heavy-duty app such as TkDiff, which uses a lot of CPU
 resources to 
 implement custom synced scrolling between two windows, is
 now pretty 
 much unusable. This is unavoidable, but unfortunate.
 
 I've spent a lot of hours over the past few weeks becoming
 acquainted 
 with Tk-Cocoa's drawing code, and I regret that I can't
 wring out much 
 more improvement here. Those private API's are undocumented
 and I don't 
 fully understand how they worked or what they actually did,
 but they did 
 add a lot of low-level magic to drawing Tk widgets. If
 getting the best 
 performance for graphic rendering is the goal, including
 those bits is 
 absolutely the right call, and I fully understand why Daniel
 Steffen 
 included them. If an Apple-sponsored open-source project
 (WebKit) 
 includes this code, then it's entirely reasonable for
 another 
 Apple-sponsored open-source project (Tk-Cocoa) to follow
 suit.
 
  From a policy standpoint, however, any such inclusion of
 private API's 
 is problematic, especially if Apple changes them under the
 hood, or if 
 Apple enforces restrictions against the use of such API's on
 their 
 platform by third-party projects. Apple has certainly been
 doing the 
 latter. No third-party developer can submit any bundled
 WebKit code to 
 the Mac App Store because of its use of private API's--you
 are limited 
 to linking to the system installation of WebKit. This
 precludes a lot of 
 apps that use WebKit, such as Qt and its QtWebKit module,
 from the Mac 
 App Store. I have also run into this issue with my own
 commercial apps 
 that include Tk. The workaround is to link to the
 system-installed 
 Tcl/Tk frameworks, which on my machine are ancient (8.5.9).
 This is also 
 an inherently fragile solution, because if Apple decided to
 stop 
 bundling Tcl/Tk on OS X, this would greatly limit deployment
 of any app 
 using Tk on the Mac.
 
 The absurdity of Apple's position is quite clear here, but I
 don't feel 
 it can be safely ignored. Apple has greatly benefited our
 community by 
 sponsoring the Cocoa port of Tk--I doubt it would have been
 written 
 otherwise--so I'm not inclined to be too critical of Apple
 in this 
 context.  Part of the reason for the mismatch between
 Tk and Cocoa is 
 that Tk has never really shed its roots in Unix and X11
 assumptions. 
 That graphic model happened to be a good fit for Carbon, as
 it is for 
 Win32, but it's a poor fit for Cocoa. Re-working Tk's
 25-year-old 
 architecture isn't likely to happen, so we have to make the
 best with 
 what we have. Removing the private API's is a necessary, but
 
 unpalatable, compromise for the platform's requirements, one
 somewhat 
 mitigated by the last few rounds of commits.
 
 For those who have read this far, thanks for your continued
 support, and 
 my apologies that we cannot do much better than the current
 state of 
 affairs. As always, I welcome your feedback, and just as
 importantly, 
 your code contributions--Marc Culler's patches have been
 hugely 
 important in the recent improvements I've been able to
 commit.
 
 Thanks,
 Kevin
 
 -- 
 Kevin Walzer
 Code by Kevin/Mobile Code by Kevin
 http://www.codebykevin.com
 http://www.wtmobilesoftware.com
 
 ------------------------------------------------------------------------------
 Meet PCI DSS 3.0 Compliance Requirements with EventLog
 Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI
 DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download
 White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog
 Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
 _______________________________________________
 Tcl-Core mailing list
 Tcl...@li...
 https://lists.sourceforge.net/lists/listinfo/tcl-core
 

Re: [MACTCL] Commits to improve drawing in Tk-Cocoa after removal of private API's

[David Z. <kr...@kr...>]

Hi Kevin,

As an extensive Mac Tk user I want to thank you for all the job you've already made and I'll try not to forget to thank you for the future time you'll spend to make Tk available on OS X.

I'm not a native english so I might not use the good words but I hope you take the feeling.

Kind regards,

-- 
👤 David Zolli
📧 kr...@kr...

[MACTCL] Commits to improve drawing in Tk-Cocoa after removal of private API's

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

Hello all,

I've done another round of commits this week in Tk-Cocoa to improve its 
drawing performance after the removal of the private Cocoa NSView API's.

I must be candid: removing the private API's did result in a degradation 
of Tk's drawing performance under Cocoa. Rendering that was snappy and 
accurate became glitchy, slow, and laggy, with weird artifacts like 
buttons scrolling outside their container window and scrollbars 
appearing in two different places when a window was remapped. Sometimes 
widgets would not remap after a window resized, and in a few instances 
too much resizing would cause a crash.

The last few commits, with some input from Marc Culler, have attempted 
to address the worst of these issues. The button and scrollbar issues 
have been fixed, and some improvement in rendering with window resizing 
and resizing of child windows is now in place. For instance, I've added 
some code to skip over some drawing operations in window resizing, which 
has smoothed things out a bit. Basic user interfaces, such as the ones 
in the Tk demo, render very well with little discernible loss of 
performance. Stability seems fine.

There is still some laggy drawing in more complex interfaces, such as 
ones using paned windows and megawidgets like tablelist. An especially 
heavy-duty app such as TkDiff, which uses a lot of CPU resources to 
implement custom synced scrolling between two windows, is now pretty 
much unusable. This is unavoidable, but unfortunate.

I've spent a lot of hours over the past few weeks becoming acquainted 
with Tk-Cocoa's drawing code, and I regret that I can't wring out much 
more improvement here. Those private API's are undocumented and I don't 
fully understand how they worked or what they actually did, but they did 
add a lot of low-level magic to drawing Tk widgets. If getting the best 
performance for graphic rendering is the goal, including those bits is 
absolutely the right call, and I fully understand why Daniel Steffen 
included them. If an Apple-sponsored open-source project (WebKit) 
includes this code, then it's entirely reasonable for another 
Apple-sponsored open-source project (Tk-Cocoa) to follow suit.

 From a policy standpoint, however, any such inclusion of private API's 
is problematic, especially if Apple changes them under the hood, or if 
Apple enforces restrictions against the use of such API's on their 
platform by third-party projects. Apple has certainly been doing the 
latter. No third-party developer can submit any bundled WebKit code to 
the Mac App Store because of its use of private API's--you are limited 
to linking to the system installation of WebKit. This precludes a lot of 
apps that use WebKit, such as Qt and its QtWebKit module, from the Mac 
App Store. I have also run into this issue with my own commercial apps 
that include Tk. The workaround is to link to the system-installed 
Tcl/Tk frameworks, which on my machine are ancient (8.5.9). This is also 
an inherently fragile solution, because if Apple decided to stop 
bundling Tcl/Tk on OS X, this would greatly limit deployment of any app 
using Tk on the Mac.

The absurdity of Apple's position is quite clear here, but I don't feel 
it can be safely ignored. Apple has greatly benefited our community by 
sponsoring the Cocoa port of Tk--I doubt it would have been written 
otherwise--so I'm not inclined to be too critical of Apple in this 
context.  Part of the reason for the mismatch between Tk and Cocoa is 
that Tk has never really shed its roots in Unix and X11 assumptions. 
That graphic model happened to be a good fit for Carbon, as it is for 
Win32, but it's a poor fit for Cocoa. Re-working Tk's 25-year-old 
architecture isn't likely to happen, so we have to make the best with 
what we have. Removing the private API's is a necessary, but 
unpalatable, compromise for the platform's requirements, one somewhat 
mitigated by the last few rounds of commits.

For those who have read this far, thanks for your continued support, and 
my apologies that we cannot do much better than the current state of 
affairs. As always, I welcome your feedback, and just as importantly, 
your code contributions--Marc Culler's patches have been hugely 
important in the recent improvements I've been able to commit.

Thanks,
Kevin

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

Re: [MACTCL] Wish8.6 crashes on Mavericks

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

Peter,

On 9/20/14, 12:33 PM, Peter Caffin wrote:
> Hi guys.
>
> This is the error:
>
> Peters-MacBook-Pro:~ pc$ /usr/local/bin/wish8.6
>
> CGColor with 1 components
>
> /usr/local/bin/wish8.6: line 2: 10500 Abort trap: 6           "$(dirname
> $0)/../../../Library/Frameworks/Tk.framework/Versions/8.6/Resources/Wish.app/Contents/MacOS/Wish"
> "$@"
>
> I was getting the same error with the existing ActiveTcl 8.5
> installation I had, so I upgraded to ActiveTcl 8.6, hoping it might have
> been resolved there.
>

Can you provide a backtrace/crash report? Look in Console.app. That 
would help.

We've been getting some reports of random crashes of Tk/Mac, but not 
anything that can be reproduced consistently.

--Kevin


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

[MACTCL] Wish8.6 crashes on Mavericks

[Peter C. <pe...@ca...>]

Hi guys.

This is the error:

Peters-MacBook-Pro:~ pc$ /usr/local/bin/wish8.6

CGColor with 1 components

/usr/local/bin/wish8.6: line 2: 10500 Abort trap: 6           "$(dirname 
$0)/../../../Library/Frameworks/Tk.framework/Versions/8.6/Resources/Wish.app/Contents/MacOS/Wish" 
"$@"

I was getting the same error with the existing ActiveTcl 8.5 
installation I had, so I upgraded to ActiveTcl 8.6, hoping it might have 
been resolved there.

Any suggestions?

Thanks.

Re: [MACTCL] Minimise Wish with double-click in title bar (Carbon)

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

On 9/16/14, 8:11 AM, Steve A wrote:
> Does anyone know of a hack to make this work in Carbon ?
> Please dont say use Cocoa. It is broken:(.

Let's define "broken."

There's no way, as far as I know, to make this work under Carbon. So it 
doesn't support your desired functionality. Isn't that a form of "broken"?

The Carbon version of Tk won't even build anymore on recent versions of 
OS X (10.8, 10.9). As a result, it's virtually impossible to patch, 
forcing you to use old binaries that will never be changed or improved. 
Isn't that a form of "broken"?

Carbon did have the virtue of running a bit faster and smoother in terms 
of event processing and drawing than Cocoa, at one point in the past. 
We've done a lot of commits to improve Cocoa this year, especially with 
regard to image rendering, drawing of buttons, and scrolling of text and 
canvases with embedded windows. It's still not perfect but much 
improved. One of the apps I used to exercise the changes was Scid, 
which, given its UI complexity, is excellent for these purposes.

Cocoa builds just fine, and is under active development, and is 
improving all the time, and I'm gratefully accepting patches from anyone 
who wants to dive in and work on something specific. Marc Culler has 
submitted several patches this year to improve drawing and scrolling in 
Tk-Cocoa, and he's responsible for most of the good new stuff in the 
library. Adrian Robert has submitted helpful patches in the past for 
input methods for non-English languages, as well. You're welcome to join 
the effort.

IMO, an actively developed toolkit that is improving all the time *by 
definition* isn't broken. Sticking with an obsolete toolkit that is 
effectively frozen in 2007 and won't even build anymore on the current 
OS is the very definition of broken.

So, to circle back to your question: Use Cocoa.

--Kevin

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

[MACTCL] Minimise Wish with double-click in title bar (Carbon)

[Steve A <ste...@gm...>]

Does anyone know of a hack to make this work in Carbon ?
Please dont say use Cocoa. It is broken :(.

thanks, Steven

[MACTCL] Minimise Wish with double-click in title bar (Carbon)

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

Does anyone know of a hack to make this work in Carbon ?
(Please dont say use Cocoa. It is broken).

thanks, Steven

[MACTCL] My open-source Tcl/Tk packages

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

Hi all,

It has occurred to me that many folks may not be aware of all the 
open-source packages for Mac OS X that I've developed: I had lost track 
of them myself, to be honest. :-) All of them are ones I've used in my 
own apps at one point or another, mostly (but not always) to improve the 
integration of my apps with OS X, and many are still currently in use. I 
wanted just to provide a brief reference to the packages' landing pages, 
as well as a few other resources for optimizing Tk apps for OS X.

The main site is http://opensource.codebykevin.com.

Mac-native, Cocoa-based Tk extensions for OS X: 
http://opensource.codebykevin.com/native.html

This is the richest resource. At this page I have native, i.e. requiring 
compilation, compilations for integrating with various aspects of Mac 
apps: printing, sheet and drawer windows, Quicklook, the Growl 
notification system, the Dock and dock icons, native toolbars, the Cocoa 
Services API, the native fullscreen API, and more. These are packages 
that I have previously or currently use actively, and am willing to 
support in terms of documentation and updates. (I have a few other 
packages in SVN at SourceForge that, while open-source, would be 
essentially unsupported.)

Open-source script packages to improve the look and feel of Tk apps on 
the Mac: http://opensource.codebykevin.com/oss.html

These provide various script-level packages for optimizing Mac apps; 
some are convenience wrappers for core Tk functions, such as 
implementing a "window" menu, and others are essentially canned packages 
of configuration options to make Tk apps look a bit more native.

In addition to the code, I also have some useful documentation:

Tutorial on packaging Tcl/Tk applications on OS X: 
http://opensource.codebykevin.com/tutorial.html

An overview of a few different options to deploy a Tcl/Tk app on the 
Mac, including starpacks and native app bundles.

Tutorial on preparing Tcl/Tk apps for the Mac App Store: 
http://opensource.codebykevin.com/app-store.html

An overview of deploying commercial and OSS Tcl/Tk apps in the Mac App 
Store.

I hope these are useful to folks. Let me know if you have questions or 
comments!

Best,
Kevin

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

[MACTCL] Progressdock and Tkmacicon packages for Tk-Mac

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

Hi all,

I've released version 1.2 of my tkmacicon package for Tcl/Tk on Mac OS X.

The tkmacicon package provides the data necessary to platform-native 
icons on OS X as Tk images. The ::tkmacicon::geticonfrompath command 
takes three arguments: a file path, width, and height. The 
::tkmacicon::geticonfromtype command takes three arguments: a file 
extension, width, and height. These commands provide the raw image data 
necessary to render a Mac icon as a native Tk image.

This release represents a significant API change from earlier versions, 
which wrote the image data to a PNG file and then read the file into a 
Tk image. Obtaining the data without the overhead of file writes and 
reads makes the package significantly faster.

For more information, see 
http://opensource.codebykevin.com/native.html#tkmacicon.

****

Also, I've released version 1.0 of my progressdock package for Tk on Mac 
OS X.

The progressdock package draws a nice progress bar over a Tk/Mac 
application's Dock icon. It is especially useful for showing 
download/uploads, and similar activities. The package is based on the 
UKDockProgressIndicator class by Uli Kusterer.

For more information on the progressdock package, see 
http://opensource.codebykevin.com/native.html#progressdock.

Hope these are useful.

Enjoy,
Kevin

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

[MACTCL] Problems building tktreectrl-2.4.1

[Michael M. <mur...@gm...>]

Greetings

I am trying to build the extension tktreectrl-2.4.1 so I can call it from python. It took me awhile to sort out versions, but I think the version I want is under /anaconda

./configure --with-tk=/anaconda/pkgs/tk-8.5.13-1/lib --with-tcl=/anaconda/pkgs/tk-8.5.13-1/lib

it finds tkConfig.sh and tclConfig.sh

Michaels-MacBook-Pro:tktreectrl-2.4.1 mmuratet$ ./configure --with-tk=/anaconda/pkgs/tk-8.5.13-1/lib --with-tcl=/anaconda/pkgs/tk-8.5.13-1/lib
checking for correct TEA configuration... ok (TEA 3.9)
configure: configuring treectrl 2.4
checking for Tcl configuration... found /anaconda/pkgs/tk-8.5.13-1/lib/tclConfig.sh
checking for existence of /anaconda/pkgs/tk-8.5.13-1/lib/tclConfig.sh... loading
checking for Tk configuration... found /anaconda/pkgs/tk-8.5.13-1/lib/tkConfig.sh
checking for existence of /anaconda/pkgs/tk-8.5.13-1/lib/tkConfig.sh... loading
configure: --prefix defaulting to TCL_PREFIX /opt/anaconda1anaconda2anaconda3
configure: --exec-prefix defaulting to TCL_EXEC_PREFIX /opt/anaconda1anaconda2anaconda3
checking for a BSD-compatible install... /usr/bin/install -c
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking whether make sets $(MAKE)... yes
checking for ranlib... ranlib
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking if the compiler understands -pipe... yes
checking whether byte ordering is bigendian... no
checking for sin... yes
checking for main in -lieee... no
checking for main in -linet... no
checking net/errno.h usability... no
checking net/errno.h presence... no
checking for net/errno.h... no
checking for connect... yes
checking for gethostbyname... yes
checking dirent.h... yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking float.h usability... yes
checking float.h presence... yes
checking for float.h... yes
checking values.h usability... no
checking values.h presence... no
checking for values.h... no
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking sys/wait.h usability... yes
checking sys/wait.h presence... yes
checking for sys/wait.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking for Tcl public headers... /anaconda/pkgs/tk-8.5.13-1/lib/../include
checking for Tcl private include files... Using -I"-------src-dir--------/tcl8.5.13/generic" -I"-------src-dir--------/tcl8.5.13/unix"
checking for Tk public headers... /anaconda/pkgs/tk-8.5.13-1/lib/../include
checking for Tk private include files... Using -I"-------src-dir--------/tk8.5.13/generic" -I"-------src-dir--------/tk8.5.13/unix"
checking for X... libraries /usr/X11/lib, headers 
checking for X11 header files... checking whether byte ordering is bigendian... (cached) no
checking for intptr_t... yes
checking for pthread_mutex_init in -lpthread... yes
checking for building with threads... yes (default)
configure: WARNING:
    --enable-threads requested, but building against a Tcl that is NOT
    thread-enabled.  This is an OK configuration that will also run in
    a thread-enabled core.
checking how to build libraries... shared
checking if 64bit support is requested... no
checking if 64bit Sparc VIS support is requested... no
checking if compiler supports visibility "hidden"... yes
checking if rpath support is requested... yes
checking system version... Darwin-11.4.2
checking for ar... ar
checking if ld accepts -single_module flag... yes
checking if ld accepts -search_paths_first flag... yes
checking for required early compiler flags... none
checking for 64-bit integer type... using long
checking for build with symbols... no
checking for tclsh... /anaconda/pkgs/tk-8.5.13-1/bin/tclsh8.5
checking for wish... /anaconda/pkgs/tk-8.5.13-1/bin/wish8.5
configure: creating ./config.status
config.status: creating Makefile

But make fails

Michaels-MacBook-Pro:tktreectrl-2.4.1 mmuratet$ sudo make
Password:
gcc -DPACKAGE_NAME=\"treectrl\" -DPACKAGE_TARNAME=\"treectrl\" -DPACKAGE_VERSION=\"2.4\" -DPACKAGE_STRING=\"treectrl\ 2.4\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE_PATCHLEVEL=\"2.4.1\" -DBUILD_treectrl=/\*\*/ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_INTPTR_T=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1  -I. -I"./generic" -I"-------src-dir--------/tcl8.5.13/generic" -I"-------src-dir--------/tcl8.5.13/unix" -I"-------src-dir--------/tk8.5.13/generic" -I"-------src-dir--------/tk8.5.13/unix"     -pipe  -Os -Wall -fno-common   -c `echo ./generic/qebind.c` -o qebind.o
gcc -DPACKAGE_NAME=\"treectrl\" -DPACKAGE_TARNAME=\"treectrl\" -DPACKAGE_VERSION=\"2.4\" -DPACKAGE_STRING=\"treectrl\ 2.4\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE_PATCHLEVEL=\"2.4.1\" -DBUILD_treectrl=/\*\*/ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_INTPTR_T=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1  -I. -I"./generic" -I"-------src-dir--------/tcl8.5.13/generic" -I"-------src-dir--------/tcl8.5.13/unix" -I"-------src-dir--------/tk8.5.13/generic" -I"-------src-dir--------/tk8.5.13/unix"     -pipe  -Os -Wall -fno-common   -c `echo ./generic/tkTreeColumn.c` -o tkTreeColumn.o
In file included from ./generic/tkTreeColumn.c:11:0:
./generic/tkTreeCtrl.h:11:20: fatal error: tkPort.h: No such file or directory
compilation terminated.
make: *** [tkTreeColumn.o] Error 1

I'm not sure where to go from here. If tkConfig.sh and tclConfig.sh don't know where the headers are, where would you look for headers?

I've never seen configure generate include paths with a lot of hyphens. Is that coming from tkConf.sh or tclConf.sh?

Thanks

Mike

Re: [MACTCL] Tk 8.6.2 blocking failure on Mac OSX

[Donald G P. <don...@ni...>]

On 08/27/2014 07:55 AM, Donald G Porter wrote:
> The following simple script segfaults in Tk 8.6.2 on Mac OSX:
...
> What are the prospects for correcting this failure in a short period
> of time?

Apparently pretty good, as Kevin Walzer has provided the one-liner fix.

Thanks!

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

[MACTCL] Tk 8.6.2 blocking failure on Mac OSX

[Donald G P. <don...@ni...>]

The following simple script segfaults in Tk 8.6.2 on Mac OSX:

button .b
pack .b
update
destroy .b
button .c
update

It appears that the cause of this critical regression is the
recent checkin

http://core.tcl.tk/tk/info/a8d82409cd

I do not believe Tk 8.6.2 can be released in this condition.

What are the prospects for correcting this failure in a short period
of time?

If we do not have hope for that, what are the consequences of backing
out that checkin?

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

[MACTCL] 2nd Call For Papers, 21th Annual Tcl/Tk Conference 2014

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

21'th Annual Tcl/Tk Conference (Tcl'2014)
http://www.tcl.tk/community/tcl2014/

[ It is 4 weeks to the deadline for Abstracts and proposals ... ]

November 10 - 14, 2014
Embassy Suites Downtown
Portland, Oregon, USA

Important Dates:

Abstracts and proposals due     Sep  8, 2014
Notification to authors         Sep 22, 2014
Author materials due            Oct 20, 2014
Tutorials start                 Nov 10, 2014
Conference starts               Nov 12, 2014

[[ 
        Registration is open.
]]

Email Contact:                tcl...@go...

Submission of Summaries

Tcl/Tk 2014 will be held in Portland, Oregon, USA from November
10 - 14, 2014. The program committee is asking for papers and
presentation proposals from anyone using or developing with Tcl/Tk
(and extensions). Past conferences have seen submissions covering a
wide variety of topics including:

* Scientific and engineering applications
* Industrial controls
* Distributed applications and Network Managment
* Object oriented extensions to Tcl/Tk
* New widgets for Tk
* Simulation and application steering with Tcl/Tk
* Tcl/Tk-centric operating environments
* Tcl/Tk on small and embedded devices
* Medical applications and visualization
* Use of different programming paradigms in Tcl/Tk and proposals for new
  directions.
* New areas of exploration for the Tcl/Tk language

Submissions should consist of an abstract of about 100 words and a
summary of not more than two pages, and should be sent as plain text
to <tclconference AT googlegroups DOT com> no later than August 5,
2014. Authors of accepted abstracts will have until September 2, 2014
to submit their final paper for the inclusion in the conference
proceedings. The proceedings will be made available on digital media,
so extra materials such as presentation slides, code examples, code
for extensions etc. are encouraged.

Printed proceedings will be produced as an on-demand book at lulu.com

The authors will have 25 minutes to present their paper at the
conference.

The program committee will review and evaluate papers according to the
following criteria:

* Quantity and quality of novel content
* Relevance and interest to the Tcl/Tk community
* Suitability of content for presentation at the conference

Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.

Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application. Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.

Papers accompanied by non-disclosure agreements will be returned to
the author(s) unread. All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.

The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.

Other Forms of Participation

The program committee also welcomes proposals for panel discussions of
up to 90 minutes. Proposals should include a list of confirmed
panelists, a title and format, and a panel description with position
statements from each panelist. Panels should have no more than four
speakers, including the panel moderator, and should allow time for
substantial interaction with attendees. Panels are not presentations
of related research papers.

Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather
sessions (BOFs) are available on a first-come, first-served basis.
WIP slots can be reserved like any paper proposal. BOF slots will be
managed on-site. All attendees with an interesting work in progress
should consider reserving a WIP slot.

Registration Information

More information on the conference is available the conference Web
site (http://www.tcl.tk/community/tcl2014/) and will be published on
various Tcl/Tk-related information channels.

        Registration is open.

To keep in touch with news regarding the conference and Tcl events in
general, subscribe to the tcl-announce list. See:
http://code.activestate.com/lists/tcl-announce to subscribe to the
tcl-announce mailing list.


Conference Committee

Clif Flynt              Noumena Corp                   General Chair, Website Admin
Andreas Kupries         ActiveState Software Inc.      Program Chair
Brian Griffin           Mentor Graphics                Site/Facilities Chair
Arjen Markus            Deltares
Cyndy Lilagan           Nat. Museum of Health & Medicine, Chicago
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 at Michigan State University & CAEN Technologies
Steve Landers           Digital Smarties

Contact Information     tcl...@go...


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

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

Re: [MACTCL] [TCLCORE] Improved image handling and removing private API calls from Tk/Cocoa: summary and explanation

[Russell E. O. <ro...@uw...>]

In article <53D...@co...>,
 Kevin Walzer <kw...@co...> wrote:

> Jeff (and Donal and Steve and Gustaf and Will),
> 
> On 7/26/14, 1:40 PM, Jeff Hobbs wrote:
> > +1 from me as well, and thanks for the efforts.
> 
> Thanks for the vote of confidence. It means a lot.
> 
> FWIW, I've done a bit more fine-tuning of the code, removing the private 
> calls altogether rather than just ifdefing them out. I also found and 
> removed a bottleneck that was displaying atrociously slow redraw of 
> complex interfaces when scrolling (i.e. the text widget with embedded 
> windows from the demo); now I think the performance is almost 
> indistinguishable from the previous implementation that used the private 
> interfaces.

Wow! I was going to say how pleased I was that you removed the private 
calls, but this makes it even better.

Thank you very much for the cleanups.

-- Russell

Re: [MACTCL] Menu entry/font configure bug--help!

[Russell E. O. <ro...@uw...>]

In article <53D...@co...>,
 Kevin Walzer <kw...@co...> wrote:

> On 7/30/14, 11:33 PM, Kevin Walzer wrote:
> > Hi all,
> >
> > I could really use some help with a bug fix. I know what the problem is,
> > and I have a possible fix, but it's not optimal.
> 
> I'm happy to report that the good folks at BitKeeper provided a patch in 
> the Tcl chatroom today, and it solved the issue; fix committed, problem 
> solved. Thanks again!
> 
> --Kevin

That is great news! It sounds as if this may also fix bug 1628:
<http://code.activestate.com/lists/tcl-mac/1628/>

If so, that would allow me to upgrade to a modern version of Tcl/Tk for 
my application.

(And yes: personally I'd much rather not be able to disable sub-menus 
than have a crash, but it sounds as if that trade-off is no longer 
needed.)

Thank you and the folks at BitKeeper for tracking this down.

-- Russell

Re: [MACTCL] Menu entry/font configure bug--help!

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

On 7/30/14, 11:33 PM, Kevin Walzer wrote:
> Hi all,
>
> I could really use some help with a bug fix. I know what the problem is,
> and I have a possible fix, but it's not optimal.

I'm happy to report that the good folks at BitKeeper provided a patch in 
the Tcl chatroom today, and it solved the issue; fix committed, problem 
solved. Thanks again!

--Kevin

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