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

[MACTCL] TkCocoa and event loop again ... any idea?

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

Hi,

in my application (that should run on Tk 8.6) I use a paned window (or ttk::panedwindow, which makes no difference) to show some widgets and hide (or "forget") them again based on what the user wants to see (using a toolbar). I have the problem that the scrollbars begin to be unresponsive on moving with the mouse (= clicking on the scrollbar and trying to move it) while using the scroll function of the Magic Mouse (= swiping the finger up or down the mouse) always works. I have tried to make an example code that shows this behaviour.

Run the script below with TkCocoa. First you will see a listbox on the left and text widget on the right. You can easily scroll the listbox clicking on the scrollbar handle and mowing it up and down. Now change the view by clicking on "step 1". Then click on "step 2" to get the original view back.

Now I cannot move the scrollbar any more. Moving the main window around on the screen sometimes makes it responsive again, sometimes also clicking a lot into the scrollbar and the trough will do, but then later it locks again. This only helps in this example code, not in my actual application code.

I have read that using some [after idle] or [update] will help, but I cannot figure out how. Is anybody able to make this scrollbar work all the time??

Thanks very much for any help,
Torsten


proc ScrolledWidget {widget parent args} {
	# create a standard widget with scrollbars around
	#
	# wigdet  -> name of the widget to be created
	# parent  -> path to the frame, in which the widget and the scrollbars should
	#            be created
	#
	# returns: the path to the created widget (frame)
	#
	ttk::frame $parent
	# Create widget attached to scrollbars, pass thru $args
	$widget $parent.list
	# Create scrollbars attached to the child widget
	ttk::scrollbar $parent.sx -orient horizontal -command [list $parent.list xview]
	grid $parent.sx -column 0 -row 1 -sticky ew
	$parent.list configure -xscrollcommand [list $parent.sx set]
	ttk::scrollbar $parent.sy -orient vertical -command [list $parent.list yview]
	grid $parent.sy -column 1 -row 0 -sticky ns
	$parent.list configure -yscrollcommand [list $parent.sy set]
	# Arrange them in the parent frame
	grid $parent.list -column 0 -row 0 -sticky ewsn
	grid columnconfigure $parent 0 -weight 1
	grid rowconfigure $parent 0 -weight 1
	# hide the original widget command from the interpreter:
	interp hide {} $parent
	# Install the alias:
	interp alias {} $parent {} ScrolledWidgetCmd $parent.list
	# fix the bindings for the child widget:
	bindtags $parent.list [lreplace [bindtags $parent.list] 0 0 $parent]
	return $parent
}
proc ScrolledWidgetCmd {self cmd args} {
	switch -- $cmd {
		widgetPath {return "$self.list"}
		default {return [uplevel 1 [list $self $cmd] $args]}
	}
}




panedwindow .p
pack .p -expand 1 -fill both

ScrolledWidget listbox .p.l
for {set i 0} {$i < 30} {incr i} {.p.l insert end $i}
.p add .p.l

text .p.t
.p add .p.t

ScrolledWidget listbox .p.l2
for {set i 0} {$i < 1000} {incr i} {.p.l2 insert end $i}

button .b -command expose1 -text "step 1"
pack .b
button .bb -command expose2 -text "step 2"
pack .bb


proc expose1 {} {
	.p paneconfigure .p.l -hide 1
	.p paneconfigure .p.t -hide 1
	if {".p.l2" ni [.p panes]} {.p add .p.l2 -stretch always} else {.p paneconfigure .p.l2 -hide 0}
}

proc expose2 {} {
	.p paneconfigure .p.l2 -hide 1
	.p paneconfigure .p.l -hide 0
	.p paneconfigure .p.t -hide 0
}

Re: [MACTCL] Partial PNG transparency not working in Cocoa Tk

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

Adrian and Linus,

On 12/7/13, 9:43 AM, Adrian Robert wrote:
>  From what I can tell the gstate is just a shortcut for avoiding creating a new one by focusing the view.  So it should be possible to use:
>
> [view lockFocusIfCanDraw]
> draw, calling the NSCopyBits with NSNullObject instead of gstate
> [view unlockFocus]
>
> But it might not be that simple — I don’t fully understand the NSGraphicsContext-related calls below.

