tkdiff 5.4 shows up with a completely black window in macOS Monterey

What does "which wish" say? If you haven't installed tcl-tk from homebrew, you'll need to. Whatever tcl-tk is on Monterey is wholly obsolete and inadequate if I remember correctly.

Yes, just "brew install tcl." That's about as "official" as we get around here :-)
Even if you get Apple's tk working, it's 8.5 I think. 8.6 works much better.
I have the macports version too, which runs with the Xquartz you can get from there. I'm a unix/linux baby too, and I like to use X11 on my Mac sometimes.

Sorry, "brew install tcl-tk."

Well, I can use "Command+Q" to quit instead, that works. Still wondering why the preferences won't open. And also, whenever I open a new diff, the dropdown for diff positions shows up for some reason and doesn't go away until I select one of them. It even persists even if I move out of tkdiff window and go to some other window.

The dropdown thing doesn't happen for me, and Edit->Preferences works. The "x" for quit doesn't work - I never tried that before.

I do find that Tk is a little squirrelly on MacOS though. The first time I ran the new 5.4 tkdiff, I had a problem with applying preferences, but I couldn't replicate it after that.

Just my 2-cents...
The "q" to quit was admittedly the norm forever, in the days BEFORE users could assign their own hotkeys (V5.1, IIRC). However when we added the new hotkey capability we felt it might be SAFER to require two fingers on the keyboard to abruptly EXIT, at least as a DEFAULT for new users. You are free to RE-ESTABLISH whatever keys you would prefer at your own discretion, and that would include reverting BACK to the simple "q". I recommend reading the builtin Help on preferences to learn the sequence of how to specify a replacement Hotkey, but once done (and saved) you should be back to "normal".

Had an odd thought, however about using an OLDER preference file against a newer TkDiff version - particularly if that earlier file PRE-DATES the (V5.1?) Hotkey additions:

Every Preference always has a DEFAULT value (program supplied), but OLDER FILES only have the preferences KNOWN by the version that SAVED THEM. More importantly, there are NOT platform specific defaults for ANY particular preference. Thus when the FILE is read-in it only adjusts the preferences IT knows about, while the others would come from the program defaults.
It might be prudent to at least REVIEW what settings one THINKS they have, particularly after moving to a newer release. There is after all a LOT of "standard" differences between the various platforms supported - and the default cant be set to ALL of them simultaneously.

That's another problem. I am just unable to open the Preferences window at all. Nothing happens.
But since its not reproducible at your end, I guess something must be wrong with my setup. I can live with it as at least I am able to use tkdiff as my git difftool.

Thanks for the help! Closing the ticket.

Nevermind, looks like I can't close it :) Will let some overlord do it.

One last thought - could you upload a copy of your preference file to this ticket? I'm curious what the default values were overridden with that might explain the rather bizarre behavior you are/were seeing. There is no fundamental reason you should be UNABLE to view the preference settings, and your description of menu accelerators and such is exceptionally odd. Perhaps there is something IN your current settings that is at the root of this. Also, you suggested this Mac installation was something rather "new" - what version of TkDiff HAD YOU been using before this?

Strangely enough your answer alone may tell me enough.
FYI - On MacOS (like linux) the default preferences file would (theoretically) exist at the filename:
$HOME/.tkdiffrc
But you ALSO said this is a brand new installation on a machine you have never RUN TkDiff on! Worse, you claim you cant even GET to the preference window which kinda infers you have never CREATED a preference file on your Mac platform! So I wouldn't be surprised to learn that the filename shown above DOESN'T EXIST. Thus your "runtime settings" consists of a PURE internally-defaulted set of parameters which you are UNABLE to modify (because the Prefs window wont open) and ALSO cant SAVE (because the button to DO SO is on that same window)!
Alas, my own knowledge of things "MacOS" is quite limited. Dorothy is the better go-to person for this topic, but it sounds to me that there is something about how TkDiff is being INVOKED, and/or how it causes "Wish" to begin executing the TkDiff script, that is not the way most other people are operating. I cant say the following would help or hurt your situation, but you could TRY copying your Preference file FROM your Linux machine and PLACE it at the filename above, to see if things get any better. If it doesn't help, you can always delete it and be none the worse off.

Technically speaking, TkDiff is what is known as a Shell "here document" which at first appears to be a conventional Shell script and asks "/bin/sh" to perform the interpretation of the remainder of its content. However, it then uses your PATH variable to locate the "Wish" executable and immediately invokes THAT tool, giving IT the WHOLE script to begin reprocessing. This is what makes the script APPEAR to be "executable" (to a linux environment, and - I believe - also to a Mac) but also directly readable by "Wish" (mostly because both share an almost identical commenting syntax). All any of that means is there are a few places (PATH content, the Tcl/Tk installation locations), and how supposed MULTIPLE versions (the original Monterey version - which Dorothy said was useless - and whatever "homebrew" put in place) are intended to stay independent of each other.

