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

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

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

On Wed, Jul 30, 2014 at 8:33 PM, Kevin Walzer <kw...@co...> wrote:
> Hi all,
>
> I could really use some help with a bug fix. I know what the problem is,
> and I have a possible fix, but it's not optimal.
>
> Last year Zbigniew Diaczyszyn reported that running "font configure"
> caused "bad access" crash in Tk Cocoa. The bug report is at
> http://sourceforge.net/p/tktoolkit/bugs/3093/,

Equivalent
    https://core.tcl.tk/tk/tktview?name=3612814fff

-- 
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster™
F: 778.786.1133
and...@ac...
http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato

EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/
21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA --
http://www.tcl.tk/community/tcl2014/
Send mail to tcl...@go..., by Sep 8
Registration is open.

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

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

Hi all,

I could really use some help with a bug fix. I know what the problem is, 
and I have a possible fix, but it's not optimal.

Last year Zbigniew Diaczyszyn reported that running "font configure" 
caused "bad access" crash in Tk Cocoa. The bug report is at 
http://sourceforge.net/p/tktoolkit/bugs/3093/, along with a sample 
script and a stack trace. Essentially, running "font configure 
TkDefaultFont -size 12" causes the crash--and it's routed, of all 
places, through the menu code, specifically TkpConfigureMenuEntry.

After running Tk in a debugger, I found the offending line in 
tkMacOSXMenu.c, around line 688 or so, which was committed a couple of 
years ago:

   [item setEnabled: !(submePtr->state == ENTRY_DISABLED)];

This line is part of a loop that steps through each menu item in a 
submenu and determines whether to set it as enabled or grayed out. If Tk 
has not set the item as disabled, Cocoa is supposed to enable the menu 
item.

This code works just fine with regular menu configuration. My guess is, 
however, is that configuring a font somehow causes a side effect of 
trying to configure the menu font as well, and the pointer to the menu 
state struct ("submePtr->state ") is somehow clobbered.

One fix is easy: remove the reference to the pointer and just run [item 
setEnabled: YES]. That seems to avoid all the crashes associated with 
font configuration. However, the unfortunate side effect is that this 
also means that menu items, at least sub-menu items, will ignore state 
flags and will always be enabled.

Alas, I haven't been able to find an actual fix to the font 
configuration side effect other than simply punting and setting submenu 
items as enabled.

If anyone has any other ideas where to look, or can provide a patch, I 
would be mighty grateful. If not, any comments on the merits of leaving 
entries enabled all the time are also appreciated.

Thanks,
Kevin


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

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

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

On 7/29/14, 12:02 AM, Don Porter wrote:
> Prompted by the substantial work, I gave the Tk test suite a try
> on my Mavericks MacBook Pro.  The results were … interesting.
>
> Can you comment on what we ought to expect from the Tk test suite?
> I know it’s never played the same central role on OSX as it has on
> other platforms, but at one point we did at least reach the point
> where the test suite did not crash or hang.
>
> I’m seeing what looks like panics from system libraries?  Perhaps
> just trying the test suite yourself will point the way to further
> improvements?
>

I've never been quite sure how to use the test suite as a benchmarking 
tool, as I see it (at least on Mac) reporting failures with no apparent 
issues for how Tk runs. I observed this with the 8.5 suite incorporating 
the recent commits:

Tests ended at Tue Jul 29 08:24:28 EDT 2014
all.tcl:	Total	457	Passed	432	Skipped	14	Failed	11
Sourced 17 Test Files.
Files with failing tests: entry.test spinbox.test ttk.test
Number of tests skipped for each constraint:
	2	NA
	4	coreEntry
	5	nyi
	3	xpnative
Kevins-MacBook-Pro:tcl-tk-85-main-merge kevin$

Running the suite against 8.6, I did observe a crash:

0   Tk                            	0x00000001007c463f TkPointerEvent + 
1327 (tkGrab.c:889)
1   Tk                            	0x00000001007b5030 
InvokeMouseHandlers + 176 (tkEvent.c:299)
2   Tk                            	0x00000001007b46ec Tk_HandleEvent + 
332 (tkEvent.c:1276)
3   Tk                            	0x000000010079f68e 
HandleEventGenerate + 7230 (tkBind.c:3440)

Seems to be an issue with the mouse pointer--if it's in the grab code, 
Tk-Cocoa's event loop doesn't play well with grab and I tend to 
discourage its use. I'm not sure where in the test suite this came; here 
is the output from the test commands themselves:

==== textIndex-19.12 Display lines FAILED
==== Contents of test case:

     .t index "2.40 -1displaylines"

---- Result was:
2.17
---- Result should have been (exact matching):
2.20
==== textIndex-19.12 FAILED