Thank you for these suggestions. I've been doing some digging into 
gState and can't quite figure out what purpose it serves.  I don't think 
there's an equivalent CoreGrpahics call that we can substitute in for it 
(I've been looking at it from that angle). I'll give this approach a try 
and see if I can make any progress. More in a few days, hopefully.

What a headache! Some might call the Win32 and Xlib API's may be 
moribund, but I prefer Debian-speak here: "stable." Grumble, grumble, 
grumble...

--Kevin

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

Re: [MACTCL] Partial PNG transparency not working in Cocoa Tk

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

From what I can tell the gstate is just a shortcut for avoiding creating a new one by focusing the view.  So it should be possible to use:

[view lockFocusIfCanDraw]
draw, calling the NSCopyBits with NSNullObject instead of gstate
[view unlockFocus]

But it might not be that simple — I don’t fully understand the NSGraphicsContext-related calls below.



On 2013.12.6, at 19:58, Linus Nyberg <li...@fa...> wrote:

> Hi and thank both of you for replying.
> 
> I can confirm that the same thing works fine on Mac OS X Lion.
> Unfortunately, Mavericks is not going away any time soon, and it’s a little scary that we appear to be the only ones trying to show transparent icons on the latest Mac OS X.
> 
> I now managed to download and compile the sources for Tcl/Tk 8.6.1 and using printf:s around the code I managed to track down the problem:
> - The way Tk composits photo images with alpha by creating an image of the background window and manually blending that image with the transparent image (see TkImgPhotoDisplay() in tkImgPhInstance.c).
> - When it fails to create the image of the background image, it simply draws the image without alpha (see TkImgPhotoDisplay() @ “We failed to get the image so draw without blending alpha. It's the best we can do”).
> - The problem is in case is that exactly that fails.
> - The reason for the failure is inside XCopyArea() in tkMacOSXDraw.c. There we can find this code:
> 	NSView *view = TkMacOSXDrawableView(srcDraw); 
> 	NSWindow *w = [view window];
> 	NSInteger gs = [w windowNumber] > 0 ? [w gState] : 0;
> 
> … and gs becomes 0, which makes the method return prematurely.
> When googling for NSWindow gState, I found this:
> https://developer.apple.com/library/mac/releasenotes/AppKit/RN-AppKit/#//apple_ref/doc/uid/TP30000741-CH2-SW51
> where it states:
>> Beginning in Mac OS X 10.9 -[NSView allocateGState] and -[NSView releaseGState] are no ops. These methods were seldom used. Additionally, methods that relied on the side effects of these methods, specifically -[NSView gState] and -[NSWindow gState] will now always return 0.
> 
> That would explain it, I think… But I don’t know what “gState” is and I don’t know how to solve it.
> Any ideas??
> 
> Best regards,
> 
> Linus
> 
> On 3 dec 2013, at 15:40, Kevin Walzer <kw...@co...> wrote:
> 
>> On 11/29/13, 3:58 AM, Wojciech Kocjan wrote:
>>> - happens on OS X 10.9 only - does not happen on 10.8 and below (also,
>>> transparency works fine on all other systems and all other OS X
>>> versions, so I suspect this is a change in OS X 10.9 that broke it)
>>> 
>>> - happens with latest Tcl/Tk from fossil, latest ActiveTcl
>>> 
>>> - happens with both tkpng and Img
>>> 
>>> - I can also confirm it only happens with Cocoa, not Carbon
>>> 
>>> So this is definitely an issue with Tk.
>> 
>> I'm not certain where to start with this. I've seen reports in Apple's 
>> dev forums about wonky color calibration in Mavericks (sRGB is no longer 
>> accurately rendered in many contexts, which is causing headaches for 
>> graphics shops), yet Linus reports that images created with the 
>> tk::mac::IconBitmap command (which is just a thin wrapper around various 
>> NSImage methods) work just fine. NSImage is itself an opaque wrapper 
>> around many, many different things.
>> 
>> If the issues with alpha channel rendering are based in the system 
>> changes in Mavericks, I am not optimistic about fixing them...it does 
>> not seem like a good idea to try to special-case image code in the Img, 
>> TkPNG, and 8.6 core, I would think. (Nor would I even know where to 
>> start here.)
>> 
>> --Kevin
>> 
>> -- 
>> Kevin Walzer
>> Code by Kevin/Mobile Code by Kevin
>> http://www.codebykevin.com
>> http://www.wtmobilesoftware.com
>> 
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT 
>> organizations don't have a clear picture of how application performance 
>> affects their revenue. With AppDynamics, you get 100% visibility into your 
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Tcl-mac mailing list
>> tc...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK 
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk_______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Partial PNG transparency not working in Cocoa Tk

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

Hi and thank both of you for replying.

I can confirm that the same thing works fine on Mac OS X Lion.
Unfortunately, Mavericks is not going away any time soon, and it’s a little scary that we appear to be the only ones trying to show transparent icons on the latest Mac OS X.

I now managed to download and compile the sources for Tcl/Tk 8.6.1 and using printf:s around the code I managed to track down the problem:
- The way Tk composits photo images with alpha by creating an image of the background window and manually blending that image with the transparent image (see TkImgPhotoDisplay() in tkImgPhInstance.c).
- When it fails to create the image of the background image, it simply draws the image without alpha (see TkImgPhotoDisplay() @ “We failed to get the image so draw without blending alpha. It's the best we can do”).
- The problem is in case is that exactly that fails.
- The reason for the failure is inside XCopyArea() in tkMacOSXDraw.c. There we can find this code:
	NSView *view = TkMacOSXDrawableView(srcDraw); 
	NSWindow *w = [view window];
	NSInteger gs = [w windowNumber] > 0 ? [w gState] : 0;

… and gs becomes 0, which makes the method return prematurely.
When googling for NSWindow gState, I found this:
https://developer.apple.com/library/mac/releasenotes/AppKit/RN-AppKit/#//apple_ref/doc/uid/TP30000741-CH2-SW51
where it states:
> Beginning in Mac OS X 10.9 -[NSView allocateGState] and -[NSView releaseGState] are no ops. These methods were seldom used. Additionally, methods that relied on the side effects of these methods, specifically -[NSView gState] and -[NSWindow gState] will now always return 0.


That would explain it, I think… But I don’t know what “gState” is and I don’t know how to solve it.
Any ideas??

Best regards,

Linus

On 3 dec 2013, at 15:40, Kevin Walzer <kw...@co...> wrote:

> On 11/29/13, 3:58 AM, Wojciech Kocjan wrote:
>> - happens on OS X 10.9 only - does not happen on 10.8 and below (also,
>> transparency works fine on all other systems and all other OS X
>> versions, so I suspect this is a change in OS X 10.9 that broke it)
>> 
>> - happens with latest Tcl/Tk from fossil, latest ActiveTcl
>> 
>> - happens with both tkpng and Img
>> 
>> - I can also confirm it only happens with Cocoa, not Carbon
>> 
>> So this is definitely an issue with Tk.
> 
> I'm not certain where to start with this. I've seen reports in Apple's 
> dev forums about wonky color calibration in Mavericks (sRGB is no longer 
> accurately rendered in many contexts, which is causing headaches for 
> graphics shops), yet Linus reports that images created with the 
> tk::mac::IconBitmap command (which is just a thin wrapper around various 
> NSImage methods) work just fine. NSImage is itself an opaque wrapper 
> around many, many different things.
> 
> If the issues with alpha channel rendering are based in the system 
> changes in Mavericks, I am not optimistic about fixing them...it does 
> not seem like a good idea to try to special-case image code in the Img, 
> TkPNG, and 8.6 core, I would think. (Nor would I even know where to 
> start here.)
> 
> --Kevin
> 
> -- 
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Partial PNG transparency not working in Cocoa Tk

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

On 11/29/13, 3:58 AM, Wojciech Kocjan wrote:
> - happens on OS X 10.9 only - does not happen on 10.8 and below (also,
> transparency works fine on all other systems and all other OS X
> versions, so I suspect this is a change in OS X 10.9 that broke it)
>
> - happens with latest Tcl/Tk from fossil, latest ActiveTcl
>
> - happens with both tkpng and Img
>
> - I can also confirm it only happens with Cocoa, not Carbon
>
> So this is definitely an issue with Tk.

I'm not certain where to start with this. I've seen reports in Apple's 
dev forums about wonky color calibration in Mavericks (sRGB is no longer 
accurately rendered in many contexts, which is causing headaches for 
graphics shops), yet Linus reports that images created with the 
tk::mac::IconBitmap command (which is just a thin wrapper around various 
NSImage methods) work just fine. NSImage is itself an opaque wrapper 
around many, many different things.

If the issues with alpha channel rendering are based in the system 
changes in Mavericks, I am not optimistic about fixing them...it does 
not seem like a good idea to try to special-case image code in the Img, 
TkPNG, and 8.6 core, I would think. (Nor would I even know where to 
start here.)

--Kevin

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

Re: [MACTCL] Partial PNG transparency not working in Cocoa Tk

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

Hi,

I have recently noticed it myself and done some investigation on the
issue. Here is some summary:

- happens on OS X 10.9 only - does not happen on 10.8 and below (also,
transparency works fine on all other systems and all other OS X
versions, so I suspect this is a change in OS X 10.9 that broke it)

- happens with latest Tcl/Tk from fossil, latest ActiveTcl

- happens with both tkpng and Img

- I can also confirm it only happens with Cocoa, not Carbon

So this is definitely an issue with Tk.

As I am not a Cocoa/Tk expert, that is as far as I went. For the
affected code I simply created PNG images with 0%/100% transparency
and use transparent images for other OSes for now, at least until this
is resolved.


2013/11/29 Linus Nyberg <li...@fa...>:
> Hi all,
>
> I’m trying to move our application over from Carbon based Tcl/Tk (8.5.4) to
> any of the Cocoa versions (8.5.13 or 8.6.1) in order to get Retina text, 64
> bit support, future proof, etc.
> One show stopper problem I’m having is that tk “images” don’t seem to render
> partial transparency (where pixels are 1-99% transparent).
> Here’s a screenshot of the result I get, where I show a “label -image”, a
> “label -bitmap” and “canvas image” with the same transparent png image. Only
> the bitmap label works, the others are wrong:
> https://dl.dropboxusercontent.com/u/12145205/alphatest_fail.png
>
> Does anyone have any tips on how to get this working? It works fine on the
> old Carbon based Tk, using the tkpng extension. It also works fine on 8.6.1
> on *Windows*.
> I wish it was as easy as just using “-bitmap” based labels all the time, but
> we at least really need images to work in canvas as well (bitmap does not
> work there as far as I know).
>
> Here are replication steps:
> - Download and install ActiveTcl 8.6.1
> - Go to http://www.w3.org/Graphics/PNG/inline-alpha.html and drag the test
> png image to your Desktop
> - Save the code below to a file (for example “alphatest.tcl on your
> desktop).
> - Open Wish.app for Tcl 8.6.1 and “Source…” alphatest.tcl
> - Happens: The image based label and image in canvas are wrong, but the
> bitmap based label works.
>
> # alphatest.tcl
> #-----------------
> set png_path "~/Desktop/alphatest.png"
>
> wm geometry . 400x900
>
> ::tk::mac::iconBitmap test_png 380 287 -imageFile $png_path
> image create photo test_png -format png -width 380 -height 287 -file
> $png_path
>
> # LABEL BASED ON "image" - does not handle partial transparency well
> #-----------------------
> set l .image_label
> label $l -image test_png
> place $l -x 10 -y 10 -anchor nw
>
> # LABEL BASED ON "bitmap" - works
> #-----------------------
> set l2 .bitmap_label
> label $l2 -bitmap test_png
> place $l2 -x 10 -y 300 -anchor nw
>
> # IMAGE IN CANVAS (BASED ON "image") - does not handle partial transparency
> well
> #-----------------------------------
> set c .c
> canvas $c -width 500 -height 310 -bg white
> place $c -x 10 -y 600 -anchor nw
> $c create image 10 10 -image test_png -anchor nw
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>

[MACTCL] Partial PNG transparency not working in Cocoa Tk

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

Hi all,

I’m trying to move our application over from Carbon based Tcl/Tk (8.5.4) to any of the Cocoa versions (8.5.13 or 8.6.1) in order to get Retina text, 64 bit support, future proof, etc.
One show stopper problem I’m having is that tk “images” don’t seem to render partial transparency (where pixels are 1-99% transparent).
Here’s a screenshot of the result I get, where I show a “label -image”, a “label -bitmap” and “canvas image” with the same transparent png image. Only the bitmap label works, the others are wrong:
https://dl.dropboxusercontent.com/u/12145205/alphatest_fail.png

Does anyone have any tips on how to get this working? It works fine on the old Carbon based Tk, using the tkpng extension. It also works fine on 8.6.1 on *Windows*.
I wish it was as easy as just using “-bitmap” based labels all the time, but we at least really need images to work in canvas as well (bitmap does not work there as far as I know).

Here are replication steps:
- Download and install ActiveTcl 8.6.1
- Go to http://www.w3.org/Graphics/PNG/inline-alpha.html and drag the test png image to your Desktop
- Save the code below to a file (for example “alphatest.tcl on your desktop).
- Open Wish.app for Tcl 8.6.1 and “Source…” alphatest.tcl
- Happens: The image based label and image in canvas are wrong, but the bitmap based label works.

# alphatest.tcl
#-----------------
set png_path "~/Desktop/alphatest.png"

wm geometry . 400x900

::tk::mac::iconBitmap test_png 380 287 -imageFile $png_path
image create photo test_png -format png -width 380 -height 287 -file $png_path

# LABEL BASED ON "image" - does not handle partial transparency well
#-----------------------
set l .image_label
label $l -image test_png
place $l -x 10 -y 10 -anchor nw

# LABEL BASED ON "bitmap" - works
#-----------------------
set l2 .bitmap_label
label $l2 -bitmap test_png
place $l2 -x 10 -y 300 -anchor nw

# IMAGE IN CANVAS (BASED ON "image") - does not handle partial transparency well
#-----------------------------------
set c .c
canvas $c -width 500 -height 310 -bg white
place $c -x 10 -y 600 -anchor nw
$c create image 10 10 -image test_png -anchor nw

Re: [MACTCL] Aqua Tk 8.5/8.6 problem on OS X 10.9 Mavericks

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

In article <nad...@ne...>,
 Ned Deily <na...@ac...> wrote:

> In article 
> <nad...@ne...>,
>  Ned Deily <nad...@pu...> wrote:
> > In article 
> > <rowen-938790.13450928102013-2AO0Uh8ossnZ+VzJOa5vwg-XMD5yJDbdMReXY1tMh2IBg@p
> > ublic.gmane.org>,
> >  "Russell E. Owen" 
> >  <row...@pu...> wrote:
> > > I'm really uneasy about standard Mac Python including Tcl/Tk because 
> > > Aqua Tcl/Tk has so many bugs. The best version of Tcl/Tk for one 
> > > application may not be best version for another user. For instance in 
> > > this case I'll probably need to continue to use 8.5.11 for quite some 
> > > time, and just force the application into 32-bit mode for compatibility 
> > > with MacOS X 10.9.  
> > I was concerned as well about use cases such as yours.   The primary focus 
> > of 
> > the python.org installers, IMO, is to make it easy for inexperienced users 
> > to 
> > get going with Python quickly, e.g. "batteries included". 
> 
> An update: after Python 2.7.6rc1 and 3.3.3rc1 received some exposure, a major 
> compatibility problem was discovered with the built-in Tcl/Tk 8.5 
> implementation in the python.org installer.  Several important third-part 
> packages that depend on the installer also depend on building and/or 
> dynamically linking with Tcl and Tk frameworks in /Library.  These include 
> PIL/Pillow and Matplotlib.  Given the urgency of getting updated installers 
> out to support 10.9 Mavericks, we decided to pull the built-in Tcl/Tk support 
> out of 2.7.6 (final) and 3.3.3 (as of rc2).  So, these releases work the way 
> previous releases have wrt which Tcl and Tk libraries are used.  What to do 
> for 3.4.0 is under consideration, but the built-in implementation will 
> definitely change for 3.4.0b1.  Thanks for your input, Russell.

Good catch. I had not thought that through. I had assumed your python 
installer put Tcl/Tk into its usual spot in /Library/Frameworks, in 
which case it would not affect how one built matplotlib and PIL. But 
that would replace any existing Tcl/Tk, which could be really nasty for 
users (especially since ActiveState does not serve older versions!). If 
you do decide to got that route, I hope the installer will ask before 
deleting an existing Tcl/Tk 8.5.

I'm sorry this is turning out to be such a headache. Much as I like my 
Mac, I sure hate the hassles in building unix-ish software for it.

-- Russell

P.S. your instructions for using a separate Tcl/Tk with a Python that 
includes its own Tcl/Tk seemed clear and simple enough. That addressed 
my concern that you quote above.

Re: [MACTCL] Aqua Tk 8.5/8.6 problem on OS X 10.9 Mavericks

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

In article <nad...@ne...>,
 Ned Deily <nad...@pu...> wrote:
> In article 
> <row...@pu...>,
>  "Russell E. Owen" <row...@pu...> wrote:
> > I'm really uneasy about standard Mac Python including Tcl/Tk because 
> > Aqua Tcl/Tk has so many bugs. The best version of Tcl/Tk for one 
> > application may not be best version for another user. For instance in 
> > this case I'll probably need to continue to use 8.5.11 for quite some 
> > time, and just force the application into 32-bit mode for compatibility 
> > with MacOS X 10.9.  
> I was concerned as well about use cases such as yours.   The primary focus of 
> the python.org installers, IMO, is to make it easy for inexperienced users to 
> get going with Python quickly, e.g. "batteries included". 

An update: after Python 2.7.6rc1 and 3.3.3rc1 received some exposure, a major 
compatibility problem was discovered with the built-in Tcl/Tk 8.5 
implementation in the python.org installer.  Several important third-part 
packages that depend on the installer also depend on building and/or 
dynamically linking with Tcl and Tk frameworks in /Library.  These include 
PIL/Pillow and Matplotlib.  Given the urgency of getting updated installers 
out to support 10.9 Mavericks, we decided to pull the built-in Tcl/Tk support 
out of 2.7.6 (final) and 3.3.3 (as of rc2).  So, these releases work the way 
previous releases have wrt which Tcl and Tk libraries are used.  What to do 
for 3.4.0 is under consideration, but the built-in implementation will 
definitely change for 3.4.0b1.  Thanks for your input, Russell.

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

Re: [MACTCL] wish launcher in applescript

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

Hi Simon,

On 11/11/13, 9:59 PM, Simon Dorfman wrote:
> Hello,
>
> I wrote an applescript launcher to be distributed with a tcl/tk app.
> Perhaps it will be useful to someone here. Here's the code:
>
> set UnixPath to POSIX path of ((path to me as text) & "::") --get path
> to parent folder
> set LaunchCrossFire to "/usr/local/bin/wish '" & UnixPath &
> "CrossFire.tcl' > /dev/null 2>&1 &" -- create command to launch CrossFire
> do shell script LaunchCrossFire -- run command
>
> ...and here's a link to where I got help writing it:
> http://superuser.com/questions/670893/get-path-of-parent-folder-of-script-location-applescript
>
>
Thank you for this!

You might also be interested in finding out how to deploy your script in 
a standalone Tcl/Tk application that does not require a separate 
launcher. Here's a link to a tutorial:

http://opensource.codebykevin.com/tutorial.html

Best,
Kevin

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

[MACTCL] wish launcher in applescript

[Simon D. <si...@ya...>]

Hello,

I wrote an applescript launcher to be distributed with a tcl/tk app.
Perhaps it will be useful to someone here. Here's the code:

set UnixPath to POSIX path of ((path to me as text) & "::") --get path to
parent folder
set LaunchCrossFire to "/usr/local/bin/wish '" & UnixPath & "CrossFire.tcl'
> /dev/null 2>&1 &" -- create command to launch CrossFire
do shell script LaunchCrossFire -- run command

...and here's a link to where I got help writing it:
http://superuser.com/questions/670893/get-path-of-parent-folder-of-script-location-applescript

-Simon

Re: [MACTCL] tcl tk problems after upgrade to mavericks

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

In article <31B...@gm...>,
 ph....@pu... wrote:
> I use a small program called "Ding: Dictionary lookup"
> It makes use of tcl/tk. It was joyful to use until I upgraded to Mavericks.
> Any keys I type into its search bar simply NOT show up,
> only after moving the window or hitting return.

There is a known refresh problem with Cocoa Tk on OS X 10.9 (Mavericks).  It 
has been fixed in the Tk trunk with a patch.  The Tk issue is here:

https://core.tcl.tk/tk/tktview?name=53f7a1b553

You can read an earlier thread about it here:

http://comments.gmane.org/gmane.comp.lang.tcl.mac/7194

There is a source patch for Tk 8.5 (and should work for Tk 8.6) that can be 
extracted from here:

http://hg.python.org/cpython/rev/8609f6df9974#l2.5

You should open an issue on the MacPorts bug tracker against the Tk port 
asking for the patch to be applied.

https://trac.macports.org/newticket

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

[MACTCL] tcl tk problems after upgrade to mavericks

[<ph....@gm...>]

I use a small program called "Ding: Dictionary lookup"
It makes use of tcl/tk. It was joyful to use until I upgraded to Mavericks.
Any keys I type into its search bar simply NOT show up,
only after moving the window or hitting return.


I wish to add here that I reinstalled my Macports and my tcl/tk but this did not help at all.


Philipp
ph....@gm...

[MACTCL] Custom operators

[Stefan M. L. <ste...@gm...>]

Hi there,

I need to implement some custom operators used by BigIp irules (a Tcl
flavor).

Can that be achieved using standard Tcl code?

Here is what we wanna be able to do:

if {"abcdefg" starts_with "ab"} { puts "starts_with works as expected" }
if {"abcdefg" ends_with "efg"} { puts "ends_with works as expected" }
if {"abcdefg" contains "cde"} { puts "contains works as expected" }
if {"abcdefg" matches_glob "ab*efg"} { puts "matches_glob works as
expected" }
if {"abcdefg" matches_regex "a.cde.*"} { puts "matches_regex works as
expected" }

if {"abcdefg" equals "abcdefg"} { puts "equals works as expected" }
if { 1 and 1} { puts "and works as expected" }
if { 1 or 0} { puts "or works as expected" }
if { not false } { puts "not works as expected" }

Cheers,

Stefan

-- 
BEKK Open
http://open.bekk.no

TesTcl - a unit test framework for iRules
http://testcl.com

Re: [MACTCL] Aqua Tk 8.5/8.6 problem on OS X 10.9 Mavericks

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

In article <row...@ne...>,
 "Russell E. Owen" <ro...@uw...> wrote:
> In article 
> <nad...@ne...>,
>  Ned Deily <na...@ac...> wrote: 
> >...
> > Thanks for tracking down the problem, Kevin!  The applied patch does indeed 
> > solve the problems seen with Python's IDLE on 10.9.
> > 
> > As described in Issue19373, the Python project has just issued maintenance 
> > release candidates, 3.3.3rc1 and 2.7.6rc1, for the current Python 3 and 2 
> > releases.  The python.org OS X 64-bit binary installers for these releases 
> > now 
> > include a built-in version of Tcl/Tk 8.5 so that users no longer have to 
> > install third-part Tcl/Tk releases to avoid the critical problems in the 
> > system Tcl/Tk 8.5 shipped by Apple in recent OS X releases.  The fix 
> > arrived 
> > after the "rc1" installers were created but "rc1_rev1" installers that 
> > include 
> > this fix should be available on the 3.3.3 and 2.7.6 download pages soon.
> > 
> > http://www.python.org/download/releases/3.3.3/
> > http://www.python.org/download/releases/2.7.6/
> > http://bugs.python.org/issue19373
> 
> Thank you both.
> 
> Do you have any idea how to use my own Tcl/Tk instead of the one 
> provided?

Yes, i do.  But I was hoping to not have to tell.  :=)

>  I'll need to do this if the crashing bug I recently reported 
> (caused by resizing a font in the option database) has not been fixed 
> (and I'm pretty sure it hasn't; it's too recent and this Mavericks 
> problem was too important).
> 
> I'm really uneasy about standard Mac Python including Tcl/Tk because 
> Aqua Tcl/Tk has so many bugs. The best version of Tcl/Tk for one 
> application may not be best version for another user. For instance in 
> this case I'll probably need to continue to use 8.5.11 for quite some 
> time, and just force the application into 32-bit mode for compatibility 
> with MacOS X 10.9.
 
I was concerned as well about use cases such as yours.   The primary focus of 
the python.org installers, IMO, is to make it easy for inexperienced users to 
get going with Python quickly, e.g. "batteries included".  But that doesn't 
mean we should preclude use by more sophisticated users.  And, one of the 
"sophisticated" use cases for the python.org installers is to build Python 
applications that run on multiple versions of OS X.  So, although at the 
moment the option is not highlighted and there is not a easy to user interface 
and it is subject to change, it is possible to continue to use to Tkinter with 
a third-party Tcl/Tk in /Library/Frameworks or the Apple-supplied Tcl/Tk in 
/System/Frameworks.  The new python.org 64-bit installers actually ship with 
two versions of the _tkinter.so extension module, one that links with the new 
built-in Tcl/Tk libraries and another that continues to link as before with 
/Library/Frameworks Tcl and Tk frameworks (falling back to 
/System/Library/Frameworks).  The first is the default installed version.  
There are two options available.  If you want to change your Python 
installation to use the latter _tkinter.so for all users, you can follow the 
instructions in the source tree here:

http://hg.python.org/cpython/file/v3.3.3rc1/Mac/BuildScript/README.txt
http://hg.python.org/cpython/file/v2.7.6rc1/Mac/BuildScript/README.txt

The idea is to just copy the desired _tkinter.so into lib-dynload:

sudo bash
cd /Library/Frameworks/Python.framework/Versions/3.3
cd ./lib/python3.3
cp -p ./lib-tkinter/library/_tkinter.so ./lib-dynload
exit

It is also possible to modify the Python module search path to find the other 
_tkinter first.  This allows changing _tkinter's dynamically without requiring 
administrator access.  An example:

# To use the "library" tkinter -> /Library/Frameworks
PYTHONPATH=/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-
tkinter/library /usr/local/bin/idle2.7

# To return to the "builtin" tkinter -> using Python's built-in copy of Tcl/Tk
PYTHONPATH=/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-
tkinter/builtin /usr/local/bin/idle2.7

I have to admit that I came up at the last minute with the idea of putting the 
_tkinter's into that kind of directory structure so that you could use 
PYTHONPATH or manipulate sys.path if you know the right paths.  I didn't have 
time to try to make it more elegant or properly document it prior to rc1 for 
3.3.3 and 2.7.6.  I would consider it "experimental".   I'm open to 
suggestions on other approaches but they are not likely to make it into the 
final releases of 3.3.3 and 2.7.6 at this point.  (Note, that the current 
3.4.0a4 has an earlier implementation and doesn't work quite like this.  The 
current tip of the default trunk does and, unless changed, will be in 3.4.0b1.)

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

Re: [MACTCL] Aqua Tk 8.5/8.6 problem on OS X 10.9 Mavericks

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

In article <nad...@ne...>,
 Ned Deily <na...@ac...> wrote:

>...
> Thanks for tracking down the problem, Kevin!  The applied patch does indeed 
> solve the problems seen with Python's IDLE on 10.9.
> 
> As described in Issue19373, the Python project has just issued maintenance 
> release candidates, 3.3.3rc1 and 2.7.6rc1, for the current Python 3 and 2 
> releases.  The python.org OS X 64-bit binary installers for these releases 
> now 
> include a built-in version of Tcl/Tk 8.5 so that users no longer have to 
> install third-part Tcl/Tk releases to avoid the critical problems in the 
> system Tcl/Tk 8.5 shipped by Apple in recent OS X releases.  The fix arrived 
> after the "rc1" installers were created but "rc1_rev1" installers that 
> include 
> this fix should be available on the 3.3.3 and 2.7.6 download pages soon.
> 
> http://www.python.org/download/releases/3.3.3/
> http://www.python.org/download/releases/2.7.6/
> http://bugs.python.org/issue19373

Thank you both.

Do you have any idea how to use my own Tcl/Tk instead of the one 
provided? I'll need to do this if the crashing bug I recently reported 
(caused by resizing a font in the option database) has not been fixed 
(and I'm pretty sure it hasn't; it's too recent and this Mavericks 
problem was too important).

I'm really uneasy about standard Mac Python including Tcl/Tk because 
Aqua Tcl/Tk has so many bugs. The best version of Tcl/Tk for one 
application may not be best version for another user. For instance in 
this case I'll probably need to continue to use 8.5.11 for quite some 
time, and just force the application into 32-bit mode for compatibility 
with MacOS X 10.9.

-- Russell

Re: [MACTCL] Aqua Tk 8.5/8.6 problem on OS X 10.9 Mavericks

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

In article <526...@co...>,
 Kevin Walzer <kw...@co...> wrote:
> On 10/23/13, 4:06 PM, Ned Deily wrote:
> > Now that OS 10.9 Mavericks has been released (and at no cost), people are
> > updating to it and running into a problem with Aqua Tk.  I ran into the
> > problem with Python's IDLE but it seems to affect other multi-window Tk
> > applications, as it can be reproduced using wish demos.   Basically, the
> > problem is that Tk windows don't get automatically redrawn when the mouse 
> > is
> > used to change the active window and focus.  I've described the details 
> > here:
> >
> > https://core.tcl.tk/tk/tktview?name=53f7a1b553
> >
> > As it affects current versions of ActiveTcl 8.5 and 8.6, I also opened an
> > ActiveTcl issue:
> >
> > http://bugs.activestate.com/show_bug.cgi?id=101210
> >
> > As noted in the Tk issue above, the Apple-supplied Tk 8.5.9 does not have 
> > this
> > problem but that version has other, serious problems that have been fixed 
> > in
> > newer versions of Tk 8.5, for example, immediately crashing when typing a
> > composing character in a text field (like option-u for US Extended input
> > methods).  Also as noted, one workaround appears to be to force Tcl/Tk to 
> > run
> > in 32-bit mode, which may not be possible for some applications if they 
> > depend
> > on non-universal libraries.
> 
> Daniel Steffen provided me a patch for the issue that he devised during 
> the development of Mavericks, and which he applied to Apple's private 
> branch of Tk-Cocoa (essentially the old 8.5.9 branch, as you noted in 
> the bug report). Daniel's patch is why the behavior isn't visible in 
> Apple's system-provided Tk, because it was fixed already. :-) Now that 
> Mavericks is out he was able to provide the patch for upstream use.
> 
> After installing Mavericks and testing with my existing build of Tk, I 
> did see the behavior. After doing a fresh checkout of trunk and 8.5, 
> applying the patch, and rebuilding Tcl/Tk, I don't see any of the 
> behavior indicated. As a result I believe this patch solves the problem 
> and I have committed it.

Thanks for tracking down the problem, Kevin!  The applied patch does indeed 
solve the problems seen with Python's IDLE on 10.9.

As described in Issue19373, the Python project has just issued maintenance 
release candidates, 3.3.3rc1 and 2.7.6rc1, for the current Python 3 and 2 
releases.  The python.org OS X 64-bit binary installers for these releases now 
include a built-in version of Tcl/Tk 8.5 so that users no longer have to 
install third-part Tcl/Tk releases to avoid the critical problems in the 
system Tcl/Tk 8.5 shipped by Apple in recent OS X releases.  The fix arrived 
after the "rc1" installers were created but "rc1_rev1" installers that include 
this fix should be available on the 3.3.3 and 2.7.6 download pages soon.

http://www.python.org/download/releases/3.3.3/
http://www.python.org/download/releases/2.7.6/
http://bugs.python.org/issue19373

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

Re: [MACTCL] Aqua Tk 8.5/8.6 problem on OS X 10.9 Mavericks

[Alexander S. <a.s...@gm...>]

Hi Jeff,

my first tests are positiv, I'll do some more test this evening.

Best Regards,
Alex

Am 27.10.2013 um 21:57 schrieb Jeff Hobbs <je...@ac...>:

> We are building updated ActiveTcl installations for 8.5 and 8.6 with this patch this weekend.  If someone wants to test from that, let me know.
> 
> Jeff
> 
> On 2013-10-27, at 1:46 PM, Kevin Walzer <kw...@co...> wrote:
> 
>> Hi Ned,
>> 
>> On 10/23/13, 4:06 PM, Ned Deily wrote:
>>> Now that OS 10.9 Mavericks has been released (and at no cost), people are
>>> updating to it and running into a problem with Aqua Tk.  I ran into the
>>> problem with Python's IDLE but it seems to affect other multi-window Tk
>>> applications, as it can be reproduced using wish demos.   Basically, the
>>> problem is that Tk windows don't get automatically redrawn when the mouse is
>>> used to change the active window and focus.  I've described the details here:
>>> 
>>> https://core.tcl.tk/tk/tktview?name=53f7a1b553
>>> 
>>> As it affects current versions of ActiveTcl 8.5 and 8.6, I also opened an
>>> ActiveTcl issue:
>>> 
>>> http://bugs.activestate.com/show_bug.cgi?id=101210
>>> 
>>> As noted in the Tk issue above, the Apple-supplied Tk 8.5.9 does not have this
>>> problem but that version has other, serious problems that have been fixed in
>>> newer versions of Tk 8.5, for example, immediately crashing when typing a
>>> composing character in a text field (like option-u for US Extended input
>>> methods).  Also as noted, one workaround appears to be to force Tcl/Tk to run
>>> in 32-bit mode, which may not be possible for some applications if they depend
>>> on non-universal libraries.
>> 
>> Daniel Steffen provided me a patch for the issue that he devised during 
>> the development of Mavericks, and which he applied to Apple's private 
>> branch of Tk-Cocoa (essentially the old 8.5.9 branch, as you noted in 
>> the bug report). Daniel's patch is why the behavior isn't visible in 
>> Apple's system-provided Tk, because it was fixed already. :-) Now that 
>> Mavericks is out he was able to provide the patch for upstream use.
>> 
>> After installing Mavericks and testing with my existing build of Tk, I 
>> did see the behavior. After doing a fresh checkout of trunk and 8.5, 
>> applying the patch, and rebuilding Tcl/Tk, I don't see any of the 
>> behavior indicated. As a result I believe this patch solves the problem 
>> and I have committed it.
>> 
>> Thanks again for the report, and thanks to Daniel for the patch.
>> 
>> Best,
>> Kevin
>> 
>> 
>> -- 
>> Kevin Walzer
>> Code by Kevin/Mobile Code by Kevin
>> http://www.codebykevin.com
>> http://www.wtmobilesoftware.com
> 
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

--
Alexander Schöpe
IT-Sachverständiger
Soft-Engineering, Support und Consulting
Im Haarmannsbusch 125a
44797 Bochum

T: +49 (234) 9799566
F: +49 (3212) 1225370

USt-IdNr: DE272452626

Re: [MACTCL] Aqua Tk 8.5/8.6 problem on OS X 10.9 Mavericks

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

We are building updated ActiveTcl installations for 8.5 and 8.6 with this patch this weekend.  If someone wants to test from that, let me know.

Jeff

On 2013-10-27, at 1:46 PM, Kevin Walzer <kw...@co...> wrote:

> Hi Ned,
> 
> On 10/23/13, 4:06 PM, Ned Deily wrote:
>> Now that OS 10.9 Mavericks has been released (and at no cost), people are
>> updating to it and running into a problem with Aqua Tk.  I ran into the
>> problem with Python's IDLE but it seems to affect other multi-window Tk
>> applications, as it can be reproduced using wish demos.   Basically, the
>> problem is that Tk windows don't get automatically redrawn when the mouse is
>> used to change the active window and focus.  I've described the details here:
>> 
>> https://core.tcl.tk/tk/tktview?name=53f7a1b553
>> 
>> As it affects current versions of ActiveTcl 8.5 and 8.6, I also opened an
>> ActiveTcl issue:
>> 
>> http://bugs.activestate.com/show_bug.cgi?id=101210
>> 
>> As noted in the Tk issue above, the Apple-supplied Tk 8.5.9 does not have this
>> problem but that version has other, serious problems that have been fixed in
>> newer versions of Tk 8.5, for example, immediately crashing when typing a
>> composing character in a text field (like option-u for US Extended input
>> methods).  Also as noted, one workaround appears to be to force Tcl/Tk to run
>> in 32-bit mode, which may not be possible for some applications if they depend
>> on non-universal libraries.
> 
> Daniel Steffen provided me a patch for the issue that he devised during 
> the development of Mavericks, and which he applied to Apple's private 
> branch of Tk-Cocoa (essentially the old 8.5.9 branch, as you noted in 
> the bug report). Daniel's patch is why the behavior isn't visible in 
> Apple's system-provided Tk, because it was fixed already. :-) Now that 
> Mavericks is out he was able to provide the patch for upstream use.
> 
> After installing Mavericks and testing with my existing build of Tk, I 
> did see the behavior. After doing a fresh checkout of trunk and 8.5, 
> applying the patch, and rebuilding Tcl/Tk, I don't see any of the 
> behavior indicated. As a result I believe this patch solves the problem 
> and I have committed it.
> 
> Thanks again for the report, and thanks to Daniel for the patch.
> 
> Best,
> Kevin
> 
> 
> -- 
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com

Re: [MACTCL] Aqua Tk 8.5/8.6 problem on OS X 10.9 Mavericks

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

Hi Ned,

On 10/23/13, 4:06 PM, Ned Deily wrote:
> Now that OS 10.9 Mavericks has been released (and at no cost), people are
> updating to it and running into a problem with Aqua Tk.  I ran into the
> problem with Python's IDLE but it seems to affect other multi-window Tk
> applications, as it can be reproduced using wish demos.   Basically, the
> problem is that Tk windows don't get automatically redrawn when the mouse is
> used to change the active window and focus.  I've described the details here:
>
> https://core.tcl.tk/tk/tktview?name=53f7a1b553
>
> As it affects current versions of ActiveTcl 8.5 and 8.6, I also opened an
> ActiveTcl issue:
>
> http://bugs.activestate.com/show_bug.cgi?id=101210
>
> As noted in the Tk issue above, the Apple-supplied Tk 8.5.9 does not have this
> problem but that version has other, serious problems that have been fixed in
> newer versions of Tk 8.5, for example, immediately crashing when typing a
> composing character in a text field (like option-u for US Extended input
> methods).  Also as noted, one workaround appears to be to force Tcl/Tk to run
> in 32-bit mode, which may not be possible for some applications if they depend
> on non-universal libraries.

Daniel Steffen provided me a patch for the issue that he devised during 
the development of Mavericks, and which he applied to Apple's private 
branch of Tk-Cocoa (essentially the old 8.5.9 branch, as you noted in 
the bug report). Daniel's patch is why the behavior isn't visible in 
Apple's system-provided Tk, because it was fixed already. :-) Now that 
Mavericks is out he was able to provide the patch for upstream use.

After installing Mavericks and testing with my existing build of Tk, I 
did see the behavior. After doing a fresh checkout of trunk and 8.5, 
applying the patch, and rebuilding Tcl/Tk, I don't see any of the 
behavior indicated. As a result I believe this patch solves the problem 
and I have committed it.

Thanks again for the report, and thanks to Daniel for the patch.

Best,
Kevin


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

Re: [MACTCL] Aqua Tk 8.5/8.6 problem on OS X 10.9 Mavericks

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

On Oct 25, 2013, at 9:28 PM, Ned Deily <na...@ac...> wrote:

> ...
> Knowing next to nothing about the internals of Cocoa Tk, I'm still wondering 
> about the significance, if any, of:
> 
> 1. a universal (x86_64, i386) build of, say, Tk 8.5.15 exhibits the failures 
> when run as x86_64 but seems to work OK forced to run in 32-bit mode (i386)

Yeah, I also see the behavior being far better in a 32-bit build.  Some font metrics and image-handling oddities are the only remaining problems I see.


> 2. the Apple-supplied version of Aqua Tk 8.5.9 in 10.9, apparently built from 
> the old DAS sources, appears to work OK in either x64_64 or i386 mode


This suggests maybe some change was made later that wasn’t 64-bit clean.  It’s not necessarily in the Mac code, though maybe that’s more likely.


-Adrian

Re: [MACTCL] Aqua Tk 8.5/8.6 problem on OS X 10.9 Mavericks

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

In article <3A2...@gm...>,
 Adrian Robert <adr...@pu...> 
 wrote:
> On Oct 25, 2013, at 12:54 AM, Kevin Walzer 
> <kw-...@pu...> wrote: 
> > On 10/23/13 4:06 PM, Ned Deily wrote:
> >> Now that OS 10.9 Mavericks has been released (and at no cost), people are
> >> updating to it and running into a problem with Aqua Tk.  I ran into the
> >> problem with Python's IDLE but it seems to affect other multi-window Tk
> >> applications, as it can be reproduced using wish demos.   Basically, the
> >> problem is that Tk windows don't get automatically redrawn when the mouse 
> >> is
> >> used to change the active window and focus.
> > I hope to install Mavericks this weekend and I'll take a look then.
> I¹ve just installed it and Tk-Cocoa is a mess under Mavericks.  Something 
> with the new timer coalescing interacts very badly with the 
> incorrectly-implemented event and drawing loops in Tk-Cocoa.  A quick fix 
> might be to use the new timer APIs to request low jitter.  But one might hope 
> that the bugs themselves might help point out more clearly what is wrong with 
> the current impl.

Knowing next to nothing about the internals of Cocoa Tk, I'm still wondering 
about the significance, if any, of:

1. a universal (x86_64, i386) build of, say, Tk 8.5.15 exhibits the failures 
when run as x86_64 but seems to work OK forced to run in 32-bit mode (i386)

2. the Apple-supplied version of Aqua Tk 8.5.9 in 10.9, apparently built from 
the old DAS sources, appears to work OK in either x64_64 or i386 mode

--
  Ned Deily
  na...@ac... -- []

Re: [MACTCL] Aqua Tk 8.5/8.6 problem on OS X 10.9 Mavericks

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

Our app checks for "-psn" in the command line to
detect if called as an App, but this no longer seems to be emplyed ??

> I was reading about those new API's in Siracusa's review and wondered
> what their effect might be. Sounds like a mess indeed.

Hmmm - just what we need for our timer based problems.
Timer coalescing is probably going to take a lot of debugging for
performance critical apps.

FWIW, our 32bit carbon 8.5.9 framework seems to go ok
on the last mavericks beta (13a598)....

OpenGL/game performance seem to be affected by the OS upgrade too.
http://forums.macrumors.com/showthread.php?p=18196922#post18196922

On Fri, Oct 25, 2013 at 9:07 PM, Kevin Walzer <kw...@co...> wrote:
> On 10/25/13 12:23 AM, Adrian Robert wrote:
>> I’ve just installed it and Tk-Cocoa is a mess under Mavericks.  Something with the new timer coalescing interacts very badly with the incorrectly-implemented event and drawing loops in Tk-Cocoa.  A quick fix might be to use the new timer APIs to request low jitter.  But one might hope that the bugs themselves might help point out more clearly what is wrong with the current impl.
>>
>> -Adrian
>
> I was reading about those new API's in Siracusa's review and wondered
> what their effect might be. Sounds like a mess indeed.
>
> As noted, I'll try to install Mavericks this weekend (I have four
> machines plus a server to upgrade), and will do some more digging after
> that.
>
> --Kevin
>
> --
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Aqua Tk 8.5/8.6 problem on OS X 10.9 Mavericks

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

On 10/25/13 12:23 AM, Adrian Robert wrote:
> I’ve just installed it and Tk-Cocoa is a mess under Mavericks.  Something with the new timer coalescing interacts very badly with the incorrectly-implemented event and drawing loops in Tk-Cocoa.  A quick fix might be to use the new timer APIs to request low jitter.  But one might hope that the bugs themselves might help point out more clearly what is wrong with the current impl.
>
> -Adrian

I was reading about those new API's in Siracusa's review and wondered 
what their effect might be. Sounds like a mess indeed.

As noted, I'll try to install Mavericks this weekend (I have four 
machines plus a server to upgrade), and will do some more digging after 
that.

--Kevin

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

Re: [MACTCL] Aqua Tk 8.5/8.6 problem on OS X 10.9 Mavericks

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

I’ve just installed it and Tk-Cocoa is a mess under Mavericks.  Something with the new timer coalescing interacts very badly with the incorrectly-implemented event and drawing loops in Tk-Cocoa.  A quick fix might be to use the new timer APIs to request low jitter.  But one might hope that the bugs themselves might help point out more clearly what is wrong with the current impl.

-Adrian



On Oct 25, 2013, at 12:54 AM, Kevin Walzer <kw...@co...> wrote:

> On 10/23/13 4:06 PM, Ned Deily wrote:
>> Now that OS 10.9 Mavericks has been released (and at no cost), people are
>> updating to it and running into a problem with Aqua Tk.  I ran into the
>> problem with Python's IDLE but it seems to affect other multi-window Tk
>> applications, as it can be reproduced using wish demos.   Basically, the
>> problem is that Tk windows don't get automatically redrawn when the mouse is
>> used to change the active window and focus.
> 
> I hope to install Mavericks this weekend and I'll take a look then.
> 
> --Kevin
> 
> 
> 
> -- 
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac