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

Re: [MACTCL] Cocoa Tk crashing on typing dead key combiner character

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

On 23/01/2011 10:56 AM, Ned Deily wrote:
> In article<D2C...@ma...>,
>   Torsten Berg<re...@ma...>  wrote:
>> I just uploaded a pathced version of tkMacOSXKeyEvent.c to the bug at SF.
>
> Thanks, Torsten.  And, thanks, Kevin, for looking into this.  I don't
> really want to get us into the business of building and shipping Tk with
> python.org installers but, if an official patch prevents this nasty
> crash and doesn't cause any other regressions, it might be worth it.

I'll make sure that we have an ActiveTcl release updated with this patch 
prior to Feb 12.  Note that we are using the 8.5-decarbon branch created 
by Daniel Steffen, which is not the "official" 8.5 source branch (that 
one still has the carbon sources).  Thus, no need for an official 8.5 
release related to this, and I suspect most people aren't using Tkinter 
and 8.6 at this time.

Jeff

Re: [MACTCL] Cocoa Tk crashing on typing dead key combiner character

[Damon C. <da...@tc...>]

You might ping Andreas Kupries (and...@ac...) over at ActiveState.  He handles the releases over there.  If you guys already recommend people install ActiveTcl (and you should over the default OS X install), you might be able to convince them that this bug is severe enough to do a small point release of ActiveTcl to fix it.  Then you would just recommend at least that version for Python.

It's not ideal since it's not in any "official" release from the Core Team, but for many people, ActiveTcl is as official as it gets.  And they are on their own release schedule as they see fit.  I'm pretty sure he might already watch this list, and if not, I know Jeff Hobbs does.  He never responds to anything though. 0-]

D


On Jan 23, 2011, at 12:56 PM, Ned Deily wrote:

> In article <D2C...@ma...>,
> Torsten Berg <re...@ma...> wrote:
>> I just uploaded a pathced version of tkMacOSXKeyEvent.c to the bug at SF.
> 
> Thanks, Torsten.  And, thanks, Kevin, for looking into this.  I don't 
> really want to get us into the business of building and shipping Tk with 
> python.org installers but, if an official patch prevents this nasty 
> crash and doesn't cause any other regressions, it might be worth it.
> 
> -- 
> Ned Deily,
> na...@ac...
> 
> 
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Cocoa Tk crashing on typing dead key combiner character

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

On 1/23/11 1:56 PM, Ned Deily wrote:
> In article<D2C...@ma...>,
>   Torsten Berg<re...@ma...>  wrote:
>> I just uploaded a pathced version of tkMacOSXKeyEvent.c to the bug at SF.
>
> Thanks, Torsten.  And, thanks, Kevin, for looking into this.  I don't
> really want to get us into the business of building and shipping Tk with
> python.org installers but, if an official patch prevents this nasty
> crash and doesn't cause any other regressions, it might be worth it.
>

I've committed Torsten's patch--thanks, Torsten. This works around the
issue by avoiding the crash, but I'm still not able to input some composite
characters (option-u, for instance): the keyboard input is ignored.
(Shift-option-u does work.)

Composite characters and Unicode are surprisingly difficult to manage in
Cocoa; I've spent a number of hours investigating this and was not able to
find any solution to the question. Torsten's patch is the only workable
solution for the moment.

--Kevin

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

Re: [MACTCL] Cocoa Tk crashing on typing dead key combiner character

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

In article <D2C...@ma...>,
 Torsten Berg <re...@ma...> wrote:
> I just uploaded a pathced version of tkMacOSXKeyEvent.c to the bug at SF.

Thanks, Torsten.  And, thanks, Kevin, for looking into this.  I don't 
really want to get us into the business of building and shipping Tk with 
python.org installers but, if an official patch prevents this nasty 
crash and doesn't cause any other regressions, it might be worth it.

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

Re: [MACTCL] Cocoa Tk crashing on typing dead key combiner character

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

Hi,

I just uploaded a pathced version of tkMacOSXKeyEvent.c to the bug at SF.

Torsten


> 
> Could you please put your code together into a full-fledged patch and 
> either send it here to the Tcl-Mac list or to the SF tracker, if you 
> haven't already? I'd be glad to review it and apply it as a short-term 
> workaround for this bug.
> 
> Ned,
> 
> Fixing this bug in CVS HEAD is not likely to address your concerns in 
> the near term. Apple does not update its version of Tcl/Tk except at new 
> releases of the OS, not at point releases. (IOW don't look for a new 
> version until Lion is out.) Daniel Steffen is pretty good about merging 
> updates from CVS HEAD into his 8.5 backport of Tk-Cocoa, but that likely 
> won't happen until the next point release of Tk (8.5.10, if I'm 
> correct). ActiveState is basing its release of Tcl/Tk on the Cocoa 
> version even in 8.5.x, so the bugfix should show up there after the next 
> point release of 8.5.
> 
> Thanks,
> Kevin
> 
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com
> 
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Cocoa Tk crashing on typing dead key combiner character

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