Lastly, while I (vaguely) understand the earlier snippet about making sure the wish window gets RAISED on-screen shortly AFTER having started TkDiff (by telling Applescript to locate the wish window and 'activate' it), my concern would be the extra manipulation of the TkDiff ARGS
which SHOULDN'T make a difference, but stranger things have happenned in the past.
Anyway, I'll bow out here as I can't tell if I'm helping or just confusing things further. I suppose if you are satisfied enough to close the Ticket, we can make that happen, but SOMETHING is very ODD about what you are experiencing.

Yes, I don't have a $HOME/.tkdiffrc, and adding one did not help.

But here's what I discovered! There's some bug in tkdiff on macOS Monterey that is making the dropdowns act wonky. See the attached two screenshots. When I first open tkdiff, the dropdown on top left shows up outside of where its supposed to be, and is waiting for my input. Preferences doesn't open until I click that dropdown (and then it goes back into its place)

When I open preferences window, multiple dropdowns are rendered outside of the window, and I have to first click them to "fix" them and then I can interact with the window.

Definitely a UI related problem.

I'd note that this dropdown issue may be an argument in favor of using Tk's native combobox/dropdown widgets instead of homegrown ones. (ongoing friendly argument.) The problem is that Aqua and Cocoa are nothing like X11 and no doubt uses opposite approaches at times. (been there with trying to integrate two diametrically opposed programs - blech.) The Tk developers who take on the herculean (and/or sisyphean) task of making it all work with the Cocoa API make the best calls they can, and it's safer not to outsmart them if it's not necessary.

Anyway I'm pretty sure darwin as derived from BSD is not the problem.

You may have found a 20-year old bug that was just WAITING for you to tickle it!!!

But we have a small problem, that YOU could help solve - WE found something in the code that is VERY suspicious, but, as you know, WE cant make the problem occur! If we sent you a specially modified version, would you be willing to TRY IT and tell us if the weirdness of the drop-down list "goes away"?
If you agree, I will send you a replacement "tkdiff" script, that you can simply "drop into place" (aka. rename the one you HAVE, put the NEW one in its place). If it doesn't work, you can put everything back and we keep scratching our heads. BUT - if it solves the problem then you are ahead of the game, and I'll even ensure what I send contains fixes for OTHER issues that no one else has seen yet!
We think the reason YOU can hit the problem is related to your hardware and/or processor speed - in short it might be a race-condition that only YOU seem to be able to hit with any regularity!
Any interest in helping us out?

Yes, of course! Send me your fix and I will test it out.

@vampm First off, just wanted to say that you are awesome at writing explanations and instructions. Extremely detailed, covering all questions that may pop into the user's head upfront etc. Just amazing stuff. Your attention to detail and spending time on being explicit is much appreciated.

Secondly, bad news, 5.4.1 did not fix the dropdown issue either :(
See attachments.

Let me know if I can provide some debug info from my system etc. which may help you.

Phooey!
Well you DID find a 20yr old BUG - just not the one that explains your problem....

I have one or two more ideas, but its gonna take a bit to lash some code together to try and ferret this all out. So in the meantime, let me ask a question or two.

When you invoke "tkdiff" are you doing so from a commandline in some terminal emulator ? I ask because your "snippet" to solve the "shows up under other windows" problem reads like a SHELL 'function' definition. More importantly, CAN YOU invoke it from a commandline if needed? There is a command line OPTION (for limited debugging) that can be specified, and I might need you to run it that way and CAPTURE the "stderr" output stream to a file so it can be analyzed for the internal conditions it can be made to report. I just have to figure out what I need to SEE first and PLANT any extra debugging statements. Naturally, this can easily become an iterative process (ugh), which is why YOU being the only one who can CAUSE this problem is such a pain! But I'm not ready to throw in the towel just yet!

Another question - when the window first appears, do you ACTUALLY have to pick something IN the displayed list, or will it disappear if you just click the mouse NEARBY (but outside of) of it?

@vampm * I use tkdiff in iTerm2 (terminal emulator) * I mainly use it as "git difftool" (so git calls it with LOCAL and REMOTE files) * I also use it directly via command line to diff two files (tkdiff file1 file2) * I was using that function to make the "Wish" window show up over other windows, but I have already stopped using that to rule it out as a cause for the issue. It makes no difference. Using tkdiff directly on command line has the same issue. * Yes, let me know what extra command line switches to add and I can dump out stdout/stderr to a file and send it your way * When the window first appears, yes, I have to interact with the displayed list, it does not disappear if I click the mouse outside it. Once the list snaps back in the right place (after interacting with it), it does not appear in the wrong place again if I re-open the preferences window (for example).

I took a screen video to show you the end-to-end behavior. Hope it helps in debugging. Attaching it to my reply.

@vampm You did it. The issue is fixed. No more dropdowns in weird places!

Just one last "issue" (which is not much of a big deal at all). And it has been there since the beginning of this thread, nothing new introduced in your experiment.

The first time tkdiff opens, the Preferences window doesn't open when I click on Edit -> Preferences. The "Edit" text on the menu bar remains highlighted. Then I click on Edit -> Preferences again, and it works fine then. And subsequently too.

So probably some another weird UI issue rendering the Preferences window the first time I believe.

Upto you if you want to pursue it (and I can test your experiments), but with your latest code, I am all set!! Thank you so much for the prompt fix!