macOS Monterey 12.3.1

This is fossil version 2.19 [92fd091703] 2022-03-23 10:09:09 UTC

(compiled from source)

Tell me if other info is needed.

It also displays this warning

DEPRECATION WARNING: The system version of Tk is deprecated and may be removed in a future release. Please don't rely on it. Set TK_SILENCE_DEPRECATION=1 to suppress this warning.

If the warning is the key, what do you think is the best solution? How should the docs change according to this?

If the warning is the key, what do you think is the best solution? How should the docs change according to this?

That warning is coming from your libtk installation, not from fossil, so there's nothing for us to document there. In anticipation of that specific deprecation though, Richard was compelled to re-do the diff support late last year and he provided an alternative which uses your local browser to render the diff:

fossil diff -b
fossil diff -by # side-by-side format

So the black screen has something to do with the warning? If this is the case maybe a simple version check (libtk installation check?) with instructions about what to do (== your post) shown somewhere would be welcome.

Otherwise the command is just broken without any explanation for the user (it is supposed to be an Official Fossil Tip :) so it's quite sad)

So the black screen has something to do with the warning?

No idea - all i know is that it's not from us.

If this is the case maybe a simple version check (libtk installation check?) with instructions about what to do (== your post) shown somewhere would be welcome.

Fossil simply passes the (-tk)-generated script to whatever tlcsh is installed. In this case, your vendor has chosen to explicitly change that apps' behavior. That's not something fossil can detect.

Otherwise the command is just broken without any explanation for the user

It is sad, but it's 100% your vendor's fault, not fossil's. They've chosen to Go Another Way and step further into The Darkness.

So Fossil has no way of (easily?) knowing about the underlying error? That's quite sad!

But the "vendor" is the newest version of the Best-OS-In-The-World (or second best; half joke here) so maybe Fossil ought to know about it imho.

By the way you knew already I think but my knowledge of tcl & co is close to zero.

Wanted to know about it more profoundly one day but as far as I can recall I somehow stopped browsing after seeing some comment on the official site (wiki?) saying that OpenBSD was made by a bunch of masturbating monkeys. Felt sad that the best tools or the industry can't be nice to each other? :)

What has OpenBSD got to do with this thread, and why are you bringing up a 14-year-old controversy involving the creator of yet a third OS? I thought we were talking about the latest release of macOS here?

I was just talking about my recent life events concerning Tcl (half-jokingly), I'm sorry if this was just noise to you.