Torsten,

Could you please put your code together into a full-fledged patch and 
either send it here to the Tcl-Mac list or to the SF tracker, if you 
haven't already? I'd be glad to review it and apply it as a short-term 
workaround for this bug.

Ned,

Fixing this bug in CVS HEAD is not likely to address your concerns in 
the near term. Apple does not update its version of Tcl/Tk except at new 
releases of the OS, not at point releases. (IOW don't look for a new 
version until Lion is out.) Daniel Steffen is pretty good about merging 
updates from CVS HEAD into his 8.5 backport of Tk-Cocoa, but that likely 
won't happen until the next point release of Tk (8.5.10, if I'm 
correct). ActiveState is basing its release of Tcl/Tk on the Cocoa 
version even in 8.5.x, so the bugfix should show up there after the next 
point release of 8.5.

Thanks,
Kevin

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

Re: [MACTCL] Cocoa Tk crashing on typing dead key combiner character

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

Hi,

I do not think that an update is coming quickly for Apple's Cocoa Tk version. It takes quite a long time from an initial submission of Tk to the moment it is shipped. But Daniel Steffen can say more about this.

What I did until now, and this may not be an option for you, is to patch the sources just enough to avoid the crash. The accent is just suppressed and an un-accented character comes out instead. It just takes a simple additional 'if' statement in tkMacOSXKeyEvent.c:

[... lines 1-144 in current cvs version ...]
	if (type == NSKeyUp || repeat) {
	    xEvent.xany.type = KeyRelease;
	} else {
	    xEvent.xany.type = KeyPress;
	}
// prevent bug here -> composite characters
if ([characters length] > 0) {
	xEvent.xkey.keycode = (keyCode << 16) | (UInt16)
		[characters characterAtIndex:0];
	if (![characters getCString:xEvent.xkey.trans_chars
		maxLength:XMaxTransChars encoding:NSUTF8StringEncoding]) {
	    TkMacOSXDbgMsg("characters too long");
	    return theEvent;
	}
}
	len = [charactersIgnoringModifiers length];
[... lines 161-356 in current cvs version ...]

Of course, a correct solution would be best, but my skills are not good enough for this. I tried several things, looked for similar code on the net, but without success. So, we will have to wait until someone takes care of this issue and I suspect that Daniel is just too busy right now.

Torsten

