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

Re: [MACTCL] Successful submission to App Store

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

> I'm really disappointed! Starkit with well known basekit are so easier to maintain and deploy.
> 
> At least, it seems it works if I rename my starkit AppMain.tcl and copy it in MyApp.app/Contents/Resources/Scripts/
> 
> But, there is "About Tcl & Tk" in menu and I can't remove it (with Tclkit I override it with .menu.apple). Is there a trick for this?
> 
> I also see wish8.5 from Apple framework doesn't handle correctly button's image for disabled state: I have a white rectangle instead of the shaded picture I have with basekit 8.5.9 :/
> 
> In fact, I'm falling back again in problems I've happily forgotten when I started to use Tclkit. For me, it looks like a huge step backward! :(
> 
> I really hope somebody knows how to use starkit without this _spin_lock_try API!

Yeah, Apple is shipping a fairly old version of Tcl/Tk with its base system, and I don't think Lion is going to improve that much.  Maybe a little.  The problem is that I don't think it's just this one little _spin_lock_try API call we're talking about.  According to Kevin's research, there are probably a lot of private APIs Tk is using, and it looks to be a daunting task to remove them all.  One which, really, only one person is qualified for.  And he's quite busy these days. 0-]

Kevin's solution so far has been to just build his own extensions to cover the shortfall in the base Tcl/Tk.  You can package your own extensions fairly easily, and they don't run afoul of Apple's guidelines if they don't call into private APIs.

Though I really think Apple should allow some kind of exception in this case since the Tcl/Tk with private APIs they're rejecting is the one THEY PAID to write!

D

Re: [MACTCL] Successful submission to App Store

[David Z. <zol...@lr...>]

Le 23 mars 2011 à 21:48, Kevin Walzer a écrit :

> David,
> 
> I suspect that there's no way you can  successfully submit with AT 
> basekits. My experience with bundling the Tcl/Tk Cocoa frameworks with 
> my app also led to initial rejection for private API's; they are 
> embedded in Tk-Cocoa all the way down. My approach was to link with the 
> version of Tk shipped with Snow Leopard--that worked around the private 
> API restriction because this version is installed by Apple itself.

Hi Kevin,

I'm really disappointed! Starkit with well known basekit are so easier to maintain and deploy.

At least, it seems it works if I rename my starkit AppMain.tcl and copy it in MyApp.app/Contents/Resources/Scripts/

But, there is "About Tcl & Tk" in menu and I can't remove it (with Tclkit I override it with .menu.apple). Is there a trick for this?

I also see wish8.5 from Apple framework doesn't handle correctly button's image for disabled state: I have a white rectangle instead of the shaded picture I have with basekit 8.5.9 :/