I was also implying that it was sad for such a useful language like Tcl (or for any language) to put this kind of comment in a header of a page. Sounded immature to me. (and I log forgot about Linus' rant, thank you for reminding me)

I think that here, the error message returned by the Best-OS-in-The-World is clear enough. It says to don't rely on it, and the fact that it's now broken (black flickery screen) confirms it, I'm not surprise.

Seeing that, I understand that I should not use "--tk" on this OS (unless I install myself a tcl/Tk GUI).

If fossil try to be clever and return error or warning message even if a tcl/tk GUI is present in the system doesn't worth it (and may become confusing) considering that.

• May be a future version will decide to support it.
• If we install a 3rd party tcl/tk that works well, fossil will need to detect this condition and omit the error message ?

On future update of MacOS, if tcl/tk get completely removed, you will have a different error message similar to:

sh: tclsh: command not found

May be in this case, fossil could detect the absence of a tcl/tk GUI beforehand and return a meaningful error message, which would be useful for all OS.

That's only my 2 cents. I don't talk in the name of the Fossil project.

The "best os" part is a joke, do not take it seriously.

I just meant that for most software like fossil, a report about a command that cannot be used (worse, invokes dragons in this case!) imho should be seen as a bug report, especially for the newest version of a first tier (== widely used) OS.

Saying "it's macOS' fault" does not seem constructive to me at all (from the pov of the user the command is supposed to abstract tcl/Tk so there should not be undefined/unclear behavior bubbling up to the surface in the first place).

Especially when the user cannot know if the message is from fossil or tk.

If it's many months since the command is unusable on macOS then I can't see any viable reason (except for some "we do not want to serve people who cannot use our software" stance like at OpenBSD) to not gracefully tell the user about it.

Seeing that, I understand that I should not use "--tk" on this OS (unless I install myself a tcl/Tk GUI).

This is because you have knowledge of Fossil or tcl/Tk that enables you to understand that this message is a "feature" of Fossil. Any user caring about Fossil should report a command that leads to a black screen/UB especially when there is no mention in the documentation. There is no mention that the command is broken on macOS in the docs or anywhere else so the first sane reaction is to ask the staff about the error message and/or read the source code yourself.

If fossil try to be clever and return error or warning message

It doesn't have to. A message such as this ↓ in the help text or in the docs should be enough.

Caveat: the --tk option does not work in recent versions of macOS starting with xx.xx. Do xxxx or use the -b option instead

But anyhow, let me remind you that this thread is

1. a feedback (better feedback to much than not enough is my stance)

2. asking for a recommended solution

nothing less nothing more. Sorry for any noise/trouble.

I am not complaining about anything.

If fossil try to be clever and return error or warning message even if a tcl/tk GUI is present in the system doesn't worth it (and may become confusing) considering that.

100%.

@KIT: fossil -tk does not know if tclsh is installed or what version it is, or anything about it. It only hopes that the binary called tclsh is an app which will accept the valid TCL code fossil generates and blindly sends to that app. It's like an interface: the interface "tclsh" accepts valid TCL code and gives a response. There is no interface for fossil asking "is this version of tclsh we really want?" or "is this an OS version where it might be broken?"

It's exactly like when fossil calls any external program: it calls them in good faith, expecting them to behave in "the conventional manner." The tclsh on your vendor's OS does not do so and fossil is completely ignorant of that. It has no way to even guess without a lot of fragile heuristics which will be subject to break in the next OS release from that vendor.

Note, also, that (fossil -tk) has an option to save the generated script for later use or passing to colleagues who have a working tcl/tk installation, and failing to process the -tk option on a potentially broken system would break that capability.

step further into The Darkness.

Alternate take:

1. Tk was already badly outdated when Fossil was first released, being a stylistic clone of Motif. It even looks outmoded on throwback distros like Mate that purposefully continue using GNOME 2, the closest surviving GUI to those days that's still in development. The mismatch is worse on macOS.

2. The underlying libraries are all but replaced. Yes, I'm aware that there's an X11 compatibility layer in Wayland, but all that means is that to support outmoded Tk, Apple would be best advised to port over Wayland. This in a world where they already kicked X to the curb. I predict that if a well-maintained port of Wayland for macOS happens at all, it'll be a third-party offering.

I was a Tk fan back in the day, but I'm not surprised Apple decided it isn't worth continuing to maintain the code base. I'm having trouble coming up with examples of important software Apple is leaving behind with this move.

Let's face it, fossil diff --tk doesn't class as "important" at that scale. Neither does "gitk" in a world where virtually everyone uses some other Git GUI, if they use one at all. What's left? Wikipedia's list leaves me with a big pile of "Meh."

What's Apple's ROI on this? Keep in mind that they're forced to provide the best Silicon Valley compensation packages.

Alternate alternate take:

The pre-installed version of Tcl/Tk version on macOS was deprecated by Apple some time ago (along with other scripting languages) and has not been updated in many years. The latest Tcl/Tk version is not badly outdated, looks nothing like Motif and it possible to use it to build modern native-looking GUIs which will run across multiple platforms (including deployment through a browser using CloudTk). I have a 7000+ line commercial program that runs across macOS, Linux and Windows with only a handful of platform specific lines (mostly setting fonts).

Also, the latest version of Tcl/Tk on macOS (and Tkinter and PerlTk) does not use X11, although the X11 version is still around for those who need it and have X11 installed.

But I digress.

I don't know how you get a black screen. When I try fossil diff --tk (with Fossil 2.18), I get this error:

can't find package Tk
    while executing
"package require Tk"
    ("eval" body line 2)
    invoked from within
"eval $prog"
    (file "file-a0cd4a312e625e1b" line 515)

Anyway, my recommendation is to install MacPorts, and then:

sudo port install tk +quartz

After that you should be able to use diff --tk without issues and without warnings.

Thank you.

Out of topic, but, why MacPorts and not Homebrew for example? Just preference or experience?

I mentioned MacPorts because I have tested my proposed workaround with it, but, sure, Homebrew may help you solve this issue as well. Homebrew is too slow and opinionated (e.g., by removing build variants and staying away from sudo) for my taste, but YMMV.

I can verify the black screen problem when I temporarily remove the Homebrew bin dir from the path on this macOS 12 system here, forcing it to use the deprecated system version of Tcl/Tk.

Homebrew's equivalent command to solve this is "brew install tcl-tk".

If you just want a GUI diff on macOS, I like p4merge better.