> See http://bugs.python.org/issue10973
> 
> and
> 
> https://sourceforge.net/tracker/index.php?func=detail&aid=2907388&group_i
> d=12997&atid=112997
> 
> As I commented on the SF tracker:
> 
> "This is a really nasty bug and, with the release of Cocoa Tk
> backports to Tk 8.5, as in the Tcl/Tk 8.5.7 shipped by Apple in Mac OS
> X 10.6 and recent ActiveState Tcl/Tk 8.5.9, it is impacting more
> applications and users. In OS X 10.6, the Apple-supplied Python
> Tkinter modules and, thus, IDLE are susceptible to this crash:
> /usr/bin/idle2.6 and, with the US Extended input method, type Option-u
> (umlaut combiner) or Option-n (tilde combiner), for instance. For the
> Python Software Foundation (python.org) Python installers for OS X, we
> were intending to support 64-bit Python with a recommendation to use
> the ActiveState 8.5.9 Tcl/Tk (since the Apple-supplied one has so many
> other problems with Tkinter and IDLE) but this easy crasher seems to
> be a show stopper for that (http://bugs.python.org/issue10973). I see
> that postfix combining characters (like Shift-Option-u) work without
> crashing. It also appears that the system Character Viewer input does
> not work at all.
> 
> Any prognosis on a fix for this problem?"
> 
> I haven't been a regular follower of this list and, with a quick search 
> of the list archives, I didn't find any previous discussion of this 
> here.  Can anyone point me to such or, better, give an update on if and 
> when a fix is likely to appear in either Apple's or ActiveState's Cocoa 
> 8.5?  Since the Python 3.2 release is less than a month away, we might 
> have to pull Cocoa Tk support which would be unfortunate.
> 
> Thanks!
> --Ned
> 
> -- 
> Ned Deily,
> na...@ac...
> 
> 
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

[MACTCL] Cocoa Tk crashing on typing dead key combiner character

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

See http://bugs.python.org/issue10973

and

https://sourceforge.net/tracker/index.php?func=detail&aid=2907388&group_i
d=12997&atid=112997

As I commented on the SF tracker:

"This is a really nasty bug and, with the release of Cocoa Tk
backports to Tk 8.5, as in the Tcl/Tk 8.5.7 shipped by Apple in Mac OS
X 10.6 and recent ActiveState Tcl/Tk 8.5.9, it is impacting more
applications and users. In OS X 10.6, the Apple-supplied Python
Tkinter modules and, thus, IDLE are susceptible to this crash:
/usr/bin/idle2.6 and, with the US Extended input method, type Option-u
(umlaut combiner) or Option-n (tilde combiner), for instance. For the
Python Software Foundation (python.org) Python installers for OS X, we
were intending to support 64-bit Python with a recommendation to use
the ActiveState 8.5.9 Tcl/Tk (since the Apple-supplied one has so many
other problems with Tkinter and IDLE) but this easy crasher seems to
be a show stopper for that (http://bugs.python.org/issue10973). I see
that postfix combining characters (like Shift-Option-u) work without
crashing. It also appears that the system Character Viewer input does
not work at all.

Any prognosis on a fix for this problem?"

I haven't been a regular follower of this list and, with a quick search 
of the list archives, I didn't find any previous discussion of this 
here.  Can anyone point me to such or, better, give an update on if and 
when a fix is likely to appear in either Apple's or ActiveState's Cocoa 
8.5?  Since the Python 3.2 release is less than a month away, we might 
have to pull Cocoa Tk support which would be unfortunate.

Thanks!
--Ned

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

Re: [MACTCL] Tk-Cocoa and Mac App Store--DON'T

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

On Jan 9, 2011, at 9:21 AM, Jeff Hobbs wrote:

> On 2011-01-09, at 8:53 AM, Adrian Robert wrote:
>> On 2011/01/09, at 5:45, Kevin Walzer wrote:
>> 
>>> On 1/7/11 11:30 PM, Kevin Walzer wrote:
>>> 
>>>> I'm currently researching solutions to this issue, but in the meantime, if anyone on the list was considering submitting a commercial app to the App Store using Tk-Cocoa, I'd hold off. It will not be accepted under the current circumstances.
>>>> 
>>> After doing some further research, I've got some ideas on how to move  ahead with my app store submissions, and will report back a bit later  once I know if this new path is successful. :-)
>> 
>> Incidentally, what about Tk-Carbon-based apps?
> 
> I believe anything Carbon based could be excluded purely on the "uses deprecated technology" exclusion that Apple reserves.

I have a Carbon app (not TK, however) approved and know of at least 5 others, so it's not a problem with Carbon per-se...

Tim

Re: [MACTCL] Tk-Cocoa and Mac App Store--DON'T

[Damon C. <da...@tc...>]

Given all the private API usage, how do you hope to fix it?  Fix Tk?

D



On Jan 9, 2011, at 12:20 PM, Kevin Walzer <kw...@co...> wrote:

> On 1/9/11 11:21 AM, Jeff Hobbs wrote:
> 
>>> Incidentally, what about Tk-Carbon-based apps?
>> 
>> I believe anything Carbon based could be excluded purely on the "uses deprecated technology" exclusion that Apple reserves.
>> 
>> Jeff
> 
> Not necessarily. The issue with Tk-Cocoa is that it uses a lot of 
> private API's. I'm not sure about Carbon.
> 
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com
> 
> ------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success of any company
> that requires sensitive data to be transmitted over the Web.   Learn how to 
> best implement a security strategy that keeps consumers' information secure 
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl 
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Tk-Cocoa and Mac App Store--DON'T

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

On 1/9/11 1:40 PM, Damon Courtney wrote:
> Given all the private API usage, how do you hope to fix it?  Fix Tk?
>
> D
>

I have some ideas on how to proceed with this, but until I know whether 
they work, I don't want to go into detail. ;-)
-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [MACTCL] Tk-Cocoa and Mac App Store--DON'T

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

On 1/9/11 11:21 AM, Jeff Hobbs wrote:

>> Incidentally, what about Tk-Carbon-based apps?
>
> I believe anything Carbon based could be excluded purely on the "uses deprecated technology" exclusion that Apple reserves.
>
> Jeff

Not necessarily. The issue with Tk-Cocoa is that it uses a lot of 
private API's. I'm not sure about Carbon.

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

Re: [MACTCL] Tk-Cocoa and Mac App Store--DON'T

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

On 2011-01-09, at 8:53 AM, Adrian Robert wrote:
> On 2011/01/09, at 5:45, Kevin Walzer wrote:
> 
>> On 1/7/11 11:30 PM, Kevin Walzer wrote:
>> 
>>> I'm currently researching solutions to this issue, but in the meantime,
>>> if anyone on the list was considering submitting a commercial app to the
>>> App Store using Tk-Cocoa, I'd hold off. It will not be accepted under
>>> the current circumstances.
>>> 
>> After doing some further research, I've got some ideas on how to move 
>> ahead with my app store submissions, and will report back a bit later 
>> once I know if this new path is successful. :-)
> 
> 
> Incidentally, what about Tk-Carbon-based apps?

I believe anything Carbon based could be excluded purely on the "uses deprecated technology" exclusion that Apple reserves.

Jeff

Re: [MACTCL] Tk-Cocoa and Mac App Store--DON'T

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

On 2011/01/09, at 5:45, Kevin Walzer wrote:

> On 1/7/11 11:30 PM, Kevin Walzer wrote:
> 
>> I'm currently researching solutions to this issue, but in the meantime,
>> if anyone on the list was considering submitting a commercial app to the
>> App Store using Tk-Cocoa, I'd hold off. It will not be accepted under
>> the current circumstances.
>> 
> After doing some further research, I've got some ideas on how to move 
> ahead with my app store submissions, and will report back a bit later 
> once I know if this new path is successful. :-)