In fact, I'm falling back again in problems I've happily forgotten when I started to use Tclkit. For me, it looks like a huge step backward! :(

I really hope somebody knows how to use starkit without this _spin_lock_try API!

-- 
David Zolli
kr...@kr...
http://www.kroc.tk

Re: [MACTCL] Successful submission to App Store

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

On 3/23/11 12:04 PM, David Zolli wrote:
> Hi all,
>
> I tried to submit a small starpack to AppStore but it was rejected because my uses non-public APIs. In resolution Center the detail is :
>
> The app includes "_spin_lock_try" from the framework .
>
> I paste "as is" so I think the space at the end means 'no framework'.
>
> My starpack was built with ActiveState Basekit 8.5.9.
>
> Does this mean something for you ?
>
> How can I find the part using _spin_lock_try ?
>

David,

I suspect that there's no way you can  successfully submit with AT 
basekits. My experience with bundling the Tcl/Tk Cocoa frameworks with 
my app also led to initial rejection for private API's; they are 
embedded in Tk-Cocoa all the way down. My approach was to link with the 
version of Tk shipped with Snow Leopard--that worked around the private 
API restriction because this version is installed by Apple itself.

Here's a link with more info:

http://www.codebykevin.com/opensource/app-store.html

Thanks,
Kevin

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

Re: [MACTCL] Successful submission to App Store

[David Z. <zol...@lr...>]

Hi all,

I tried to submit a small starpack to AppStore but it was rejected because my uses non-public APIs. In resolution Center the detail is :

The app includes "_spin_lock_try" from the framework . 

I paste "as is" so I think the space at the end means 'no framework'.

My starpack was built with ActiveState Basekit 8.5.9.

Does this mean something for you ?

How can I find the part using _spin_lock_try ?

-- 
David Zolli
kr...@kr...
http://www.kroc.tk

Re: [MACTCL] problem running Aqua wish -- "not built with CoreFoundation support"

[K S. <kis...@ya...>]

Hi,

OK, I have noticed a couple of problems with this script, and in my case it caused the default Tcl/Tk installed on the system (8.5.7) instead of the local Tcl/Tk (8.5.9) to be run. I think I have corrected this problem now. Hopefully this will also fix my user's problem.

Thanks for your help, Kevin. I would not have looked at the generated script in detail without your input!

Cheers,

Kish

--- On Mon, 14/3/11, K Shen <kis...@ya...> wrote:
> 
> #! /bin/sh
> ECLIPSEDIR="${ECLIPSEDIR:-/Users/kish/Tests/Eclipse6.0_168}"
> DYLD_LIBRARY_PATH="$ECLIPSEDIR/lib/x86_64_macosx:/Users/kish/Tests/Eclipse6.0_168/tcltk/x86_64_macosx/lib:$DYLD_LIBRARY_PATH"
> DYLD_FRAMEWORK_PATH="/Users/kish/Tests/Eclipse6.0_168/tcltk/Library/Frameworks:$DYLD_FRAMEWORK_PATH"
> TCL_LIBRARY="${TCL_LIBRARY:-/Users/kish/Tests/Eclipse6.0_168/tcltk/x86_64_macosx/lib/tcl8.5}"
> TK_LIBRARY="${TK_LIBRARY:-/Users/kish/Tests/Eclipse6.0_168/tcltk/x86_64_macosx/lib/tk8.5}"
> DAVINCIHOME="${DAVINCIHOME:-$ECLIPSEDIR/daVinci/x86_64_macosx}"
> JRE_HOME="${JRE_HOME:-/Library/Java/JavaVirtualMachines/1.6.0_22-b04-307.jdk/Contents/Home}"
> export ECLIPSEDIR TCL_LIBRARY TK_LIBRARY
> DYLD_FRAMEWORK_PATH DYLD_LIBRARY_PATH DAVINCIHOME JRE_HOME
> exec
> "/Users/kish/Tests/Eclipse6.0_168/tcltk/x86_64_macosx/bin/wish8.5"
> "/Users/kish/Tests/Eclipse6.0_168/lib_tcl/tkeclipse.tcl" --
> "$@"
> 
> The Tcl/Tk tarball was installed in
> 
> /Users/kish/Tests/Eclipse6.0_168/tcltk/x86_64_macosx
> 
> Note that in the above, DYLD_LIBRARY_PATH is not set to
> point to
> 
> /Users/kish/Tests/Eclipse6.0_168/tcltk/x86_64_macosx/lib,
> 
> which is where the X11 libtcl libtk are, so they should not
> be found.
> 
> 
> Cheers,
> 
> Kish
> 
> > -- Kevin Walzer
> > Code by Kevin
> > http://www.codebykevin.com
> > 
> 
> 
>       
> 
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 


      

Re: [MACTCL] problem running Aqua wish -- "not built with CoreFoundation support"

[K S. <kis...@ya...>]

Hi Kevin,

--- On Mon, 14/3/11, Kevin Walzer <kw...@co...> wrote:

> Tk is actually a Tcl package, so when you are running with,
> you are actually running Tcl, the interpreter.
> 

I understand that. I don't really understand how the Apple framework works. In the case of other Unix (and also when I run the X11 version), I expect that when I run wish, then libtcl8.5.dylib and libtk8.5.dylib
will be loaded. My question with the Aqua version of Tk is, how does it find the libtcl.dylib? From what I can tell of the error message, it found some Tcl that is built without CoreFoundation support.

Having said this, I took a look at the configure for Tcl in the unix directory. There is also a --enable-corefoundation flag here, and the default is supposed to be on also, so it looks like my "X11" build of Tcl (it is not really X11 as it does not use X11) should have CoreFoundation support also...

> How has your user installed Tcl/Tk? How are you
> distributing the packages?
> 

The tcl/tk is distributed as a tarball, and the user install this as in ohter Unix systems (i.e. untar the tarball and run a script to set the environment variables to localise things). I should add that when the user reported the problem, I downloaded the tarball and installed that in the same way, and that still work (i.e. I wasn't using the version I built). Of course, there may still be some environment setting that is different.

I should also say I build every with the --prefix set to my own directory (so that it does not go into /usr/local), so this directory
has:

Applications    Library         bin             include         lib


where the frameworks are in Library/Frameworks, and the (X11) libtk libtcl are in lib etc.

This is then packed into a tarball. When the localisation script is run,
then scripts for running our system is set. Here is the one for running Aqua Tcl/Tk (this is in the version I downloaded):

#! /bin/sh
ECLIPSEDIR="${ECLIPSEDIR:-/Users/kish/Tests/Eclipse6.0_168}"
DYLD_LIBRARY_PATH="$ECLIPSEDIR/lib/x86_64_macosx:/Users/kish/Tests/Eclipse6.0_168/tcltk/x86_64_macosx/lib:$DYLD_LIBRARY_PATH"
DYLD_FRAMEWORK_PATH="/Users/kish/Tests/Eclipse6.0_168/tcltk/Library/Frameworks:$DYLD_FRAMEWORK_PATH"
TCL_LIBRARY="${TCL_LIBRARY:-/Users/kish/Tests/Eclipse6.0_168/tcltk/x86_64_macosx/lib/tcl8.5}"
TK_LIBRARY="${TK_LIBRARY:-/Users/kish/Tests/Eclipse6.0_168/tcltk/x86_64_macosx/lib/tk8.5}"
DAVINCIHOME="${DAVINCIHOME:-$ECLIPSEDIR/daVinci/x86_64_macosx}"
JRE_HOME="${JRE_HOME:-/Library/Java/JavaVirtualMachines/1.6.0_22-b04-307.jdk/Contents/Home}"
export ECLIPSEDIR TCL_LIBRARY TK_LIBRARY DYLD_FRAMEWORK_PATH DYLD_LIBRARY_PATH DAVINCIHOME JRE_HOME
exec "/Users/kish/Tests/Eclipse6.0_168/tcltk/x86_64_macosx/bin/wish8.5" "/Users/kish/Tests/Eclipse6.0_168/lib_tcl/tkeclipse.tcl" -- "$@"

The Tcl/Tk tarball was installed in

/Users/kish/Tests/Eclipse6.0_168/tcltk/x86_64_macosx

Note that in the above, DYLD_LIBRARY_PATH is not set to point to

/Users/kish/Tests/Eclipse6.0_168/tcltk/x86_64_macosx/lib,

which is where the X11 libtcl libtk are, so they should not be found.


Cheers,

Kish

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


      

Re: [MACTCL] problem running Aqua wish -- "not built with CoreFoundation support"

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

On 3/13/11 8:28 PM, K Shen wrote:

> For me, the X11 and Aqua versions both work, and are different
> (i.e. they are not somehow running the same thing). For my user, the X11 version works, so from what you are suggesting. perhaps when he ran the Aqua version, he somehow got tangled with the X11 version?
>
> His error message is complaining about Tcl not being built with corefoundation. How is Tcl invoked from within Tk? From what you have said, it does look like in his case, he is invoking the X11 version of tcl, which does not have core foundation support, whereas in my case, I run the correct version of Tcl?

Tk is actually a Tcl package, so when you are running with, you are 
actually running Tcl, the interpreter.

How has your user installed Tcl/Tk? How are you distributing the packages?



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

Re: [MACTCL] problem running Aqua wish -- "not built with CoreFoundation support"

[K S. <kis...@ya...>]

Hi Kevin,

--- On Sun, 13/3/11, Kevin Walzer <kw...@co...> wrote:
> It's not entirely clear to me how you can build both X11
> and Aqua 
> versions of Tk, unless they are installed in different
> places.
> 

Well, the Aqua Tcl/Tk is each built as a Framework, but the X11 Tcl/Tk is built as in normal Unix, with the .dylib files placed in $prefix/lib.

I also renamed the X11 wish as xwish (although not tclsh, as I don't
explicitly call tclsh myself).


> The only thing I can think of is that you have mixed up
> your X11 and Framework. 
> Aqua builds, gotten them tangled up. Have you tried
> separating them out?
> 

For me, the X11 and Aqua versions both work, and are different
(i.e. they are not somehow running the same thing). For my user, the X11 version works, so from what you are suggesting. perhaps when he ran the Aqua version, he somehow got tangled with the X11 version? 

His error message is complaining about Tcl not being built with corefoundation. How is Tcl invoked from within Tk? From what you have said, it does look like in his case, he is invoking the X11 version of tcl, which does not have core foundation support, whereas in my case, I run the correct version of Tcl?

Cheers,

Kish



      

Re: [MACTCL] problem running Aqua wish -- "not built with CoreFoundation support"

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

Hi Kish,

On 3/13/11 6:59 PM, K Shen wrote:

> I build a Tcl/Tk 8.5.9 from source so that it provides both Aqua and X11 versions of Tcl/Tk for use with my application. I build the Aqua version following the instructions in the macosx/README, with weak-linking for 10.5. For Unix. I build from the unix directory.

It's not entirely clear to me how you can build both X11 and Aqua 
versions of Tk, unless they are installed in different places.

>
> I am able to run both the X11 and Aqua wish on my own machine (an Intel iMac running Mac OS X 10.6), but I have just received a report from a user that
> he is unable to run the Aqua Tcl/Tk I distribute. He reports the following error:
>
> TclMacOSXNotifierAddRunLoopMode: Tcl not built with CoreFoundation support
> /Users/pmoura/Documents/Prolog/eclipse_6_0_168_x86_64_macosx/tcltk/x86_64_macosx/bin/wish8.5: line 2: 16972 Abort trap              "$(dirname $0)/../Library/Frameworks/Tk.framework/Versions/8.5/Resources/Wish.app/Contents/MacOS/Wish" "$@"
>
> He is running a 64bit Intel Mac OS X 10.6 machine as well, so I am not sure why he is getting this problem and I am not.
>
> As far as I can tell from the configure, --enable-corefoundation is a flag for configuring the Mac build of Tcl/Tk, but it is enabled by default, and I don't remember disabling it during the build.

--enable-corefoundation is the default, and is required for Aqua Tk. 
-disable-corefoundation is a flag you can pass for Unix/X11 builds of 
Wish, but I'm not sure if that is the default for Unix/X11 Tk.
>
> Does anyone have any idea what the problem might be, and why the Tcl/Tk can run on some Macs, but not others, even though they are both running the same version of Mac OS X? [I have tried running the Aqua Tcl/Tk on both 32 and 64 bit kernels, and it works for me on both]

The only thing I can think of is that you have mixed up your X11 and 
Aqua builds, gotten them tangled up. Have you tried separating them out?

--Kevin

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

[MACTCL] problem running Aqua wish -- "not built with CoreFoundation support"

[K S. <kis...@ya...>]

Hi,

I build a Tcl/Tk 8.5.9 from source so that it provides both Aqua and X11 versions of Tcl/Tk for use with my application. I build the Aqua version following the instructions in the macosx/README, with weak-linking for 10.5. For Unix. I build from the unix directory.

I am able to run both the X11 and Aqua wish on my own machine (an Intel iMac running Mac OS X 10.6), but I have just received a report from a user that
he is unable to run the Aqua Tcl/Tk I distribute. He reports the following error:

TclMacOSXNotifierAddRunLoopMode: Tcl not built with CoreFoundation support
/Users/pmoura/Documents/Prolog/eclipse_6_0_168_x86_64_macosx/tcltk/x86_64_macosx/bin/wish8.5: line 2: 16972 Abort trap              "$(dirname $0)/../Library/Frameworks/Tk.framework/Versions/8.5/Resources/Wish.app/Contents/MacOS/Wish" "$@"

He is running a 64bit Intel Mac OS X 10.6 machine as well, so I am not sure why he is getting this problem and I am not.

As far as I can tell from the configure, --enable-corefoundation is a flag for configuring the Mac build of Tcl/Tk, but it is enabled by default, and I don't remember disabling it during the build.

Does anyone have any idea what the problem might be, and why the Tcl/Tk can run on some Macs, but not others, even though they are both running the same version of Mac OS X? [I have tried running the Aqua Tcl/Tk on both 32 and 64 bit kernels, and it works for me on both]

Thanks and cheers,

Kish


      

[MACTCL] ANN: Three new Tk-Cocoa packages, plus one updated one

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

I'm pleased to announce the release of three new Tcl/Tk packages to 
improve the integration of Tk apps on the Mac, as well as an updated 
package.

Mactoolbar

This package creates a Mac-native toolbar (based on the Cocoa NSToolbar) 
for use in Tk windows. The mactoolbar package offers a basic 
implementation of the NSToolbar library; it displays toolbar buttons, 
with labels and images, and does not display other Mac-native widgets 
such as the Cocoa searchfield. It does not allow customization, nor can 
it display Tk widgets.

Prefstoolbar

This package creates a Mac-native toolbar (based on the Cocoa NSToolbar) 
for use in Tk windows. The The toolbar items are selectable, as in 
standard Cocoa preferences windows. The package offers a basic 
implementation of the NSToolbar library; it displays toolbar buttons, 
with labels and images, and does not display other Mac-native widgets 
such as the Cocoa searchfield. It does not allow customization, nor can 
it display Tk widgets.

Quicklook

The quicklook package displays a native QuickLook preview panel in a Tk 
application. The quicklook::quicklook path takes a file path as an 
argument and then displays a QuickLook panel of the file.

And, the updated package: cocoaprint. This new version fixes a serious 
bug that caused applications to crash after the print dialog is dismissed.

All packages are authored by Kevin Walzer, and are available from 
http://tk-components.sourceforge.net/ under the standard Tcl BSD-style 
license.

Enjoy,
Kevin

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

Re: [MACTCL] Cocoa toolbar in Tk window--geometry/focus question

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

On 3/3/11 8:34 PM, Kevin Walzer wrote:

>>
>>
> Looks like I can achieve the required effect on a widget-by-widget
> basis, but there does not appear to be any general procedure or variable
> I can set at a global level that will get the job done.
>

On further inspection: no monkeypatching of widget bindings required. 
Creating the toolbar and then setting the unifiedTitleAndToolbar window 
flag via the MacWindowStyle command does the trick:

tk::unsupported::MacWindowStyle style .f document 
{unifiedTitleAndToolbar standardDocument}

That seems to map the toolbar into the Tk window geometry and the rest 
of the widget geometry is correct.

--Kevin


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

Re: [MACTCL] Cocoa toolbar in Tk window--geometry/focus question

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

On 3/3/11 11:16 AM, Kevin Walzer wrote:
> I'm making substantial process on my library to add Cocoa NSToolbars to
> Tk windows. At present the library creates the toolbar, populates it
> with buttons, images, labels, tooltips, etc., and passes commands on to
> the Tcl interpreter to execute. So far, so good.
>
> I am running into an unexpected issue, however. The toolbar appears to
> mess up the tracking of mouse coordinates in the Tk widgets. For
> instance, in a test script with a ttk entry, the entry does not gain
> focus when the mouse pointer is directly over it, but rather about 54
> pixels higher on the screen. With some trial and error, I can force
> focus to the entry with this binding:
>
> bind all<Button-1>  {focus -force [winfo containing %X  [expr %Y - 54]]}
>
> However, that only sets focus on the entry field, not its insertion
> point, nor does the cursor change to a text insert cursor when hovered
> directly over the entry, but rather when it is located about 50 pixels
> above it.
>
> Additionally, a button command does not fire when the button is pressed,
> but rather when<Button-1>  is pressed about 50 pixels above the button.
>
> I think I understand what is going on here: the toolbar is part of the
> window chrome, not Tk's widgets, and it takes up a lot of real estate. I
> believe default Tk-Mac window geometry is based on a height of 22 pixels
> for the title bar, after which Tk's real estate beings.
>
> What would be the right way to fix this? Override some of the default
> bindings for widgets with some cursor mapping procedure as above, or is
> there a different solution I'm not thinking of?
>
> --Kevin
>
>
Looks like I can achieve the required effect on a widget-by-widget 
basis, but there does not appear to be any general procedure or variable 
I can set at a global level that will get the job done.

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

[MACTCL] Cocoa toolbar in Tk window--geometry/focus question

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

I'm making substantial process on my library to add Cocoa NSToolbars to 
Tk windows. At present the library creates the toolbar, populates it 
with buttons, images, labels, tooltips, etc., and passes commands on to 
the Tcl interpreter to execute. So far, so good.

I am running into an unexpected issue, however. The toolbar appears to 
mess up the tracking of mouse coordinates in the Tk widgets. For 
instance, in a test script with a ttk entry, the entry does not gain 
focus when the mouse pointer is directly over it, but rather about 54 
pixels higher on the screen. With some trial and error, I can force 
focus to the entry with this binding:

bind all <Button-1> {focus -force [winfo containing %X  [expr %Y - 54]]}

However, that only sets focus on the entry field, not its insertion 
point, nor does the cursor change to a text insert cursor when hovered 
directly over the entry, but rather when it is located about 50 pixels 
above it.

Additionally, a button command does not fire when the button is pressed, 
but rather when <Button-1> is pressed about 50 pixels above the button.

I think I understand what is going on here: the toolbar is part of the 
window chrome, not Tk's widgets, and it takes up a lot of real estate. I 
believe default Tk-Mac window geometry is based on a height of 22 pixels 
for the title bar, after which Tk's real estate beings.

What would be the right way to fix this? Override some of the default 
bindings for widgets with some cursor mapping procedure as above, or is 
there a different solution I'm not thinking of?

--Kevin


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

Re: [MACTCL] error building tk 8.5.8 on OS X 10.6

[sinnfluter <JRa...@gm...>]

Rich E-2 wrote:
> 
> Hi again,
> 
> I get the following warnings and errors when I try to build Tk 8.5.8 on OS
> X
> 10.6 Snow Leopard.  Anyone have an idea as to why?
> 
> 
> 
> 
> Hey!
> 
> Did you fix your problem and could you tell me how??
> I tried to install tcl/tk 8.5.8 on OS X 10.6.2 as well and got exactly the
> same error messages.
> 
> For tcl, I did the following:
> 
> ./configure --enable-framework
> make
> sudo make install
> 
> which worked perfectly fine but for tk I got the above mentioned errors.
> 
> I'm a total unix and mac newbie and have no clue where my mistake is. I
> tried to set CFLAGS='-arch i386' as proposed by Daniel but this didn't
> work either. Maybe I did something wrong there (I really just tried
> ./configure --enable-framework CFLAGS='-arch i386' which might be
> nonsense...?!).
> 
> Please help me!
> 
> 
> 
> 
> 

-- 
View this message in context: http://old.nabble.com/error-building-tk-8.5.8-on-OS-X-10.6-tp27167210p31039842.html
Sent from the tcl-mac mailing list archive at Nabble.com.

Re: [MACTCL] control click menu over a Table (corrected)

[Robert K. <ro...@cr...>]

Thanks for the response.

bind .t.t <Control-ButtonRelease-1> stops the Table from activating the 
table cell
where I control-click to open the menu. I'm talking about something else.
while the menu is opened if you click on one of the menu items, it activates
the Table cell beneath that menu item after the popup menu closes. (This 
would be
applicable if your menu command's labels are long enough to appear over a 
different
Table cell than the one clicked on to open the menu.) I think the 
<ButtonRelease-1>
of the Table is still firing after the menu is gone. Interestingly it only 
activates the cell after
a delay, or until I touch the mouse.

To stop that I have to bind .t.t <ButtonRelease-1> {break}, but that's a 
bind I need in Table
for activating cells normally.

RK


On Thu, 24 Feb 2011 17:24:59 -0800
  Jeff Hobbs <je...@ac...> wrote:

> If you want to balance out your special binding, don't
>do all that extra cmd trickery, just add:
>
> bind .t.t <Control-ButtonRelease-1> { break }
>
> Jeff
>
> On 24/02/2011 7:50 AM, Robert Karen wrote:
>> sorry in my original email, I said 'rt click' a few
>>times and meant to say
>> 'control-click'. here is corrected version:
>>
>> Can someone tell me  what is going wrong here. I am
>>trying to bind
>> to control-click to open a menu in a Tktable/Table and
>>it continues
>> to catch the button-release in the table and select the
>>cell beneath
>> the menu element selected. the code below stops it by
>>modifying the
>> default bind for Table's ButtonRelease-1, but isn't
>>there a standard
>> way of managing control click tk_popup menu where I
>>shouldn't have to
>> modify the binding of Table? Thanks for any help. I ran
>>this with
>> wish 8.5.7.
>>
>> package require Tktable
>> toplevel .t
>> table .t.t -variable var
>> pack .t.t
>> menu .t.m
>> .t.m add command -label First -command {puts "first..."}
>> .t.m add command -label Second -command {puts
>>"second..."}
>> .t.m add command -label Third -command {tk_messageBox
>>-message "third..."}
>> set bindCmd [bind Table<ButtonRelease-1>]
>> append cmd "if {\[info exists menuOpen\]} \{"
>> append cmd $bindCmd
>> append cmd "\}"
>> puts "new bind cmd for Table's ButtonRelease-1 = $cmd"
>> bind Table<ButtonRelease-1>  $cmd
>> bind .t.t<Control-Button-1>  {
>>      set menuOpen 1
>>      tk_popup .t.m %X %Y
>>      unset menuOpen
>>      break
>> }

Re: [MACTCL] control click menu over a Table (corrected)

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

That is a standard problem in that the "exactness" means that the 
release event will not get caught, and is picked up by the Table class 
binding.

If you want to balance out your special binding, don't do all that extra 
cmd trickery, just add:

bind .t.t <Control-ButtonRelease-1> { break }

Jeff

On 24/02/2011 7:50 AM, Robert Karen wrote:
> sorry in my original email, I said 'rt click' a few times and meant to say
> 'control-click'. here is corrected version:
>
> Can someone tell me  what is going wrong here. I am trying to bind
> to control-click to open a menu in a Tktable/Table and it continues
> to catch the button-release in the table and select the cell beneath
> the menu element selected. the code below stops it by modifying the
> default bind for Table's ButtonRelease-1, but isn't there a standard
> way of managing control click tk_popup menu where I shouldn't have to
> modify the binding of Table? Thanks for any help. I ran this with
> wish 8.5.7.
>
> package require Tktable
> toplevel .t
> table .t.t -variable var
> pack .t.t
> menu .t.m
> .t.m add command -label First -command {puts "first..."}
> .t.m add command -label Second -command {puts "second..."}
> .t.m add command -label Third -command {tk_messageBox -message "third..."}
> set bindCmd [bind Table<ButtonRelease-1>]
> append cmd "if {\[info exists menuOpen\]} \{"
> append cmd $bindCmd
> append cmd "\}"
> puts "new bind cmd for Table's ButtonRelease-1 = $cmd"
> bind Table<ButtonRelease-1>  $cmd
> bind .t.t<Control-Button-1>  {
>      set menuOpen 1
>      tk_popup .t.m %X %Y
>      unset menuOpen
>      break
> }

Re: [MACTCL] control click menu over a Table (corrected)

[Robert K. <ro...@cr...>]

sorry in my original email, I said 'rt click' a few times and meant to say
'control-click'. here is corrected version:

Can someone tell me  what is going wrong here. I am trying to bind to 
control-click
to open a menu in a Tktable/Table and it continues to catch the 
button-release in the
table and select the cell beneath the menu element selected. the code below 
stops it
by modifying the default bind for Table's ButtonRelease-1, but isn't there a 
standard way of
managing control click tk_popup menu where I shouldn't have to modify the 
binding of
Table? Thanks for any help. I ran this with wish 8.5.7.

package require Tktable
toplevel .t
table .t.t -variable var
pack .t.t
menu .t.m
.t.m add command -label First -command {puts "first..."}
.t.m add command -label Second -command {puts "second..."}
.t.m add command -label Third -command {tk_messageBox -message "third..."}
set bindCmd [bind Table <ButtonRelease-1>]
append cmd "if {\[info exists menuOpen\]} \{"
append cmd $bindCmd
append cmd "\}"
puts "new bind cmd for Table's ButtonRelease-1 = $cmd"
bind Table <ButtonRelease-1> $cmd
bind .t.t <Control-Button-1> {
    set menuOpen 1
    tk_popup .t.m %X %Y
    unset menuOpen
    break
}

[MACTCL] rt click menu over a Table

[Robert K. <ro...@cr...>]

Can someone tell me  what is going wrong here. I am trying to bind to 
control-click
to open a menu in a Tktable/Table and it continues to catch the 
button-release in the
table and select the cell beneath the menu element selected. the code below 
stops it
by modifying the defautl bind for Table's ButtonRelease-1, but isn't there a 
standard way of
managing rt click popup menu where I shouldn't have to play with binding of 
Table? Thanks
for any help. I ran this with wish 8.5.7.

package require Tktable
toplevel .t
table .t.t -variable var
pack .t.t
menu .t.m
.t.m add command -label First -command {puts "first..."}
.t.m add command -label Second -command {puts "second..."}
.t.m add command -label Third -command {tk_messageBox -message "third..."}
set bindCmd [bind Table <ButtonRelease-1>]
append cmd "if {\[info exists menuOpen\]} \{"
append cmd $bindCmd
append cmd "\}"
puts "new bind cmd for Table's ButtonRelease-1 = $cmd"
bind Table <ButtonRelease-1> $cmd
bind .t.t <Control-Button-1> {
   set menuOpen 1
   tk_popup .t.m %X %Y
   unset menuOpen
   break
}

Re: [MACTCL] Real Cocoa toolbar in Tk

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

On 2/15/11 11:05 AM, Kevin Walzer wrote:

>
> Apparently this is harder than I expected.

After some further work: not that hard.

http://www.codebykevin.com/cocoa-toolbar-in-tk-window.png

I've put together a basic NSToolbar-in-Tk-window implementation that 
seems to work. You define a list of traits for the toolbar button (name, 
label, command, image, Tcl proc to execute) and then hand it over to 
Cocoa to render in the window. Pushing the button runs the Tcl 
procedure, just like a regular Tk button.

I'm not quite ready to release the code yet--I want to stress-test it in 
at least one shipping application, just to make sure it can handle it.

Another caveat is that the implementation is basic--it sets up basic 
buttons in a single NS toolbar in a toplevel window, which I am assuming 
will be the main application window. It doesn't support more than one 
toolbar, or fancy stuff in the toolbar (c.f. a native NSSearch field 
like you see in Safari), or the "selected" toolbar state that you see in 
Cocoa preferences windows. Such things are technically feasible but 
would add a lot of complexity to the implementation, which I don't have 
time for.

It also doesn't support drawing Tk widgets on the toolbar itself--such 
wizardry is, I suspect, beyond Tk's capabilities.

Still, I think this will cover the most common use cases nicely, and 
will make Tk applications that use the toolbar look a lot more native, 
since it is a real NSToolbar. An added bonus is that the toolbar will 
automatically reflect changes on Mac OS X.

More to come later, when I actually release it--hopefully in the next 
month or so.

Best,
Kevin



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

Re: [MACTCL] Real Cocoa toolbar in Tk

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

>
> On 2/9/11 5:59 PM, Kevin Walzer wrote:
>> I've been doing a bit of hacking with Tk again, and I've discovered how
>> to enable a real NSToolbar in a Tk window via a Tk extension. Here's a
>> screenshot:
>>
>> http://www.codebykevin.com/cocoa-toolbar.png
>>
>> This is in the very early stages, but I think it will be feasible for me
>> to write an entire wrapper for NSToolbar that will display native Mac
>> toolbar lbuttons.

Apparently this is harder than I expected.

I can display a toolbar frame in a Tk window if I'm doing so 
interactively from the console, but it doesn't work if I am running a 
script. I suspect this has something to do with the order of window 
creation.

Will do a bit more experimenting, but I may have to set this aside if I 
can't get it moving.

Of course, if anyone else has some interest in taking up this project, 
be my guest!

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

Re: [MACTCL] Real Cocoa toolbar in Tk

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

On 2/9/11 8:45 PM, Tim Jones wrote:

>
> Well, what are you waiting for?

Just enough time to work on it in a proper fashion. Soon.

>
> On a separate note, your work on the Mac side of TCL is deserving of a major Jolt award, or maybe even an Oscar for best technical advancement of an operating system.

Thanks. :-)

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

[MACTCL] Crashes in tkpath.

[Revar D. <rev...@gm...>]

On Nov 23, 2010, at 6:04 PM, Clifford Yapp wrote:

> Revar, are any of the files you have that are
> known to crash tkpath available to use as test cases or are they
> private/commercial?  Or, alternately, can you contrive a case that
> will provoke crashes and post that?

I have a file that will reproduce the crashes finally!  Unfortunately it is private and can't be distributed.  I'll see if I can alter it and/or simplify it until I can give it out.
In the meantime I have a crash log from it, if it helps any.



Process:         TkCAD [98822]
Path:            /Users/revar/dev/TkCAD/TkCAD.app/Contents/MacOS/TkCAD
Identifier:      com.tcltk.wish.tkcd
Version:         0.205 (0.205)
Code Type:       X86 (Native)
Parent Process:  launchd [280]

Date/Time:       2011-02-09 18:22:55.759 -0800
OS Version:      Mac OS X 10.6.6 (10J567)
Report Version:  6

Interval Since Last Report:          1433985 sec
Crashes Since Last Report:           73
Per-App Interval Since Last Report:  250562 sec
Per-App Crashes Since Last Report:   11
Anonymous UUID:                      594473A9-81D4-4B82-8DAF-2B84D9F4D748

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   Tcl                           	0x0a095ef7 TclpAlloc + 526
1   Tcl                           	0x0a0701e3 Tcl_LinkVar + 305
2   Tcl                           	0x0a07029a Tcl_NewListObj + 84
3   Tcl                           	0x0a01bf08 TclDumpMemoryInfo + 30541
4   Tcl                           	0x0a010c40 Tcl_GetVersion + 7407
5   Tcl                           	0x0a04b61b TclStackAlloc + 5210
6   Tcl                           	0x0a08a971 TclObjInterpProcCore + 1460
7   Tcl                           	0x0a010c40 Tcl_GetVersion + 7407
8   Tcl                           	0x0a04b61b TclStackAlloc + 5210
9   Tcl                           	0x0a08a971 TclObjInterpProcCore + 1460
10  Tcl                           	0x0a010c40 Tcl_GetVersion + 7407
11  Tcl                           	0x0a04b61b TclStackAlloc + 5210
12  Tcl                           	0x0a08a971 TclObjInterpProcCore + 1460
13  Tcl                           	0x0a010c40 Tcl_GetVersion + 7407
14  Tcl                           	0x0a011102 Tcl_EvalObjv + 59
15  Tcl                           	0x0a011fa3 TclEvalObjEx + 402
16  Tcl                           	0x0a017371 TclDumpMemoryInfo + 11190
17  Tcl                           	0x0a010c40 Tcl_GetVersion + 7407
18  Tcl                           	0x0a04b61b TclStackAlloc + 5210
19  Tcl                           	0x0a08a971 TclObjInterpProcCore + 1460
20  Tcl                           	0x0a010c40 Tcl_GetVersion + 7407
21  Tcl                           	0x0a04b61b TclStackAlloc + 5210
22  Tcl                           	0x0a08a971 TclObjInterpProcCore + 1460
23  Tcl                           	0x0a010c40 Tcl_GetVersion + 7407
24  Tcl                           	0x0a04b61b TclStackAlloc + 5210
25  Tcl                           	0x0a08a971 TclObjInterpProcCore + 1460
26  Tcl                           	0x0a010c40 Tcl_GetVersion + 7407
27  Tcl                           	0x0a04b61b TclStackAlloc + 5210
28  Tcl                           	0x0a08a971 TclObjInterpProcCore + 1460
29  Tcl                           	0x0a010c40 Tcl_GetVersion + 7407
30  Tcl                           	0x0a01185a Tcl_EvalObjv + 1939
31  Tcl                           	0x0a011bb6 Tcl_EvalEx + 46
32  Tk                            	0x0b007012 Tk_BindEvent + 4712
33  Tk                            	0x0b00bb6a TkBindEventProc + 325
34  Tk                            	0x0b013b6b Tk_HandleEvent + 1479
35  Tk                            	0x0b013c6a Tk_HandleEvent + 1734
36  Tcl                           	0x0a07b9d3 Tcl_ServiceEvent + 164
37  Tcl                           	0x0a07bc21 Tcl_DoOneEvent + 164
38  Tk                            	0x0b013594 Tk_MainLoop + 37
39  Tk                            	0x0b0207fa Tk_MainEx + 1865
40  TkCAD                         	0x000045d3 0x1000 + 13779
41  TkCAD                         	0x0000458f 0x1000 + 13711
42  TkCAD                         	0x000044bd 0x1000 + 13501

Thread 1:  Dispatch queue: com.apple.libdispatch-manager
0   libSystem.B.dylib             	0x940b9982 kevent + 10
1   libSystem.B.dylib             	0x940ba09c _dispatch_mgr_invoke + 215
2   libSystem.B.dylib             	0x940b9559 _dispatch_queue_invoke + 163
3   libSystem.B.dylib             	0x940b92fe _dispatch_worker_thread2 + 240
4   libSystem.B.dylib             	0x940b8d81 _pthread_wqthread + 390
5   libSystem.B.dylib             	0x940b8bc6 start_wqthread + 30

Thread 2:
0   libSystem.B.dylib             	0x940cead2 select$DARWIN_EXTSN$NOCANCEL + 10
1   libSystem.B.dylib             	0x94166fd7 select + 92
2   Tcl                           	0x0a0af743 Tcl_DeleteFileHandler + 898
3   libSystem.B.dylib             	0x940c085d _pthread_start + 345
4   libSystem.B.dylib             	0x940c06e2 thread_start + 34

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x00107eb0  ebx: 0x0a095cf4  ecx: 0x00000000  edx: 0x0a0d30f0
  edi: 0x00000004  esi: 0x00000070  ebp: 0xbfffc728  esp: 0xbfffc6c0
   ss: 0x0000001f  efl: 0x00010202  eip: 0x0a095ef7   cs: 0x00000017
   ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
  cr2: 0x00000000

Re: [MACTCL] Real Cocoa toolbar in Tk

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

On Feb 9, 2011, at 6:06 PM, Kevin Walzer wrote:

> On 2/9/11 6:33 PM, Tim Jones wrote:
>> Hi Kevin,
>> 
>> Your native toolbars seem to be missing...
>> 
>> Tim
>> 
> 
> Tim,
> 
> What do you mean here? There's no buttons or anything in the native 
> toolbar--I'm not that far yet. :-)

Well, what are you waiting for?  

On a separate note, your work on the Mac side of TCL is deserving of a major Jolt award, or maybe even an Oscar for best technical advancement of an operating system.

Tim

Re: [MACTCL] Real Cocoa toolbar in Tk

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

On 2/9/11 6:33 PM, Tim Jones wrote:
> Hi Kevin,
>
> Your native toolbars seem to be missing...
>
> Tim
>

Tim,

What do you mean here? There's no buttons or anything in the native 
toolbar--I'm not that far yet. :-)

K

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