Disable aqua on mac?

[smithsp]

I would like to disable the aqua front end of tk, and use the regular x11 face. I tried building without aqua on my Mac, but came across problems. Here are the changes I made:

diff --git a/recipe/build.sh b/recipe/build.sh
index cb190da..3faa53e 100755
--- a/recipe/build.sh
+++ b/recipe/build.sh
@@ -28,7 +28,7 @@ cd $SRC_DIR/tk${VER}/unix
        --prefix="${PREFIX}" \
        $ARCH_FLAG \
        --with-tcl="${PREFIX}/lib" \
-       --enable-aqua=yes \
+       --enable-aqua=no \
 
 make
 make install
diff --git a/recipe/meta.yaml b/recipe/meta.yaml
index 1c0795e..b9a363d 100644
--- a/recipe/meta.yaml
+++ b/recipe/meta.yaml
@@ -26,8 +26,16 @@ requirements:
     - curl           # [win]
     - 7za            # [win]
     - vc {{ VC_VERSION }}  # [win]
+    - xorg-libx11 1.6.*        
+    - xorg-xproto 7.0.31 6
+    - libxcb 1.12 1
+    - xorg-kbproto 1.0.7 1
+    - xorg-libxdmcp 1.1.2 3
+    - xorg-libxau 1.0.8 3
+
   run:
     - vc {{ VC_VERSION }}  # [win]
+    - xorg-libx11 1.6.*
 
 test:

My build fails abruptly with

Fixing linking of /atom/conda-bld/tk_1516137711021/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_place/lib:/usr/X11R6/lib/libtk8.6.dylib in /atom/conda-bld/tk_1516137711021/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_place/lib/libtk8.6.dylib
Error: Could not find lib:/usr/X11R6/lib/libtk8.6.dylib

Full log is attached.

I was able to build previously, but that version seems to have had some opportunistic linking to my MacPorts installation in /opt/local.

[smithsp]

conda_build_tk.log

[dsentinel]

@smithsp Did you have any luck with this? Or even better upload to a channel?
I have the same need.

[smithsp]

@dsentinel Not that I remember. @kalling do you remember getting this to work?

[kalling]

@smithsp , @dsentinel
I don't think this ever occurred. In fact, I think we starting moving away from custom tk builds?

[dsentinel]

Thanks! Looks like I'm on my own here.

[dsentinel]

I got a build working package built.

[smithsp]

@dsentinel That sounds great! Did you upload it to a channel?

[dsentinel]

I haven't.
I'd be happy to if there is interest. This would require a bit of effort to create a channel and test for more general use.

It sounds like you all moved away from it, and I didn't come across any others complaining in my research for this. Which surprised me. We have legacy tkinter apps that look terrible on aqua, and some custom elements flat out don't work. I figured there would be others out there with the same issues, but all I found were old complaints that thought x11 looked bad and wanted aqua.

[smithsp]

@dsentinel We reverted to using MacPorts, since we couldn't come up with a solution, but having a non-aqua conda version is still desirable. Maybe you could open a pull request on this repo, and we could work with the conda-forge folks to come up with a non-aqua variant for mac-osx-64 that could be managed through their channel.

[dsentinel]

@dsentinel We reverted to using MacPorts, since we couldn't come up with a solution,

I love macports! But I can't ask my users to install it for my software to install.

but having a non-aqua conda version is still desirable. Maybe you could open a pull request on this repo, and we could work with the conda-forge folks to come up with a non-aqua variant for mac-osx-64 that could be managed through their channel.

Sure thing. Gimme a couple of weeks, I'm about to travel.
I can create a custom channel if it comes to it. I have an internal channel serving here.

I built this on a mac, so it may require a bit of effort to get it working in CI with a Linux docker cross-compile. I made a quick attempt in that direction but bailed for forgotten reasons.

[smithsp]

Mention @orso82 and @FantuzziMatteo97

[FantuzziMatteo97]

Using the default tk package from conda-forge, if I use Dark mode, then I can't see the menu subitems:

If I just switch back to the default appearance mode (light), then the subitems show up fine

This was the motivation for wanting to move away from the aqua build of tk.

[jakirkham]

@FantuzziMatteo97, did you raise this with the Tk developers?

[smithsp]

@jakirkham We have not raised this with the Tk folks. We just wanted to use the non-aqua version of tk, since it works with that (installed via MacPorts). But do you happen to know the best way to contact them?

[kalling]

@jakirkham @FantuzziMatteo97 The dark mode issue is certainly an annoyance with some (all?) conda versions of tk. I have tried a number of tk versions and some are worse than others. (As in, some versions of tk make everything blank, while others just have the menu issue in dark mode.)

[kalling]

Interestingly, the dark mode menu is readable after doing a clean 10.15 (Catalina) install in a VM. (Not great, but readable.)

The install is using tk 8.6.9 ha92aebf_0 conda-forge

[dsentinel]

How do you make a variant? with build string? I don't think this would be a "conda mutex"
Need something very much like macports variant.

[dsentinel]

@kalling , @smithsp and all.
I have this working... the fork is here https://github.com/dsentinel/tk-feedstock
and you can pull from my channel
https://onyx.passcal.nmt.edu/passcal

I'd be happy to try to merge this, but I'm unclear on how to make a variant of a package.

[kalling]

@dsentinel Thanks! I'll give it a look

[smithsp]

We should incorporate changes in the fork of @dsentinel for no-aqua into the freetype branch #40 . I have read documentation on variants a few times, and did not sufficiently understand them to be able to make progress for the tk freetype variant, but I just read https://conda-forge.org/docs/maintainer/knowledge_base.html#complete-example (under https://conda-forge.org/docs/maintainer/knowledge_base.html#message-passing-interface-mpi) and I think that I can finally visualize how a tk freetype and/or noaqua variant could be built (although I don't have time now to work on it).

[dsentinel]

@smithsp
Thanks for the references. It's hard to find comprehensive documentation for conda/conda-build, looks like conda-forge sheds a bit more light on this. This is one of the reasons I haven't made progress here.

Here's some of my ignorance( maybe a conda builder comes across this and can elaborate):

• is a meta-package required for a variant
• is a track feature a variant?
• what is the simple form of:
  • define a variant (not based on another pkg or meta-pkg): create a package with a variant (different build command, and different dependencies)
  • having a package depend on that variant

As the docs only contain examples and don't elaborate on the general mechanisms I think I understand, but with very low confidence. And will likely trial and error for a while, until I get something that works. Went through this with the CDT.

I think I'm in the same place as you are. I have a general understanding, but will probably take some trial and error to get this right.

The current hack is having a no_aqua build in this channel above , and specifying it's build string in our packages. Looks like the formal way to do it is also hackish by setting the build number etc. This solves my problem for now, but I'd be happy to merge the "correct" solution upstream.

1 question that we'll have to answer is:
Will a no aqua (or freetypefont) variant be incompatible or satisfy a general tk dep trying to be installed in the same env

[dsentinel]

This article may have some insight as well.
https://www.anaconda.com/blog/package-better-conda-build-3