Incidentally, what about Tk-Carbon-based apps?

Re: [MACTCL] Tk-Cocoa and Mac App Store--DON'T

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

On 1/7/11 11:30 PM, Kevin Walzer wrote:

> I'm currently researching solutions to this issue, but in the meantime,
> if anyone on the list was considering submitting a commercial app to the
> App Store using Tk-Cocoa, I'd hold off. It will not be accepted under
> the current circumstances.
>
After doing some further research, I've got some ideas on how to move 
ahead with my app store submissions, and will report back a bit later 
once I know if this new path is successful. :-)
-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [MACTCL] Request for input: improving Mac-specific documentation in Tcl/Tk man pages

[Tom K. <kre...@gm...>]

After seeing some of the other comments on this list I will add that
when I developed the menubar package (found in tklib) using an 8.6
build from ActiveState.
tomk

On Fri, Jan 7, 2011 at 9:49 AM, Tom Krehbiel <kre...@gm...> wrote:
> Kevin,
> When I was working on the menubar package I noticed that tk menu item
> accelerator key sequences don't work although they appear to be
> supported on the Mac. I didn't spend a lot of time digging into the
> issue since I only had access to an old Mac laptop with 10.4 on it.
> tomk
>

Re: [MACTCL] [TCLCORE] Request for input: improving Mac-specific documentation in Tcl/Tk man pages

[<L....@su...>]

On 8 Jan 2011, at 16:19, Larry McVoy wrote:

> On Sat, Jan 08, 2011 at 11:32:21AM +0000, L....@su... wrote:
>> On 8 Jan 2011, at 01:49, Will Duquette wrote:
>> The Tk versions that ship with 10.5 Leopard and 10.6 Snow Leopard -
>> which is to say, 8.4.7 and 8.5.7. 
>> 
>> One of Tk's strengths is that it offers good portable crossplatform
>> GUI abstraction; Mac Tk should maintain that strength.
> 
> This isn't a Tk issue, it's an Apple issue.  At least in part.

Well, using the Mac menubar via Tk for my terminal-and-shell-script-spawned app was fine in Max OS X 10.4, broken in 10.5 (hence my detect-10.5-and-use-popup-menus workaround), fixed again in 10.6. That's writing menu code the recommended, cross-platform, works-everywhere-else way.

I don't know which of Tk or Apple was responsible for that particular regression, but given the other Tk-related things I've run into, I'm inclined to blame Tk. After all, Apple did ship later, updated, final point release versions of Tk with each OS release, which is an entirely reasonable thing to do.

> One could
> argue that it is a Tk issue because 8.6 hasn't shipped so Apple is using
> whatever they think is reasonable and that doesn't include 8.6
> beta something.

Well, yes - at this point 8.6 is only available as a beta (a two-year-old beta...), and requires some code changes for applications to support. At this point providing 8.5.x with OS releases is sensible.


> That said, we just bundle it.  It sucks but I *long* since gave up
> on having any hope of a reasonable answer depending on the installed
> versions.  We don't even count on stdio being stable, we ship our own
> (which has some nice benefits, we can extend it).
> 
> As a commercial application, depending on whatever being installed is
> just not prudent.