textMark.test
textTag.test
2014-07-29 09:07:17.987 tktest[33359:507] 
CFURLCopyResourcePropertyForKey failed because it was passed this URL 
which has no scheme: badStipple
2014-07-29 09:07:17.989 tktest[33359:507] 
CFURLCopyResourcePropertyForKey failed because it was passed this URL 
which has no scheme: bogus
/bin/sh: line 1: 33359 Segmentation fault: 11  ./tktest 
/Users/kevin/tcl-tk-fossil/tk/unix/../tests/all.tcl -geometry +0+0
make[2]: *** [test-classic] Error 139
make[1]: *** [test-tk] Error 2
make: *** [test-develop] Error 2

Any idea where I could take a closer look at this?

--Kevin



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

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

[Don P. <d.g...@co...>]

On Jul 25, 2014, at 2:32 PM, Kevin Walzer <kw...@co...> wrote:
> I'm writing to report on a couple of significant commits I have made to 
> Tk/Mac on both trunk and core-8-5-branch.

From the descriptions, all sounds good to me.

Prompted by the substantial work, I gave the Tk test suite a try
on my Mavericks MacBook Pro.  The results were … interesting.

Can you comment on what we ought to expect from the Tk test suite?
I know it’s never played the same central role on OSX as it has on
other platforms, but at one point we did at least reach the point
where the test suite did not crash or hang.

I’m seeing what looks like panics from system libraries?  Perhaps
just trying the test suite yourself will point the way to further
improvements?

DGP

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

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

Jeff (and Donal and Steve and Gustaf and Will),

On 7/26/14, 1:40 PM, Jeff Hobbs wrote:
> +1 from me as well, and thanks for the efforts.

Thanks for the vote of confidence. It means a lot.

FWIW, I've done a bit more fine-tuning of the code, removing the private 
calls altogether rather than just ifdefing them out. I also found and 
removed a bottleneck that was displaying atrociously slow redraw of 
complex interfaces when scrolling (i.e. the text widget with embedded 
windows from the demo); now I think the performance is almost 
indistinguishable from the previous implementation that used the private 
interfaces.

--Kevin

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

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

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

+1 from me as well, and thanks for the efforts.

