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

Re: [MACTCL] building universal tkImg-1.4.13

[Uwe K. <Uwe...@gm...>]

Hello Bernd, Christopher,
thank you very much for your feedback! I managed to build successfully for the x86_64 architecture.

I still did not manage building for the arm64 architecture. There are two roadblocks (I use macOS 13 Ventura Beta 5) which may both be related to the configure script not resolving the target platform correctly.

The target on Intel Mac is "x86_64-apple-darwin19.6.0“ —> works
The target on my M1 Mac is "arm64-apple-darwin22.0.0“ —> does not work —> „windows"

- my guess is the configure script cannot determine the system platform for "arm64-apple-darwin22.0.0“ and assumes „windows“ and therefore enables „-static-libgcc“ CFLAGS. This is not supported by clang and produces a fatal error. I worked araound that by commenting out the respective line in tcl.m4

- next thing is I run into arm neon errors at the link stage of libpng: (undefined symbols _png_do_expand_palette_rgb8_neon, etc…). I browsed throug the bug reports and found that in the past Linux users had reported the same issue.

@Christopher: is that fixed in the SVN revision 569 that you mentioned to me and how can I download that?

I noticed that in the various config.guess there is no mention of "arm" in the „Darwin“ section:

    *:Darwin:*:*)
	UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown
	eval "$set_cc_for_build"
	if test "$UNAME_PROCESSOR" = unknown ; then
	    UNAME_PROCESSOR=powerpc
	fi
	if test "`echo "$UNAME_RELEASE" | sed -e 's/\..*//'`" -le 10 ; then
	    if [ "$CC_FOR_BUILD" != no_compiler_found ]; then
		if (echo '#ifdef __LP64__'; echo IS_64BIT_ARCH; echo '#endif') | \
		       (CCOPTS="" $CC_FOR_BUILD -E - 2>/dev/null) | \
		       grep IS_64BIT_ARCH >/dev/null
		then
		    case $UNAME_PROCESSOR in
			i386) UNAME_PROCESSOR=x86_64 ;;
			powerpc) UNAME_PROCESSOR=powerpc64 ;;
		    esac
		fi
		# On 10.4-10.6 one might compile for PowerPC via gcc -arch ppc
		if (echo '#ifdef __POWERPC__'; echo IS_PPC; echo '#endif') | \
		       (CCOPTS="" $CC_FOR_BUILD -E - 2>/dev/null) | \
		       grep IS_PPC >/dev/null
		then
		    UNAME_PROCESSOR=powerpc
		fi
	    fi
	elif test "$UNAME_PROCESSOR" = i386 ; then
	    # Avoid executing cc on OS X 10.9, as it ships with a stub
	    # that puts up a graphical alert prompting to install
	    # developer tools.  Any system running Mac OS X 10.7 or
	    # later (Darwin 11 and later) is required to have a 64-bit
	    # processor. This is not true of the ARM version of Darwin
	    # that Apple uses in portable devices.
	    UNAME_PROCESSOR=x86_64
	fi
	echo "$UNAME_PROCESSOR"-apple-darwin"$UNAME_RELEASE"
	exit ;;


I do not really understand what is going on in these scripts but I am happy to try out your suggestions and keep you informed.

best regards,
Uwe Kirschner