but as developers of a commercial application, you can justify the time and cost of developing and shipping more reliable alternatives.

The rest of us will have to settle for pointing out the problems, in the hope that that leads to improvements in the status quo.

Lloyd Wood
L....@su...
http://sat-net.com/L.Wood

Re: [MACTCL] [TCLCORE] Request for input: improving Mac-specific documentation in Tcl/Tk man pages

[Larry M. <lm...@bi...>]

On Sat, Jan 08, 2011 at 11:32:21AM +0000, L....@su... wrote:
> On 8 Jan 2011, at 01:49, Will Duquette wrote:
> The Tk versions that ship with 10.5 Leopard and 10.6 Snow Leopard -
> which is to say, 8.4.7 and 8.5.7. 
> 
> One of Tk's strengths is that it offers good portable crossplatform
> GUI abstraction; Mac Tk should maintain that strength.

This isn't a Tk issue, it's an Apple issue.  At least in part.  One could
argue that it is a Tk issue because 8.6 hasn't shipped so Apple is using
whatever they think is reasonable and that doesn't include 8.6
beta something.

That said, we just bundle it.  It sucks but I *long* since gave up
on having any hope of a reasonable answer depending on the installed
versions.  We don't even count on stdio being stable, we ship our own
(which has some nice benefits, we can extend it).

As a commercial application, depending on whatever being installed is
just not prudent.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [MACTCL] Request for input: improving Mac-specific documentation in Tcl/Tk man pages

[Will D. <wi...@wj...>]

I've usually used ActiveState's builds of Tcl/Tk, rather than
the build installed with OS X; but I've written a number of 
cross-platform apps that seem to run just fine on OS X.  The problem
is, the version of Tk that ships with OS X only gets updated
with major releases of the OS; and what you get is what was
available at that time.  

I've got a large application I'm currently working on with I
deliver on Linux; but I regularly do development work on a
MacBook Pro using a recent version of ActiveTcl.  I've done
almost nothing to customize it to look nice on the Mac, so it's
kind of ugly, but I'm not having any trouble with it either.

Will


On Jan 8, 2011, at 2:36 AM, <L....@su...> wrote:

> 
> On 8 Jan 2011, at 01:49, Will Duquette wrote:
> 
>> Odd.  I've done a fair amount of Tk programming on the Mac over the last seven or eight years, and I've not run into these kinds of problems.  Quirks, yes, and a few things to work around, but not the kind of problems you're talking about.  What versions have you seen this in?
> 
> The Tk versions that ship with 10.5 Leopard and 10.6 Snow Leopard - which is to say, 8.4.7 and 8.5.7. My concern is the installed base of Tk on the Macs for Mac OS X unix "power users".
> 
> Over the last decade I've been maintaining a unix Tk application (http://savi.sf.net/) that is crossplatform - compile it and go. On other platforms, it just works with the Tk supplied with the operating system, but on the Mac, there are Mac-only showstoppers.  Mac Tk's menuing support has proven particularly failure-prone; in 10.5 Leopard the menubar was just completely broken, and I had to go back to early-90s Tk code and spawn popup menus instead. I've had to come up with a number of Mac-only workarounds, including looking for specific SDK versions to predict Tk behaviour.
> 
> It may well be that people embedding a chosen version of Tk in Mac-specific app bundles (rather than linking unix binaries) avoid these problems. But I can't say that investing more time in Mac Tk or Mac OS X-only development is appealing, based on my experience to date...
> 
> It may also be that the core Mac Tk developers choose not to use other platforms, and simply don't consider testing with crossplatform unix Tcl/Tk applications. In which case, I'm expecting this problem to get worse, rather than better, in future. (And the GUI stuff will likely also diverge and become more works-on-Mac-only too.)
> 
> One of Tk's strengths is that it offers good portable crossplatform GUI abstraction; Mac Tk should maintain that strength.
> 
>> Will
>> 
>> On Jan 7, 2011, at 7:29 AM, <L....@su...> <L....@su...> wrote:
>> 
>>>> One developer responded that it seems there are lot of subtle ways in which Tk/Aqua differs
>>>> from other platforms and yet these differences are not documented in the man pages.
>>> [..]
>>>> I'm inclined to agree with him.
>>> [..]
>>>> What I'm asking for here is suggestions for additional things to cover, based on your experience,
>>> 
>>> The Mac-only crashes. Oh god, the crashes.
>>> 
>>> Tk on the Mac differs from other platforms in its lack of maturity and stability. Listbox too wide? Hang. Menuing problems appear endemic, as the Mac Tk code is relatively new.
>>> 
>>> http://sourceforge.net/tracker/?func=detail&atid=112997&aid=3044863&group_id=12997
>>> is one such example.
>>> 
>>> I'd leave focusing on documentation until the code is more solid, frankly.
> 
>> Will Duquette, OP
>> will -at- wjduquette dot com  
>> http://foothills.wjduquette.com/blog
> 
> Lloyd Wood
> L....@su...
> http://sat-net.com/L.Wood
> 
> 
> 