On Fri, Jul 25, 2014 at 5:33 PM, Steve Landers
<st...@di...> wrote:
> Kevin,
>
> This all makes sense to me.  Thanks to you and Marc for for initiating the work and stewarding it to completion.
>
> Steve
>
>> On 26 Jul 2014, at 2:32 am, Kevin Walzer <kw...@co...> wrote:
>>
>> Hi all,
>>
>> I'm writing to report on a couple of significant commits I have made to
>> Tk/Mac on both trunk and core-8-5-branch.
>>
>> The first commit is based on an extensive patch provided by Marc Culler
>> that fixes alpha rendering in images under Tk Cocoa; some changes in
>> 10.9 Mavericks broke rendering of the alpha channel in images, so
>> transparency was no longer displayed (instead just ugly black shapes for
>> shadows, or nothing at all). Marc re-worked several functions to restore
>> this functionality, and I appreciate his work. Thanks so much to him for
>> taking the time to submit, re-work, and then re-submit the patch.
>>
>> The second change involves removing several function calls into private,
>> undocumented Cocoa drawing methods. Some of these changes may be a bit
>> controversial, as they carry a performance penalty in certain contexts,
>> but I believe they are important and I wanted to explain why I have made
>> them.
>>
>> As designed, Tk Cocoa attempts to map an X11 style of window drawing
>> onto the Cocoa graphics/windowing API. We're all aware that this is not
>> a seamless mapping. To improve the drawing performance and make the
>> rendering a bit cleaner, Daniel Steffen borrowed some techniques from
>> WebKit that involve calling into private, undocumented API's to give Tk
>> better, more fine-grained control of drawing in response to X11-style
>> "Expose" events.
>>
>> Apple has always warned against using undocumented API's as they are
>> unsupported and subject to change. However, in 2009, when Daniel was
>> working on the Cocoa port, this seemed a very reasonable optimization to
>> make, as the example of WebKit was already out there, and the relevant
>> private API's had not been changed for several years.  Also, Apple did
>> not take any action against accessing private API's beyond discouraging
>> it as unsupported and occasionally changing the API's in question.
>>
>> More recently, however, Apple has taken a harder line on using
>> undocumented API's by making it more difficult to distribute apps that
>> make use of such calls; these apps are not allowed in the Mac App Store,
>> which has become the main way of distributing apps on the Mac platform.
>> For instance, in the case of my own apps, this has prevented me from
>> shipping up-to-date Tk code with my apps, because the app store
>> restrictions forbid it.
>>
>> I have worked around the issue by linking to the version of Tk bundled
>> with the operating system, which on my machine is 8.5.9. (This loophole
>> exists because Apple-installed libraries are exempted from their rules
>> on private API's.) Such workarounds are inherently fragile, however, as
>> they are dependent on Apple continuing to ship Tk with the operating
>> system. If Apple were to stop distributing Tk with OS X, then no app
>> making use of Tk as currently designed would be able to access Apple's
>> main distribution channel.
>>
>> These changes in the Mac platform, combined with my general discomfort
>> with Tk accessing unsupported API's when other open-source languages and
>> frameworks do not, have led me to conclude that these calls need to be
>> removed. And that's what I've done.
>>
>> In some cases, the removal of these calls causes no issue at all. A few
>> of the calls focused on accessing the "resize grip" on the lower corner
>> of a window. Apple removed the "resize grip" from windows in 10.7, so
>> there is no need for private API access here at all.
>>
>> In other cases, there may be a performance hit in drawing especially
>> complex interfaces. I commented out an entire class designed by Daniel
>> that accesses private NSWindow/NSView API's, based on the example of
>> WebKit. My initial fear was that this would prevent drawing from
>> occurring at all, but that's not the case. I've done a fair amount of
>> testing with the widget demo, my own apps, and a couple of third-party
>> apps that link to Tk, and in virtually every context windows and widgets
>> draw as expected and with no noticeable change in rendering. Images
>> display fine, buttons work as expected, and text scrolls without any
>> delay. Redraw of the window in response to resizing also works OK. The
>> one area where I did notice a significant difference was in the widget
>> demo where a text widget is drawn with a large number of embedded
>> widgets, buttons, etc. There is lag in drawing the widgets when the text
>> is scrolled. Unfortunately, I haven't found any way to replace the calls
>> to private API's with equally optimized public API's; I assume that's
>> why the private calls are there in the first place.
>>
>> Because I've only found very limited cases of regression in the drawing
>> performance, I am willing to accept these in the service of removing the
>> calls to private API's. The private API access simply places
>> unacceptable limitations on distributing any app linking to Tk on the
>> Mac, and more generally gives Apple too much control over Tk's
>> functionality; calling private API's is not a good foundation for a GUI
>> toolkit.
>>
>> I've made the commits to core-8-5-branch in time for these changes to
>> make it into the upcoming release of Tcl/Tk 8.5.16, and whenever a new
>> release of 8.6 is made.
>>
>> Let me know if you have questions or concerns.
>>
>> Thanks,
>> Kevin
>>
>> --
>> Kevin Walzer
>> Code by Kevin/Mobile Code by Kevin
>> http://www.codebykevin.com
>> http://www.wtmobilesoftware.com

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

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

Kevin,

This all makes sense to me.  Thanks to you and Marc for for initiating the work and stewarding it to completion.

Steve 

> On 26 Jul 2014, at 2:32 am, Kevin Walzer <kw...@co...> wrote:
> 
> Hi all,
> 
> I'm writing to report on a couple of significant commits I have made to 
> Tk/Mac on both trunk and core-8-5-branch.
> 
> The first commit is based on an extensive patch provided by Marc Culler 
> that fixes alpha rendering in images under Tk Cocoa; some changes in 
> 10.9 Mavericks broke rendering of the alpha channel in images, so 
> transparency was no longer displayed (instead just ugly black shapes for 
> shadows, or nothing at all). Marc re-worked several functions to restore 
> this functionality, and I appreciate his work. Thanks so much to him for 
> taking the time to submit, re-work, and then re-submit the patch.
> 
> The second change involves removing several function calls into private, 
> undocumented Cocoa drawing methods. Some of these changes may be a bit 
> controversial, as they carry a performance penalty in certain contexts, 
> but I believe they are important and I wanted to explain why I have made 
> them.
> 
> As designed, Tk Cocoa attempts to map an X11 style of window drawing 
> onto the Cocoa graphics/windowing API. We're all aware that this is not 
> a seamless mapping. To improve the drawing performance and make the 
> rendering a bit cleaner, Daniel Steffen borrowed some techniques from 
> WebKit that involve calling into private, undocumented API's to give Tk 
> better, more fine-grained control of drawing in response to X11-style 
> "Expose" events.
> 
> Apple has always warned against using undocumented API's as they are 
> unsupported and subject to change. However, in 2009, when Daniel was 
> working on the Cocoa port, this seemed a very reasonable optimization to 
> make, as the example of WebKit was already out there, and the relevant 
> private API's had not been changed for several years.  Also, Apple did 
> not take any action against accessing private API's beyond discouraging 
> it as unsupported and occasionally changing the API's in question.
> 
> More recently, however, Apple has taken a harder line on using 
> undocumented API's by making it more difficult to distribute apps that 
> make use of such calls; these apps are not allowed in the Mac App Store, 
> which has become the main way of distributing apps on the Mac platform. 
> For instance, in the case of my own apps, this has prevented me from 
> shipping up-to-date Tk code with my apps, because the app store 
> restrictions forbid it.
> 
> I have worked around the issue by linking to the version of Tk bundled 
> with the operating system, which on my machine is 8.5.9. (This loophole 
> exists because Apple-installed libraries are exempted from their rules 
> on private API's.) Such workarounds are inherently fragile, however, as 
> they are dependent on Apple continuing to ship Tk with the operating 
> system. If Apple were to stop distributing Tk with OS X, then no app 
> making use of Tk as currently designed would be able to access Apple's 
> main distribution channel.
> 
> These changes in the Mac platform, combined with my general discomfort 
> with Tk accessing unsupported API's when other open-source languages and 
> frameworks do not, have led me to conclude that these calls need to be 
> removed. And that's what I've done.
> 
> In some cases, the removal of these calls causes no issue at all. A few 
> of the calls focused on accessing the "resize grip" on the lower corner 
> of a window. Apple removed the "resize grip" from windows in 10.7, so 
> there is no need for private API access here at all.
> 
> In other cases, there may be a performance hit in drawing especially 
> complex interfaces. I commented out an entire class designed by Daniel 
> that accesses private NSWindow/NSView API's, based on the example of 
> WebKit. My initial fear was that this would prevent drawing from 
> occurring at all, but that's not the case. I've done a fair amount of 
> testing with the widget demo, my own apps, and a couple of third-party 
> apps that link to Tk, and in virtually every context windows and widgets 
> draw as expected and with no noticeable change in rendering. Images 
> display fine, buttons work as expected, and text scrolls without any 
> delay. Redraw of the window in response to resizing also works OK. The 
> one area where I did notice a significant difference was in the widget 
> demo where a text widget is drawn with a large number of embedded 
> widgets, buttons, etc. There is lag in drawing the widgets when the text 
> is scrolled. Unfortunately, I haven't found any way to replace the calls 
> to private API's with equally optimized public API's; I assume that's 
> why the private calls are there in the first place.
> 
> Because I've only found very limited cases of regression in the drawing 
> performance, I am willing to accept these in the service of removing the 
> calls to private API's. The private API access simply places 
> unacceptable limitations on distributing any app linking to Tk on the 
> Mac, and more generally gives Apple too much control over Tk's 
> functionality; calling private API's is not a good foundation for a GUI 
> toolkit.
> 
> I've made the commits to core-8-5-branch in time for these changes to 
> make it into the upcoming release of Tcl/Tk 8.5.16, and whenever a new 
> release of 8.6 is made.
> 
> Let me know if you have questions or concerns.
> 
> Thanks,
> Kevin
> 
> -- 
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

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

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

Hi all,

I'm writing to report on a couple of significant commits I have made to 
Tk/Mac on both trunk and core-8-5-branch.

The first commit is based on an extensive patch provided by Marc Culler 
that fixes alpha rendering in images under Tk Cocoa; some changes in 
10.9 Mavericks broke rendering of the alpha channel in images, so 
transparency was no longer displayed (instead just ugly black shapes for 
shadows, or nothing at all). Marc re-worked several functions to restore 
this functionality, and I appreciate his work. Thanks so much to him for 
taking the time to submit, re-work, and then re-submit the patch.

The second change involves removing several function calls into private, 
undocumented Cocoa drawing methods. Some of these changes may be a bit 
controversial, as they carry a performance penalty in certain contexts, 
but I believe they are important and I wanted to explain why I have made 
them.

As designed, Tk Cocoa attempts to map an X11 style of window drawing 
onto the Cocoa graphics/windowing API. We're all aware that this is not 
a seamless mapping. To improve the drawing performance and make the 
rendering a bit cleaner, Daniel Steffen borrowed some techniques from 
WebKit that involve calling into private, undocumented API's to give Tk 
better, more fine-grained control of drawing in response to X11-style 
"Expose" events.

Apple has always warned against using undocumented API's as they are 
unsupported and subject to change. However, in 2009, when Daniel was 
working on the Cocoa port, this seemed a very reasonable optimization to 
make, as the example of WebKit was already out there, and the relevant 
private API's had not been changed for several years.  Also, Apple did 
not take any action against accessing private API's beyond discouraging 
it as unsupported and occasionally changing the API's in question.

More recently, however, Apple has taken a harder line on using 
undocumented API's by making it more difficult to distribute apps that 
make use of such calls; these apps are not allowed in the Mac App Store, 
which has become the main way of distributing apps on the Mac platform. 
For instance, in the case of my own apps, this has prevented me from 
shipping up-to-date Tk code with my apps, because the app store 
restrictions forbid it.

I have worked around the issue by linking to the version of Tk bundled 
with the operating system, which on my machine is 8.5.9. (This loophole 
exists because Apple-installed libraries are exempted from their rules 
on private API's.) Such workarounds are inherently fragile, however, as 
they are dependent on Apple continuing to ship Tk with the operating 
system. If Apple were to stop distributing Tk with OS X, then no app 
making use of Tk as currently designed would be able to access Apple's 
main distribution channel.

These changes in the Mac platform, combined with my general discomfort 
with Tk accessing unsupported API's when other open-source languages and 
frameworks do not, have led me to conclude that these calls need to be 
removed. And that's what I've done.

In some cases, the removal of these calls causes no issue at all. A few 
of the calls focused on accessing the "resize grip" on the lower corner 
of a window. Apple removed the "resize grip" from windows in 10.7, so 
there is no need for private API access here at all.

In other cases, there may be a performance hit in drawing especially 
complex interfaces. I commented out an entire class designed by Daniel 
that accesses private NSWindow/NSView API's, based on the example of 
WebKit. My initial fear was that this would prevent drawing from 
occurring at all, but that's not the case. I've done a fair amount of 
testing with the widget demo, my own apps, and a couple of third-party 
apps that link to Tk, and in virtually every context windows and widgets 
draw as expected and with no noticeable change in rendering. Images 
display fine, buttons work as expected, and text scrolls without any 
delay. Redraw of the window in response to resizing also works OK. The 
one area where I did notice a significant difference was in the widget 
demo where a text widget is drawn with a large number of embedded 
widgets, buttons, etc. There is lag in drawing the widgets when the text 
is scrolled. Unfortunately, I haven't found any way to replace the calls 
to private API's with equally optimized public API's; I assume that's 
why the private calls are there in the first place.

Because I've only found very limited cases of regression in the drawing 
performance, I am willing to accept these in the service of removing the 
calls to private API's. The private API access simply places 
unacceptable limitations on distributing any app linking to Tk on the 
Mac, and more generally gives Apple too much control over Tk's 
functionality; calling private API's is not a good foundation for a GUI 
toolkit.

I've made the commits to core-8-5-branch in time for these changes to 
make it into the upcoming release of Tcl/Tk 8.5.16, and whenever a new 
release of 8.6 is made.

Let me know if you have questions or concerns.

Thanks,
Kevin

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

Re: [MACTCL] Text widget issue with 8.5.15

[Trevor W. <pha...@me...>]

Okay, mystery solved (I believe).  Here is a webpage that describes what is going on and how to fix it.  Apparently, the behavior is one introduced in Lion and is intentional.  Good news is that it is modifiable.

Later,
Trevor

http://lifehacker.com/5826055/make-your-keyboard-keys-repeat-properly-when-held-down-in-mac-os-x-lion


On Jul 11, 2014, at 9:13 PM, Kevin Walzer <kw...@co...> wrote:

> On 7/11/14, 3:50 PM, Trevor Williams wrote:
>> In the 8.5.8 version, I can hold down any printable key, and the text widget will begin inserting that same character indefinitely until I release the key.  However, in the 8.5.15 version, holding down any printable key, will only insert a single key.  Interestingly, if I hold the key down, release it and then hit the backspace character, it takes a few backspace keystrokes before the character is actually deleted.  Anyone know why this is occurring and how I can get the old behavior back?
> 
> I see this with some keys (b, r) and not with others (e, a). I'm not 
> sure what is causing it. The implementation between Carbon and Cocoa is 
> different (completely different API's) and so the difference perhaps 
> lies there. It may not be solvable.
> 
> Is there a use case for indefinitely repeating a character with a single 
> keypress?
> 
> -- 
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Text widget issue with 8.5.15

[Trevor W. <pha...@me...>]

Excellent question about a use case.  In my case, yes.  I have created a Vim-like binding for a text widget such that I can edit within a Tk text widget using Vim-like functionality.  So moving the cursor around and deleting characters is greatly enhanced by pressing and holding various keys when in command mode.  Not having this capability is going to be a deal-breaker for the Cocoa port if this issue cannot be solved.

Thanks,
Trevor


On Jul 11, 2014, at 9:13 PM, Kevin Walzer <kw...@co...> wrote:

> On 7/11/14, 3:50 PM, Trevor Williams wrote:
>> In the 8.5.8 version, I can hold down any printable key, and the text widget will begin inserting that same character indefinitely until I release the key.  However, in the 8.5.15 version, holding down any printable key, will only insert a single key.  Interestingly, if I hold the key down, release it and then hit the backspace character, it takes a few backspace keystrokes before the character is actually deleted.  Anyone know why this is occurring and how I can get the old behavior back?
> 
> I see this with some keys (b, r) and not with others (e, a). I'm not 
> sure what is causing it. The implementation between Carbon and Cocoa is 
> different (completely different API's) and so the difference perhaps 
> lies there. It may not be solvable.
> 
> Is there a use case for indefinitely repeating a character with a single 
> keypress?
> 
> -- 
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Text widget issue with 8.5.15

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

On 7/11/14, 3:50 PM, Trevor Williams wrote:
> In the 8.5.8 version, I can hold down any printable key, and the text widget will begin inserting that same character indefinitely until I release the key.  However, in the 8.5.15 version, holding down any printable key, will only insert a single key.  Interestingly, if I hold the key down, release it and then hit the backspace character, it takes a few backspace keystrokes before the character is actually deleted.  Anyone know why this is occurring and how I can get the old behavior back?

I see this with some keys (b, r) and not with others (e, a). I'm not 
sure what is causing it. The implementation between Carbon and Cocoa is 
different (completely different API's) and so the difference perhaps 
lies there. It may not be solvable.

Is there a use case for indefinitely repeating a character with a single 
keypress?

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

Re: [MACTCL] Text widget issue with 8.5.15

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

I'm not seeing this in 8.6.1, and I don't remember seeing it in 8.5.15 either.  Odd.

Will

On Jul 11, 2014, at 12:50 PM, Trevor Williams <pha...@gm...> wrote:

> All,
> 
> Yesterday, I updated my Tcl/Tk installation from 8.5.8 (carbon-based version apparently) to 8.5.15 (cocoa-based).  Fortunately, my issue with the resizing grip has been resolved (the cocoa version does not use the resize grip that the carbon version uses -- you can resize by pulling from any corner/side of the window).  Unfortunately, it appears that a behavior of the text widget seems to have changed.
> 
> In the 8.5.8 version, I can hold down any printable key, and the text widget will begin inserting that same character indefinitely until I release the key.  However, in the 8.5.15 version, holding down any printable key, will only insert a single key.  Interestingly, if I hold the key down, release it and then hit the backspace character, it takes a few backspace keystrokes before the character is actually deleted.  Anyone know why this is occurring and how I can get the old behavior back?
> 
> To attempt to reproduce the problem, simply pack a single text widget:
> 
>     pack [text .t]
> 
> Then insert a character multiple times by holding on the 'b' key (for instance).
> 
> My Tcl/Tk installation came from ActiveTcl using the Mac bundle (8.5.15 version).
> 
> Thanks for any help/insight that you can provide.
> 
> Thanks,
> Trevor
> ------------------------------------------------------------------------------
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac


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

[MACTCL] Text widget issue with 8.5.15

[Trevor W. <pha...@gm...>]

All,

Yesterday, I updated my Tcl/Tk installation from 8.5.8 (carbon-based version apparently) to 8.5.15 (cocoa-based).  Fortunately, my issue with the resizing grip has been resolved (the cocoa version does not use the resize grip that the carbon version uses -- you can resize by pulling from any corner/side of the window).  Unfortunately, it appears that a behavior of the text widget seems to have changed.

In the 8.5.8 version, I can hold down any printable key, and the text widget will begin inserting that same character indefinitely until I release the key.  However, in the 8.5.15 version, holding down any printable key, will only insert a single key.  Interestingly, if I hold the key down, release it and then hit the backspace character, it takes a few backspace keystrokes before the character is actually deleted.  Anyone know why this is occurring and how I can get the old behavior back?

To attempt to reproduce the problem, simply pack a single text widget:

     pack [text .t]

Then insert a character multiple times by holding on the 'b' key (for instance).

My Tcl/Tk installation came from ActiveTcl using the Mac bundle (8.5.15 version).

Thanks for any help/insight that you can provide.

Thanks,
Trevor

Re: [MACTCL] Top-level resizing grip on Mac

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

On 7/10/14, 3:28 PM, Trevor Williams wrote:
> I am using the stock version on my Mac.  Version 8.5.8 (or 9) I believe
> -- uses X11 server.  I'm also seeing the same resizing grip in the
> Tcl/Tk framework that I include with the app bundle (which I believe is
> 8.5.9).
>
> Which version should I be using that is Cocoa based?

I can't speak to what the X11 version shows--that's the standard Unix one.

I'd switch to to the current release of 8.5 on Aqua--that's 8.5.15 and 
that's Cocoa-based.

--Kevin

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

Re: [MACTCL] Top-level resizing grip on Mac

[Trevor W. <pha...@ic...>]

I am using the stock version on my Mac.  Version 8.5.8 (or 9) I believe -- uses X11 server.  I'm also seeing the same resizing grip in the Tcl/Tk framework that I include with the app bundle (which I believe is 8.5.9).

Which version should I be using that is Cocoa based?

Thanks,
Trevor

On Jul 10, 2014, at 09:17 AM, Kevin Walzer <kw...@co...> wrote:

> On 7/10/14, 9:05 AM, Trevor Williams wrote:
>        > Does anyone know if it is possible to remove the resizing grip "square" in toplevel windows on the Mac? Unfortunately, this widget is placed above anything that I have packed in the lower right-hand corner of the window, and, quite frankly, it's pretty ugly compared to all other (non-Tk) windows found in Mac OSX.
>        >
>        > Any help would be appreciated.
>        >
>        > Thanks,
>        > Trevor
>
> The resize grip is a relic of Carbon-Tk and isn't included with current
> versions of Tk. What version of Tk are you using? Switching to Cocoa
> should remove it.
>
>
> -- 
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Top-level resizing grip on Mac

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

On 7/10/14, 9:05 AM, Trevor Williams wrote:
> Does anyone know if it is possible to remove the resizing grip "square" in toplevel windows on the Mac?  Unfortunately, this widget is placed above anything that I have packed in the lower right-hand corner of the window, and, quite frankly, it's pretty ugly compared to all other (non-Tk) windows found in Mac OSX.
>
> Any help would be appreciated.
>
> Thanks,
> Trevor

The resize grip is a relic of Carbon-Tk and isn't included with current 
versions of Tk. What version of Tk are you using? Switching to Cocoa 
should remove it.


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

Re: [MACTCL] Top-level resizing grip on Mac

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

If you set the window to be not resizable (e.g., wm resizable . 0 0) then it will not show the resize grip.




On 2014.7.10, at 16:05, Trevor Williams <pha...@gm...> wrote:

> Does anyone know if it is possible to remove the resizing grip "square" in toplevel windows on the Mac?  Unfortunately, this widget is placed above anything that I have packed in the lower right-hand corner of the window, and, quite frankly, it's pretty ugly compared to all other (non-Tk) windows found in Mac OSX.
> 
> Any help would be appreciated.
> 
> Thanks,
> Trevor
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

[MACTCL] Top-level resizing grip on Mac

[Trevor W. <pha...@gm...>]

Does anyone know if it is possible to remove the resizing grip "square" in toplevel windows on the Mac?  Unfortunately, this widget is placed above anything that I have packed in the lower right-hand corner of the window, and, quite frankly, it's pretty ugly compared to all other (non-Tk) windows found in Mac OSX.

Any help would be appreciated.

Thanks,
Trevor

Re: [MACTCL] To Do 02-JUL-14

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

Dear List Users,

> I think you may have sent this to the wrong group. 

Please accept my apologies for this error.

Yours, Kevan

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

[MACTCL] To Do 02-JUL-14

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

I'll be in at 1 pm today, Wednesday. Tomorrow 11 am group meeting.

(1) I have a package in the Physics office. It may contain CCDs for your 
work with Hermann. Feel free to fetch it. (Richard)

(2) Make a tight coil of our 62-um core rad-hard fiber, with its jacket 
stripped off, maybe 10 cm in diameter, for our upcoming neutron test. 
Put an FC connector on both ends. The coil should contain 5 m of fiber. 
Measure the fraction of blue light that reaches the far end once 
injected at the near end. (MichaelM)

(3) Measure how much more light is captured by our new 100-um core fiber 
than our existing 62-um core fiber, when pressed against and EZ500 LED. 
Measure how much more light is launched towards a camera 1 m distant 
along the fiber axis. (MichaelM)

(4) There are several old injector blocks with LED boards in a bag. Test 
them and try to salvage some for our existing work. (Richard)

(5) Discuss the specification of the new Programmable Logic Head 
(A2081). (Richard and Kevan)

(6) Finish the layout of the prototype buck regulator circuit board, 
A208001A. (Yuxin)

(7) Submit A208001A board for fabrication. (Kevan)

(8) Buy some ferrules. (Kevan)

(9) When the new A207901D circuit boards come in, load them with Luxeon 
Z LEDs and test them. Using the excellent pulse generator you have 
built, and the gig for holding the circuit board and a ferrule, measure 
capture efficiency for a fiber pressed against the LED surface. (MichaelF)

(10) Glue one fiber jumper 115 mm long with an FC on one end and our 
last remaining ferrule on the other end. Leave the fiber and glue on 
both ends. This is for me to polish in a demonstration video. We will 
get one take only. (MichaelM)

Re: [MACTCL] ttk::style on Mac

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

On 6/28/14, 11:38 PM, Trevor Williams wrote:

> Using the X11-based version of wish, this works as expected when I use the following code snippet:
>
> tablelist::tablelist .tl -background [ttk::style lookup TLabel -background]
>
> with a clam theme, the background turns a shade of grey.  However, when I use the same code snippet on Mac OSX (version 8.5.9 on Mavericks), the background is white.  In doing some basic debugging, I found that the return value of the forementioned ttk::style lookup call is a value of "systemWindowBody".  Making the following call:
>
> winfo rgb . systemWindowBody
>
> returns an integer value of white.  However, when a ttk::label is displayed to the window, its color is a shade of grey.
>
> Can anyone tell me what is going on here and what I might be doing wrong?


I don't think the Mac-native system colors can be accurately specified 
in RGB; you may simply be better off wrapping the tablelist 
configuration call in something like this:

if [tk windowingsystem ] = eq "aqua" {
	.tl configure -background systemWindowBody
}

or whatever you want to use. See the "colors" man page for a list and 
experiment.

--Kevin

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

[MACTCL] ttk::style on Mac

[Trevor W. <pha...@gm...>]

Hi everyone!

I have a Tcl/Tk application which primarily uses ttk widgets; however, there are a few widgets which do not and I would like to change their background color to be the same color as the standard ttk::label.

Using the X11-based version of wish, this works as expected when I use the following code snippet:

tablelist::tablelist .tl -background [ttk::style lookup TLabel -background]

with a clam theme, the background turns a shade of grey.  However, when I use the same code snippet on Mac OSX (version 8.5.9 on Mavericks), the background is white.  In doing some basic debugging, I found that the return value of the forementioned ttk::style lookup call is a value of "systemWindowBody".  Making the following call:

winfo rgb . systemWindowBody

returns an integer value of white.  However, when a ttk::label is displayed to the window, its color is a shade of grey.

Can anyone tell me what is going on here and what I might be doing wrong?

Thanks,
Trevor Williams

Re: [MACTCL] Issue with %x and %y in binding tkinter event

[Adam U. <up...@be...>]

No, thats great. That is exactly what I want. Thanks for the help!

Adam 

On May 20, 2014, at 3:07 PM, Damon Courtney <da...@tc...> wrote:

> I would see that as more a mistake on the Windows and Linux side. There’s absolutely no reason a KEY event should return the current coordinates of the MOUSE. :) Other than just trying to be complete, but I’m actually surprised that works on any platform. I wouldn’t have expected it to at all.
> 
> Either way, you can use [winfo pointerx $toplevel] and [winfo pointery $toplevel] (or [winfo pointerxy $toplevel] for both at once) to get the mouse coordinates. Unless I’m missing what is being asked for, in which case, I’ll shut up. :)
> 
> Damon
> 
> 
> On May 20, 2014, at 5:01 PM, Kevin Walzer <kw...@co...> wrote:
> 
>> On 5/20/14, 5:48 PM, Adam Updegrove wrote:
>>> Hello,
>>> 
>>> I am currently working on developing a GUI in mac. I am using tcl/tk 8.5.
>>> I am encountering an issue where the %x and %y for tkinter are returning the same value (negative values) no matter where my cursor is for a KeyPress. %X and %Y return 0 values.
>>> In Ubuntu and Windows, the same exact code returns the values I actually want.
>>> 
>>> I was wondering if anyone has seen something similar?
>> 
>> It's a known issue, but I haven't found a workable fix for it.
>> 
>> --Kevin
>> 
>> -- 
>> Kevin Walzer
>> Code by Kevin/Mobile Code by Kevin
>> http://www.codebykevin.com
>> http://www.wtmobilesoftware.com
>> 
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos.
>> Get unparalleled scalability from the best Selenium testing platform available
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> Tcl-mac mailing list
>> tc...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 
> 
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Issue with %x and %y in binding tkinter event

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

I would see that as more a mistake on the Windows and Linux side. There’s absolutely no reason a KEY event should return the current coordinates of the MOUSE. :) Other than just trying to be complete, but I’m actually surprised that works on any platform. I wouldn’t have expected it to at all.

Either way, you can use [winfo pointerx $toplevel] and [winfo pointery $toplevel] (or [winfo pointerxy $toplevel] for both at once) to get the mouse coordinates. Unless I’m missing what is being asked for, in which case, I’ll shut up. :)

Damon


On May 20, 2014, at 5:01 PM, Kevin Walzer <kw...@co...> wrote:

> On 5/20/14, 5:48 PM, Adam Updegrove wrote:
>> Hello,
>> 
>> I am currently working on developing a GUI in mac. I am using tcl/tk 8.5.
>> I am encountering an issue where the %x and %y for tkinter are returning the same value (negative values) no matter where my cursor is for a KeyPress. %X and %Y return 0 values.
>> In Ubuntu and Windows, the same exact code returns the values I actually want.
>> 
>> I was wondering if anyone has seen something similar?
> 
> It's a known issue, but I haven't found a workable fix for it.
> 
> --Kevin
> 
> -- 
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
> 
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Issue with %x and %y in binding tkinter event

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

On 5/20/14, 5:48 PM, Adam Updegrove wrote:
> Hello,
>
> I am currently working on developing a GUI in mac. I am using tcl/tk 8.5.
> I am encountering an issue where the %x and %y for tkinter are returning the same value (negative values) no matter where my cursor is for a KeyPress. %X and %Y return 0 values.
> In Ubuntu and Windows, the same exact code returns the values I actually want.
>
> I was wondering if anyone has seen something similar?

It's a known issue, but I haven't found a workable fix for it.

--Kevin

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