> On 22. Aug 2022, at 12:42, Christopher Chavez <chr...@gm...> wrote:
> 
> Sent: Friday, August 12, 2022 at 8:20 AM
> From: "Uwe Kirschner"
>> Hello Andreas,
>> I am struggeling very much with building a universal (x86_64/arm64) version of tkImg-1.4.13.
>>  
>> I had not managed to build a x86_64 version either because of a missing tiffconf.h but luckily I could fallback on the prebuilt distribution.
>>  
>> 
>> In file included from tifftcl.c:29:
>> In file included from ./tifftcl.h:50:
>> In file included from ./tifftclDecls.h:37:
>> In file included from ./../compat/libtiff/libtiff/tiffio.h:31:
>> ./../compat/libtiff/libtiff/tiff.h:28:10: fatal error: 'tiffconf.h' file not found
>> #include "tiffconf.h"
>>          ^~~~~~~~~~~~
>>  
>> Unfortunately, there was no prebuilt universal package when I last checked (a few days ago). Do you intend to provide a prebuild universal tkImg-1.4.13?
>> 
>> On Apple Silicon (M1 MacMini) I cannot proceed far enough to run into the missing tiffconf.h issue which had stopped me on my Intel Mac. Rather, I fail much earlier in the configure process. Looking at config.log I assume that a „windows“ platform is recognized.
>>  
>> 
>> checking for tclsh... tclsh86.exe
>> checking for wish... wish86.exe
>>  
>>  
>> In the "tkImg-1.4.13“ directory I run:
>>  autoconf
>> ./genConfigureScripts.sh
>> ./configure —with-tcl=… —with-tk=… CFLAGS=„-arch x86_64 -arch arm64“
>> make
>>  
>> …but no luck. Script stops due to an invalid libzlibtclstub1.2.11.a (when attempting to produce pngtcl1.6.37.dylib). I did a lipo -archs on libzlibtclstub1.2.11.a and lipo complains about an illegal fat file in the archive…
>>  
>>  
>>  
>> Can you please have a look at the log-files and tell me what is going wrong?
>>  
>> Best regards,
>> Uwe
> 
> 
> Hello Uwe,
> 
> As I say to others who post here, the tcl-mac list is not as popular as it once was, and I would not recommend using it due to the likelihood of posts going unnoticed. Also, I am not aware of Andreas having worked on tkimg in quite some time; Jan Nijtmans and Paul Obermeier have been the ones maintaining it for several years.
> 
> I am not familiar with Universal builds and do not have access to an Apple Silicon Mac. However I am able to build Tcl/Tk (core-8-6-branch) and tkimg (SVN revision 569, which recently fixed building libpng on arm64) without issue on macOS 10.15 Catalina using Xcode 12.4 command line tools and the macOS 11 Big Sur SDK:
> 
> CC='xcrun --sdk /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk -r clang' \
> CFLAGS='-arch x86_64 -arch arm64' \
> ./configure …
> 
> From looking at your config.log, I do believe something is going wrong during `checking platform`:
> 
> configure:3395: checking platform
> configure:3413: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -c -arch x86_64 -arch arm64  conftest.c >&5
> ./configure: line 1503: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang: No such file or directory
> …
> configure:3424: checking for cygpath
> configure:3452: result: echo
> configure:3464: result: windows
> 
> I am not certain, but I believe the problem is that this step is hardcoded to use TCL_CC, and I suspect that TCL_CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang is being picked up from your tclConfig.sh. You may try overriding it as a workaround, e.g. `TCL_CC=/usr/bin/clang ./configure …`. I do not know if that is enough to allow the build to succeed for you, but if it does, then it indicates a likely issue in tclconfig rather than a Universal build issue in tkimg (I have opened a ticket in case it is the former: https://core.tcl-lang.org/tclconfig/info/c03b9df15f )
> 
> 
> Hope this helps,
> Christopher A. Chavez

Re: [MACTCL] building universal tkImg-1.4.13

[Christopher C. <chr...@gm...>]

Sent: Friday, August 12, 2022 at 8:20 AM
From: "Uwe Kirschner"
> Hello Andreas,
> I am struggeling very much with building a universal (x86_64/arm64) version of tkImg-1.4.13.
> 
> I had not managed to build a x86_64 version either because of a missing tiffconf.h but luckily I could fallback on the prebuilt distribution.
> 
> 
> In file included from tifftcl.c:29:
> In file included from ./tifftcl.h:50:
> In file included from ./tifftclDecls.h:37:
> In file included from ./../compat/libtiff/libtiff/tiffio.h:31:
> ./../compat/libtiff/libtiff/tiff.h:28:10: fatal error: 'tiffconf.h' file not found
> #include "tiffconf.h"
>          ^~~~~~~~~~~~
> 
> Unfortunately, there was no prebuilt universal package when I last checked (a few days ago). Do you intend to provide a prebuild universal tkImg-1.4.13?
> 
> On Apple Silicon (M1 MacMini) I cannot proceed far enough to run into the missing tiffconf.h issue which had stopped me on my Intel Mac. Rather, I fail much earlier in the configure process. Looking at config.log I assume that a „windows“ platform is recognized.
>  
> 
> checking for tclsh... tclsh86.exe
> checking for wish... wish86.exe
> 
> 
> In the "tkImg-1.4.13“ directory I run:
>  autoconf
> ./genConfigureScripts.sh
> ./configure —with-tcl=… —with-tk=… CFLAGS=„-arch x86_64 -arch arm64“
> make
> 
> …but no luck. Script stops due to an invalid libzlibtclstub1.2.11.a (when attempting to produce pngtcl1.6.37.dylib). I did a lipo -archs on libzlibtclstub1.2.11.a and lipo complains about an illegal fat file in the archive…
> 
> 
> 
> Can you please have a look at the log-files and tell me what is going wrong?
> 
> Best regards,
> Uwe


Hello Uwe,

As I say to others who post here, the tcl-mac list is not as popular as it once was, and I would not recommend using it due to the likelihood of posts going unnoticed. Also, I am not aware of Andreas having worked on tkimg in quite some time; Jan Nijtmans and Paul Obermeier have been the ones maintaining it for several years.

I am not familiar with Universal builds and do not have access to an Apple Silicon Mac. However I am able to build Tcl/Tk (core-8-6-branch) and tkimg (SVN revision 569, which recently fixed building libpng on arm64) without issue on macOS 10.15 Catalina using Xcode 12.4 command line tools and the macOS 11 Big Sur SDK:

CC='xcrun --sdk /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk -r clang' \
CFLAGS='-arch x86_64 -arch arm64' \
./configure …

>From looking at your config.log, I do believe something is going wrong during `checking platform`:

configure:3395: checking platform
configure:3413: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -c -arch x86_64 -arch arm64  conftest.c >&5
./configure: line 1503: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang: No such file or directory
…
configure:3424: checking for cygpath
configure:3452: result: echo
configure:3464: result: windows

I am not certain, but I believe the problem is that this step is hardcoded to use TCL_CC, and I suspect that TCL_CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang is being picked up from your tclConfig.sh. You may try overriding it as a workaround, e.g. `TCL_CC=/usr/bin/clang ./configure …`. I do not know if that is enough to allow the build to succeed for you, but if it does, then it indicates a likely issue in tclconfig rather than a Universal build issue in tkimg (I have opened a ticket in case it is the former: https://core.tcl-lang.org/tclconfig/info/c03b9df15f )


Hope this helps,
Christopher A. Chavez

Re: [MACTCL] building universal tkImg-1.4.13

[Obermeier-Tcl3D <obe...@tc...>]

Hi Uwe,

I'm one of the tkImg developers.
Building tkImg on Intel Macs works fine for me using my BAWT framework (www.bawt.tcl3d.org).
tkImg currently does not build on ARM Macs, but a friend of mine is currently working on that issue, as I do not have access to an ARM Mac.
So stay tuned.

Regards,
Paul

Am 12.08.2022 um 15:20 schrieb Uwe Kirschner:
> Hello Andreas,
> I am struggeling very much with building a universal (x86_64/arm64) version of tkImg-1.4.13.
>
> I had not managed to build a x86_64 version either because of a missing tiffconf.h but luckily I could fallback on the prebuilt distribution.
>
> In file included from tifftcl.c:29:
> In file included from ./tifftcl.h:50:
> In file included from ./tifftclDecls.h:37:
> In file included from ./../compat/libtiff/libtiff/tiffio.h:31:
> *./../compat/libtiff/libtiff/tiff.h:28:10: **fatal error: **'tiffconf.h' file not found*
> #include "tiffconf.h"
> *         ^~~~~~~~~~~~*
>
> Unfortunately, there was no prebuilt universal package when I last checked (a few days ago). Do you intend to provide a prebuild universal tkImg-1.4.13?
>
> On Apple Silicon (M1 MacMini) I cannot proceed far enough to run into the missing tiffconf.h issue which had stopped me on my Intel Mac. Rather, I fail much earlier in the configure process. Looking at config.log I assume that a „windows“ platform is recognized.
>
> checking for tclsh... tclsh86.exe
> checking for wish... wish86.exe
>
>
> In the "tkImg-1.4.13“ directory I run:
>  autoconf
> ./genConfigureScripts.sh
> ./configure —with-tcl=… —with-tk=… CFLAGS=„-arch x86_64 -arch arm64“
> make
>
> …but no luck. Script stops due to an invalid libzlibtclstub1.2.11.a (when attempting to produce pngtcl1.6.37.dylib). I did alipo -archs on libzlibtclstub1.2.11.a and lipo complains about an illegal fat file in the archive…
>
>
>
> Can you please have a look at the log-files and tell me what is going wrong?
>
> Best regards,
> Uwe
>
>
>
>
>
>
>
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

[MACTCL] building universal tkImg-1.4.13

[Uwe K. <Uwe...@gm...>]

Hello Andreas,
I am struggeling very much with building a universal (x86_64/arm64) version of tkImg-1.4.13.

I had not managed to build a x86_64 version either because of a missing tiffconf.h but luckily I could fallback on the prebuilt distribution.

In file included from tifftcl.c:29:
In file included from ./tifftcl.h:50:
In file included from ./tifftclDecls.h:37:
In file included from ./../compat/libtiff/libtiff/tiffio.h:31:
./../compat/libtiff/libtiff/tiff.h:28:10: fatal error: 'tiffconf.h' file not found
#include "tiffconf.h"
         ^~~~~~~~~~~~

Unfortunately, there was no prebuilt universal package when I last checked (a few days ago). Do you intend to provide a prebuild universal tkImg-1.4.13?

On Apple Silicon (M1 MacMini) I cannot proceed far enough to run into the missing tiffconf.h issue which had stopped me on my Intel Mac. Rather, I fail much earlier in the configure process. Looking at config.log I assume that a „windows“ platform is recognized.

checking for tclsh... tclsh86.exe
checking for wish... wish86.exe


In the "tkImg-1.4.13“ directory I run:
 autoconf
./genConfigureScripts.sh
./configure —with-tcl=… —with-tk=… CFLAGS=„-arch x86_64 -arch arm64“
make

…but no luck. Script stops due to an invalid libzlibtclstub1.2.11.a (when attempting to produce pngtcl1.6.37.dylib). I did a lipo -archs on libzlibtclstub1.2.11.a and lipo complains about an illegal fat file in the archive…



Can you please have a look at the log-files and tell me what is going wrong?

Best regards,
Uwe

Re: [MACTCL] very slow widget config/update problem with tk 8.6.12

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

On 2/25/22 12:44 PM, Kevan Hashemi wrote:
> Dear Chavez,
>
>> PS: this mailing list is not as popular as it once was. I would 
>> personally not recommend using it due to the likelihood of posts 
>> being ignored.
>
> Where else can one report MacOS Tcl issues?
>
> Best Wishes, Kevan
>
You can open a ticket at the core Tcl/Tk development site. Here is the 
site for Tk:

https://core.tcl-lang.org/tk/timeline?y=ci

--Kevin

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

Re: [MACTCL] very slow widget config/update problem with tk 8.6.12

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

Dear Chavez,

> PS: this mailing list is not as popular as it once was. I would personally not recommend using it due to the likelihood of posts being ignored.

Where else can one report MacOS Tcl issues?

Best Wishes, Kevan

-- 
Kevan Hashemi, President
Open Source Instruments Inc.
www.opensourceinstruments.com

Re: [MACTCL] very slow widget config/update problem with tk 8.6.12

[Aivar A. <aiv...@gm...>]

A similar issue was discussed at https://bugs.python.org/issue43511 and
https://core.tcl-lang.org/tk/tktview/f642d7c0f4

Best regards
Aivar

On Fri, Feb 25, 2022 at 10:11 AM Christopher Chavez <chr...@gm...>
wrote:

> Sent: Wednesday, January 26, 2022 at 8:19 AM
> From: "Andy Colebourne"
>
> > Moving from 8.6.10 to 8.6.12 and discovered that my folding widgets are
> now very slow to update.
>
> > Is this fixed in the core branch and, if so, how do I download that?
> >
> > Thanks,
> >
> > Andy
>
>
> Hi Andy,
>
> As another Tk Aqua user, I want to say that your issue has not been fixed
> on a development branch, but I do not have enough information to say with
> certainty. There have not been issues strongly resembling yours reported—at
> least on the issue tracker (https://core.tcl-lang.org/tk/ticket)—and so
> it is likely not understood well enough for Tk Aqua developers to act on.
> It would greatly help if you could provide example code exhibiting the
> issue.
>
>
> Christopher A. Chavez
>
>
> PS: this mailing list is not as popular as it once was. I would personally
> not recommend using it due to the likelihood of posts being ignored.
>
>
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>

Re: [MACTCL] very slow widget config/update problem with tk 8.6.12

[Christopher C. <chr...@gm...>]

Sent: Wednesday, January 26, 2022 at 8:19 AM
From: "Andy Colebourne"

> Moving from 8.6.10 to 8.6.12 and discovered that my folding widgets are now very slow to update.

> Is this fixed in the core branch and, if so, how do I download that?
> 
> Thanks,
> 
> Andy


Hi Andy,

As another Tk Aqua user, I want to say that your issue has not been fixed on a development branch, but I do not have enough information to say with certainty. There have not been issues strongly resembling yours reported—at least on the issue tracker (https://core.tcl-lang.org/tk/ticket)—and so it is likely not understood well enough for Tk Aqua developers to act on. It would greatly help if you could provide example code exhibiting the issue.


Christopher A. Chavez


PS: this mailing list is not as popular as it once was. I would personally not recommend using it due to the likelihood of posts being ignored.

[MACTCL] very slow widget config/update problem with tk 8.6.12

[Andy C. <an...@ac...>]

Moving from 8.6.10 to 8.6.12 and discovered that my folding widgets are now
very slow to update.

 

Illustrated here:

 

http://inivis.com/external/foldingprob.mov

 

The UI on the right (fuzzy low-res) is compiled with 8.6.10 - speed is fine.
The UI on the left is 8.6.12 - very slow to update.

 

Is this fixed in the core branch and, if so, how do I download that?

 

Thanks,

 

Andy

 

Re: [MACTCL] Opening app by double-clicking or dragging file

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

On 10/27/21 8:18 AM, Jasper Taylor wrote:
> Thanks Kevin, have updated to latest core-8-6-branch and all is working!
> —Jasper
>
Great, glad it helped!

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

Re: [MACTCL] Opening app by double-clicking or dragging file

[Jasper T. <ja...@si...>]

Thanks Kevin, have updated to latest core-8-6-branch and all is working! 
	—Jasper

> On 27 Oct 2021, at 12:12, Kevin Walzer <kw...@co...> wrote:
> 
> Hi Jasper,
> 
> On 10/27/21 6:15 AM, Jasper Taylor wrote:
>> Hi MacTclers,
>> I have a long standing problem that if I double click a file that is handled by my app, or if I drag it to the app’s icon, I get an error message like this:
>> 
>> The document “posning.sml” could not be opened. Simile cannot open files in the “com.Simulistics.sml” format.
>> 
>> The app then opens without opening the document. However, if I do the same thing when the app is already running, the app’s tk::mac::OpenDocument procedure is called and the document opens. I also have tk::mac::OpenApplication and tk::mac::ReopenApplication defined, but neither are called in the first case.
>> I enabled the ‘com.apple.security.authorization.apple-events’ key when signing the code, but this does not seem to change anything.
>> Any help very much appreciated!
>> 	—Jasper
> 
> This bug was reported on the list last spring, and I committed a fix in 830e5b70 - it probably hasn't made it into a new Tcl/Tk release yet. Can you try building the tip of core-8-6-branch? It should address the issue. 
> 
> Thanks,
> 
> Kevin  
> 
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com <http://www.codebykevin.com/>
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Opening app by double-clicking or dragging file

[Jasper T. <ja...@si...>]

I’m sorry everyone, this was a red herring. All this change seems to have done is stop the app getting tried at all, resulting in an older version of the app being tried instead, which has the original Info.plist. The only reason I can think of why the older version works OK is that it is built for x86-64 while the newer one is combined x86-64 and arm64. Also the older one uses TclTk 8.6.10 whereas the newer one is TclTk 8.6.11. My machine is arm64. Well, nothing on the Mac is ever easy…
	—Jasper

> On 27 Oct 2021, at 12:17, Jasper Taylor <ja...@si...> wrote:
> 
> Have fixed this by including these lines in the Info.plist under CFBundleDocumentTypes:
> 
>                         <key>LSHandlerRank</key>
>                         <string>Owner</string>
>                         <key>LSItemContentTypes</key>
>                         <array>
>                           <string>public.data</string>
>                         </array>
> 
>> On 27 Oct 2021, at 11:15, Jasper Taylor <ja...@si... <mailto:ja...@si...>> wrote:
>> 
>> Hi MacTclers,
>> I have a long standing problem that if I double click a file that is handled by my app, or if I drag it to the app’s icon, I get an error message like this:
>> 
>> The document “posning.sml” could not be opened. Simile cannot open files in the “com.Simulistics.sml” format.
>> 
>> The app then opens without opening the document. However, if I do the same thing when the app is already running, the app’s tk::mac::OpenDocument procedure is called and the document opens. I also have tk::mac::OpenApplication and tk::mac::ReopenApplication defined, but neither are called in the first case.
>> I enabled the ‘com.apple.security.authorization.apple-events’ key when signing the code, but this does not seem to change anything.
>> Any help very much appreciated!
>> 	—Jasper
>> _______________________________________________
>> Tcl-mac mailing list
>> tc...@li... <mailto:tc...@li...>
>> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 

Re: [MACTCL] Opening app by double-clicking or dragging file

[Jasper T. <ja...@si...>]

Have fixed this by including these lines in the Info.plist under CFBundleDocumentTypes:

                        <key>LSHandlerRank</key>
                        <string>Owner</string>
                        <key>LSItemContentTypes</key>
                        <array>
                          <string>public.data</string>
                        </array>

> On 27 Oct 2021, at 11:15, Jasper Taylor <ja...@si...> wrote:
> 
> Hi MacTclers,
> I have a long standing problem that if I double click a file that is handled by my app, or if I drag it to the app’s icon, I get an error message like this:
> 
> The document “posning.sml” could not be opened. Simile cannot open files in the “com.Simulistics.sml” format.
> 
> The app then opens without opening the document. However, if I do the same thing when the app is already running, the app’s tk::mac::OpenDocument procedure is called and the document opens. I also have tk::mac::OpenApplication and tk::mac::ReopenApplication defined, but neither are called in the first case.
> I enabled the ‘com.apple.security.authorization.apple-events’ key when signing the code, but this does not seem to change anything.
> Any help very much appreciated!
> 	—Jasper
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Opening app by double-clicking or dragging file

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

Hi Jasper,

On 10/27/21 6:15 AM, Jasper Taylor wrote:
> Hi MacTclers,
> I have a long standing problem that if I double click a file that is 
> handled by my app, or if I drag it to the app’s icon, I get an error 
> message like this:
>
> *The document “posning.sml” could not be opened. Simile cannot open 
> files in the “com.Simulistics.sml” format.*
> *
> *
> The app then opens without opening the document. However, if I do the 
> same thing when the app is already running, the app’s 
> tk::mac::OpenDocument procedure is called and the document opens. I 
> also have tk::mac::OpenApplication and tk::mac::ReopenApplication 
> defined, but neither are called in the first case.
> I enabled the ‘com.apple.security.authorization.apple-events’ key when 
> signing the code, but this does not seem to change anything.
> Any help very much appreciated!
> —Jasper


This bug was reported on the list last spring, and I committed a fix in 
830e5b70 - it probably hasn't made it into a new Tcl/Tk release yet. Can 
you try building the tip of core-8-6-branch? It should address the issue.

Thanks,

Kevin

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

[MACTCL] Opening app by double-clicking or dragging file

[Jasper T. <ja...@si...>]

Hi MacTclers,
I have a long standing problem that if I double click a file that is handled by my app, or if I drag it to the app’s icon, I get an error message like this:

The document “posning.sml” could not be opened. Simile cannot open files in the “com.Simulistics.sml” format.

The app then opens without opening the document. However, if I do the same thing when the app is already running, the app’s tk::mac::OpenDocument procedure is called and the document opens. I also have tk::mac::OpenApplication and tk::mac::ReopenApplication defined, but neither are called in the first case.
I enabled the ‘com.apple.security.authorization.apple-events’ key when signing the code, but this does not seem to change anything.
Any help very much appreciated!
	—Jasper

Re: [MACTCL] Apple M1 Build

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

Jasper and Nocolas: thank you, that's great news. Best Wishes, Kevan

On 10/21/21 10:46 AM, nicolas bats wrote:
> Yes
> And with mac_styles_87 branch,  CPU usage of my app is reduced about 20% compared to Intel CPU.
> 
> ++
> 
> Le jeu. 21 oct. 2021 à 16:38, Jasper Taylor <ja...@si... <mailto:ja...@si...>> a écrit :
> 
>     Yes I have
> 
>           --Jasper
> 
>     On 21/10/2021 14:45, Kevan Hashemi wrote:
>      > Dear Tcl-Mac,
>      >
>      > Has anyone built TclTk for Apple M1 yet?
>      >
>      > Best, Kevan
>      >
> 
> 
>     _______________________________________________
>     Tcl-mac mailing list
>     tc...@li... <mailto:tc...@li...>
>     https://lists.sourceforge.net/lists/listinfo/tcl-mac <https://lists.sourceforge.net/lists/listinfo/tcl-mac>
> 
> 
> 
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 

-- 
Kevan Hashemi, President
Open Source Instruments Inc.
www.opensourceinstruments.com

Re: [MACTCL] Apple M1 Build

[nicolas b. <sl1...@gm...>]

Yes
And with mac_styles_87 branch,  CPU usage of my app is reduced about 20%
compared to Intel CPU.

++

Le jeu. 21 oct. 2021 à 16:38, Jasper Taylor <ja...@si...> a
écrit :

> Yes I have
>
>      --Jasper
>
> On 21/10/2021 14:45, Kevan Hashemi wrote:
> > Dear Tcl-Mac,
> >
> > Has anyone built TclTk for Apple M1 yet?
> >
> > Best, Kevan
> >
>
>
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>

Re: [MACTCL] Apple M1 Build

[Jasper T. <ja...@si...>]

Yes I have

     --Jasper

On 21/10/2021 14:45, Kevan Hashemi wrote:
> Dear Tcl-Mac,
>
> Has anyone built TclTk for Apple M1 yet?
>
> Best, Kevan
>

[MACTCL] Apple M1 Build

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

Dear Tcl-Mac,

Has anyone built TclTk for Apple M1 yet?

Best, Kevan

-- 
Kevan Hashemi, President
Open Source Instruments Inc.
www.opensourceinstruments.com

[MACTCL] Announcement & Call for Speakers (The SQLite & Tcl Conf 2021)

[<con...@tc...>]

Hello tcl-mac, fyi ...

# The SQLite & Tcl Conference

__Wednesday, November 17, 2021__

The 2nd annual SQLite & Tcl virtual conference will be held on Wednesday, November 17.
The virtual event will feature a combination of curated talks and work in progress talks (WIPs).

[Registration is open](https://www.eventbrite.com/e/the-sqlite-tcl-conference-st-2021-registration-168185004877)!

Please visit the [SQLite & TCL conference](https://conf.tcl-lang.org/) home page to stay informed.

# Call for Speakers

We've made it easier to contribute by asking for shorter, less formal
talks rather than requiring formal papers.

  - Have you done interesting work that you would like to share?

  - How about a cool idea that's not yet baked or just in the
    prototype stage but seems like something others would be
    interested in? We are particularly interested in new ideas, to
    hear about novel solutions to problems you've faced, or to see
    your work in progress.

## To submit your talk:

Please visit the [call for speakers page](https://conf.tcl-lang.org/callforspeakers/)
for instructions.

As a token of our appreciation, each speaker will be gifted with a
video conferencing light kit to use while presenting.

The call for speakers for S&T 2021 ends on __October 4, 2021 at 11:59 PM CT__.

__Important dates:__

  - October 4 - Call for speakers for S&T 2021 ends at 11:59 PM CT

  - October 8 - We will start notifying speakers with their status of
    their submission and scheduled talk.

  - October 18 - Agenda for S&T 2021 Announced

  - November 17 - S&T 2021 held digitally online  

Re: [MACTCL] Supporting Command-click on window title

[Aivar A. <aiv...@gm...>]

Thanks a lot!

I got it working with .wm_attributes("-titlepath",
stringContainingTheAbsolutePathOfTheDocument)
Passing empty string as the second argument turned the feature off.

I had to do it after setting iconbitmap, otherwise the icon file became the
titlepath.

Best regards,
Aivar


Furthermore, I think there should be something more -- I need to somehow
specify the path of the current document. I can't see how Tk could infer it.

On Tue, Jun 8, 2021 at 3:26 PM Kevin Walzer <kw...@co...> wrote:

> On 6/8/21 2:33 AM, Aivar Annamaa wrote:
> > Hi!
> >
> > In many macOS apps, when you Command-click on window's title, macOS
> > will show a menu describing the location of the currently open
> > document (see
> >
> https://oneminutemacman.com/command-click-a-windows-title-to-show-the-documents-location/
> > <
> https://oneminutemacman.com/command-click-a-windows-title-to-show-the-documents-location/
> >).
> >
> > Is it possible to control this in a Tk app? My Tkinter app currently
> > does show this menu, but it is always describing the location of the
> > application's icon file (set with root window's iconbitmap method).
> >
> > If there are no direct means for this in Tk, perhaps you know the name
> > of the corresponding method in Cocoa? Maybe it's possible to call it
> > via Python's ctypes.
> >
> > Best regards,
> > Aivar
>
> In Tcl, the command is [wm attributes $w -titlepath true]. In
> Python/Tkinter, it's something like w.wm_attributes("titlepath",
> "true"), where $w or w is the window name/object. (My Python is a bit
> rusty, but give this a try.)
>
> --Kevin
>
> --
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com
>
>
>
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>

Re: [MACTCL] Supporting Command-click on window title

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

On 6/8/21 2:33 AM, Aivar Annamaa wrote:
> Hi!
>
> In many macOS apps, when you Command-click on window's title, macOS 
> will show a menu describing the location of the currently open 
> document (see 
> https://oneminutemacman.com/command-click-a-windows-title-to-show-the-documents-location/ 
> <https://oneminutemacman.com/command-click-a-windows-title-to-show-the-documents-location/>).
>
> Is it possible to control this in a Tk app? My Tkinter app currently 
> does show this menu, but it is always describing the location of the 
> application's icon file (set with root window's iconbitmap method).
>
> If there are no direct means for this in Tk, perhaps you know the name 
> of the corresponding method in Cocoa? Maybe it's possible to call it 
> via Python's ctypes.
>
> Best regards,
> Aivar

In Tcl, the command is [wm attributes $w -titlepath true]. In 
Python/Tkinter, it's something like w.wm_attributes("titlepath", 
"true"), where $w or w is the window name/object. (My Python is a bit 
rusty, but give this a try.)

--Kevin

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

[MACTCL] Supporting Command-click on window title

[Aivar A. <aiv...@gm...>]

Hi!

In many macOS apps, when you Command-click on window's title, macOS will
show a menu describing the location of the currently open document (see
https://oneminutemacman.com/command-click-a-windows-title-to-show-the-documents-location/
).

Is it possible to control this in a Tk app? My Tkinter app currently does
show this menu, but it is always describing the location of the
application's icon file (set with root window's iconbitmap method).

If there are no direct means for this in Tk, perhaps you know the name of
the corresponding method in Cocoa? Maybe it's possible to call it via
Python's ctypes.

Best regards,
Aivar

Re: [MACTCL] Still Cannot Build TclTk on MacOS10.15

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

Dear Christopher,

> The patchlevel of macOS 10.15’s Tcl/Tk is 8.5.9. 

You are quite right: I have 8.5.18 installed by Home Brew.

> I would think SIP (System Integrity Protection) would try very hard to keep you from deleting the system Tcl/Tk, so I would not recommend trying to.

I can delete the Home Brew installation, although that will break a few things like ffmpeg and python.

So far as I understand it, the TclTk embedded build, invoked by the commands below, is independent of any installed TclTk.

make -C tcl/macosx embedded
make -C tk/macosx embedded

Is anyone able to complete the embedded build of 8.7 on MacOS 10.15 or 11.1? I can on MacOS 10.12, but not on 10.15.

Best, Kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://www.bndhep.net

Re: [MACTCL] Still Cannot Build TclTk on MacOS10.15

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

Dear Mansour,

Thank you for your attention.

> Can you share the output of:
> 
>      export CC="$(xcrun --find clang)"
>      $CC --version

kevan@KSH5 ~ % export CC="$(xcrun --find clang)"
kevan@KSH5 ~ % $CC --version
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

>      xcodebuild -showsdks

kevan@KSH5 ~ % xcodebuild -showsdks
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory
'/Library/Developer/CommandLineTools' is a command line tools instance

As you can see, I don't have Xcode installed. I don't believe I have it installed on my older machine either, but I will check.

Best, Kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://www.bndhep.net