Will Duquette, OP
will -at- wjduquette dot com  
http://foothills.wjduquette.com/blog

Re: [MACTCL] Request for input: improving Mac-specific documentation in Tcl/Tk man pages

[<L....@su...>]

On 8 Jan 2011, at 01:49, Will Duquette wrote:

> Odd.  I've done a fair amount of Tk programming on the Mac over the last seven or eight years, and I've not run into these kinds of problems.  Quirks, yes, and a few things to work around, but not the kind of problems you're talking about.  What versions have you seen this in?

The Tk versions that ship with 10.5 Leopard and 10.6 Snow Leopard - which is to say, 8.4.7 and 8.5.7. My concern is the installed base of Tk on the Macs for Mac OS X unix "power users".

Over the last decade I've been maintaining a unix Tk application (http://savi.sf.net/) that is crossplatform - compile it and go. On other platforms, it just works with the Tk supplied with the operating system, but on the Mac, there are Mac-only showstoppers.  Mac Tk's menuing support has proven particularly failure-prone; in 10.5 Leopard the menubar was just completely broken, and I had to go back to early-90s Tk code and spawn popup menus instead. I've had to come up with a number of Mac-only workarounds, including looking for specific SDK versions to predict Tk behaviour.

It may well be that people embedding a chosen version of Tk in Mac-specific app bundles (rather than linking unix binaries) avoid these problems. But I can't say that investing more time in Mac Tk or Mac OS X-only development is appealing, based on my experience to date...

It may also be that the core Mac Tk developers choose not to use other platforms, and simply don't consider testing with crossplatform unix Tcl/Tk applications. In which case, I'm expecting this problem to get worse, rather than better, in future. (And the GUI stuff will likely also diverge and become more works-on-Mac-only too.)

One of Tk's strengths is that it offers good portable crossplatform GUI abstraction; Mac Tk should maintain that strength.

> 
> Will
> 
> On Jan 7, 2011, at 7:29 AM, <L....@su...> <L....@su...> wrote:
> 
>>> One developer responded that it seems there are lot of subtle ways in which Tk/Aqua differs
>>> from other platforms and yet these differences are not documented in the man pages.
>> [..]
>>> I'm inclined to agree with him.
>> [..]
>>> What I'm asking for here is suggestions for additional things to cover, based on your experience,
>> 
>> The Mac-only crashes. Oh god, the crashes.
>> 
>> Tk on the Mac differs from other platforms in its lack of maturity and stability. Listbox too wide? Hang. Menuing problems appear endemic, as the Mac Tk code is relatively new.
>> 
>> http://sourceforge.net/tracker/?func=detail&atid=112997&aid=3044863&group_id=12997
>> is one such example.
>> 
>> I'd leave focusing on documentation until the code is more solid, frankly.
>> ------------------------------------------------------------------------------
>> Gaining the trust of online customers is vital for the success of any company
>> that requires sensitive data to be transmitted over the Web.   Learn how to 
>> best implement a security strategy that keeps consumers' information secure 
>> and instills the confidence they need to proceed with transactions.
>> http://p.sf.net/sfu/oracle-sfdevnl 
>> _______________________________________________
>> Tcl-mac mailing list
>> tc...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 
> 
> Will Duquette, OP
> will -at- wjduquette dot com  
> http://foothills.wjduquette.com/blog
> 
> 
> 
> 
> 

Lloyd Wood
L....@su...
http://sat-net.com/L.Wood

Re: [MACTCL] Request for input: improving Mac-specific documentation in Tcl/Tk man pages

[<L....@su...>]

On 8 Jan 2011, at 01:49, Will Duquette wrote:

> Odd.  I've done a fair amount of Tk programming on the Mac over the last seven or eight years, and I've not run into these kinds of problems.  Quirks, yes, and a few things to work around, but not the kind of problems you're talking about.  What versions have you seen this in?

The Tk versions that ship with 10.5 Leopard and 10.6 Snow Leopard - which is to say, 8.4.7 and 8.5.7. My concern is the installed base of Tk on the Macs for Mac OS X unix "power users".

Over the last decade I've been maintaining a unix Tk application (http://savi.sf.net/) that is crossplatform - compile it and go. On other platforms, it just works with the Tk supplied with the operating system, but on the Mac, there are Mac-only showstoppers.  Mac Tk's menuing support has proven particularly failure-prone; in 10.5 Leopard the menubar was just completely broken, and I had to go back to early-90s Tk code and spawn popup menus instead. I've had to come up with a number of Mac-only workarounds, including looking for specific SDK versions to predict Tk behaviour.

It may well be that people embedding a chosen version of Tk in Mac-specific app bundles (rather than linking unix binaries) avoid these problems. But I can't say that investing more time in Mac Tk or Mac OS X-only development is appealing, based on my experience to date...

It may also be that the core Mac Tk developers choose not to use other platforms, and simply don't consider testing with crossplatform unix Tcl/Tk applications. In which case, I'm expecting this problem to get worse, rather than better, in future. (And the GUI stuff will likely also diverge and become more works-on-Mac-only too.)

One of Tk's strengths is that it offers good portable crossplatform GUI abstraction; Mac Tk should maintain that strength.

> Will
> 
> On Jan 7, 2011, at 7:29 AM, <L....@su...> <L....@su...> wrote:
> 
>>> One developer responded that it seems there are lot of subtle ways in which Tk/Aqua differs
>>> from other platforms and yet these differences are not documented in the man pages.
>> [..]
>>> I'm inclined to agree with him.
>> [..]
>>> What I'm asking for here is suggestions for additional things to cover, based on your experience,
>> 
>> The Mac-only crashes. Oh god, the crashes.
>> 
>> Tk on the Mac differs from other platforms in its lack of maturity and stability. Listbox too wide? Hang. Menuing problems appear endemic, as the Mac Tk code is relatively new.
>> 
>> http://sourceforge.net/tracker/?func=detail&atid=112997&aid=3044863&group_id=12997
>> is one such example.
>> 
>> I'd leave focusing on documentation until the code is more solid, frankly.

> Will Duquette, OP
> will -at- wjduquette dot com  
> http://foothills.wjduquette.com/blog

Lloyd Wood
L....@su...
http://sat-net.com/L.Wood

Re: [MACTCL] Request for input: improving Mac-specific documentation in Tcl/Tk man pages

[James L. <jam...@gm...>]

On Jan 7, 2011, at 4:22 PM, Kevin Walzer wrote:

> ...
> 
> What I'm asking for here is suggestions for additional things to cover, 
> based on your experience, and any suggested text or points that you feel 
> would be appropriate.
> 

I have very limited experience of using Tcl/Tk on a Mac but I did encounter some undocumented 'features', including:

1. The 'tk scaling' command doesn't work correctly, in particular for button text. I did have limited success by specifying
    TkDefaultFont for the font
2. A number of options don't work as advertised for menus, including 'columnbreak', and 'background'

On the other hand, I haven't experienced problems of crashes.

James

Re: [MACTCL] Request for input: improving Mac-specific documentation in Tcl/Tk man pages

[Will D. <wi...@wj...>]

On Jan 7, 2011, at 7:24 PM, Steve Landers wrote:

> 
> On 08/01/2011, at 11:14 AM, Kevan Hashemi wrote:
> 
>> Will Duquette wrote:
>>> Odd.  I've done a fair amount of Tk programming on the Mac over the
>>> last seven or eight years, and I've not run into these kinds of
>>> problems.
>> 
>> I'll second that. The interpreter is rock solid in my experience.
> 
> +1
> 
> And I applaud the efforts to improve the Mac-specific Tk documentation.

Very much agreed.



Will Duquette, OP
will -at- wjduquette dot com  
http://foothills.wjduquette.com/blog

[MACTCL] Tk-Cocoa and Mac App Store--DON'T

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

Hi all,

About a month ago I had submitted one of my Tk-Cocoa apps to the Mac App 
Store, which opened yesterday. I was hoping to be able to report 
success, but my app has been rejected. One reason it's been rejected is 
that Tk-Ccooa accesses private API's inside the AppKit headers, which is 
discouraged by Apple and is a no-no for apps in the App Store. A grep of 
the source tree of Tk-Cocoa for terms flagged by the App Store reviewers 
yielded this data:

Kevin-Walzers-MacBook:macosx kevin$ grep -R "_running" .
./tkMacOSXInit.c:    _running = 1;

Kevin-Walzers-MacBook:macosx kevin$ grep -R "_subviews" .
./tkMacOSXPrivate.h:    BOOL _subviewsSetAside;
./tkMacOSXWindowEvent.c:    _subviewsSetAside = NO;
./tkMacOSXWindowEvent.c:    if (_subviewsSetAside || _savedSubviews) {
./tkMacOSXWindowEvent.c:    _savedSubviews = _subviews;
./tkMacOSXWindowEvent.c:    _subviews = nil;
./tkMacOSXWindowEvent.c:    _subviewsSetAside = YES;
./tkMacOSXWindowEvent.c:    if (!_subviewsSetAside || _subviews) {
./tkMacOSXWindowEvent.c:    _subviews = _savedSubviews;
./tkMacOSXWindowEvent.c:    _subviewsSetAside = NO;
./tkMacOSXWindowEvent.c:    BOOL needToSetAsideSubviews = 
!_subviewsSetAside;
./tkMacOSXWindowEvent.c:    BOOL needToSetAsideSubviews = 
!_subviewsSetAside;
./tkMacOSXWindowEvent.c:    BOOL subviewsWereSetAside = _subviewsSetAside;
Kevin-Walzers-MacBook:macosx kevin$ grep -R appFlags .
./tkMacOSXInit.c:    if (!_appFlags._hasBeenRun) {
./tkMacOSXInit.c:        _appFlags._hasBeenRun = YES;


./tkMacOSXInit.c:    if (!_appFlags._hasBeenRun) {
./tkMacOSXInit.c:        _appFlags._hasBeenRun = YES;
Kevin-Walzers-MacBook:macosx kevin$

The _running and _appFlags instance variables are defined in 
NSApplication.h, and the _subviews instance variable is defined in 
NSView.h. All are marked in the headers as private and thus off-limits 
for direct access by developers.

I'm currently researching solutions to this issue, but in the meantime, 
if anyone on the list was considering submitting a commercial app to the 
App Store using Tk-Cocoa, I'd hold off. It will not be accepted under 
the current circumstances.

Thanks,
Kevin


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

Re: [MACTCL] [TCLCORE] Request for input: improving Mac-specific documentation in Tcl/Tk man pages

[Larry M. <lm...@bi...>]

We are in the same boat as Will though we do no Mac specific programming,
our stuff runs on 

    aix5
    freebsd
    hp-ia64
    hp11-parisc
    linux-ia64
    linux-parisc
    linux-ppc
    linux-x86 & x86_64
    macos-ppc
    macos-x86
    netbsd (x86)
    openbsd (x86)
    sco
    sgi
    sun-sparc
    sunx86
    windows (win2000 and later, though not a fan of vista)

On the mac we build both X11 and Aqua versions of our gui tools such that
if you rsh/ssh in and set your display you get X11 and it just works,
otherwise you get Aqua.  

We haven't had problems with the Mac but we also don't demand much of
Tk on the Mac.

That said, I too would be interested in knowing what problems are lurking.

On Fri, Jan 07, 2011 at 05:49:49PM -0800, Will Duquette wrote:
> Odd.  I've done a fair amount of Tk programming on the Mac over the last seven or eight years, and I've not run into these kinds of problems.  Quirks, yes, and a few things to work around, but not the kind of problems you're talking about.  What versions have you seen this in?
> 
> Will
> 
> On Jan 7, 2011, at 7:29 AM, <L....@su...> <L....@su...> wrote:
> 
> >> One developer responded that it seems there are lot of subtle ways in which Tk/Aqua differs
> >> from other platforms and yet these differences are not documented in the man pages.
> > [..]
> >> I'm inclined to agree with him.
> > [..]
> >> What I'm asking for here is suggestions for additional things to cover, based on your experience,
> > 
> > The Mac-only crashes. Oh god, the crashes.
> > 
> > Tk on the Mac differs from other platforms in its lack of maturity and stability. Listbox too wide? Hang. Menuing problems appear endemic, as the Mac Tk code is relatively new.
> > 
> > http://sourceforge.net/tracker/?func=detail&atid=112997&aid=3044863&group_id=12997
> > is one such example.
> > 
> > I'd leave focusing on documentation until the code is more solid, frankly.
> > ------------------------------------------------------------------------------
> > Gaining the trust of online customers is vital for the success of any company
> > that requires sensitive data to be transmitted over the Web.   Learn how to 
> > best implement a security strategy that keeps consumers' information secure 
> > and instills the confidence they need to proceed with transactions.
> > http://p.sf.net/sfu/oracle-sfdevnl 
> > _______________________________________________
> > Tcl-mac mailing list
> > tc...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 
> 
> Will Duquette, OP
> will -at- wjduquette dot com  
> http://foothills.wjduquette.com/blog
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success of any company
> that requires sensitive data to be transmitted over the Web.   Learn how to 
> best implement a security strategy that keeps consumers' information secure 
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com