In case anyone's interested, I've tweaked version 6.0 from 2025-07-07 as follows:
Dark background on text panes and scrollbars (this seemed a little tricky with tcl/tk on MacOS)
Changed default highlight colors to my personal taste and for better readability in dark mode
Added Cursor Left and Right keys to [p]revious and [n]ext for quick navigation between diff spots. This now supports key repeat which didn't seem to work with [p] and [n] on MacOS.
tkdiff is running great here on MacOS 26 with the homebrew version of tcl-tk.
As of 2026, I still consider tkdiff to be one of the fastest and wonderfully straightforward graphical diff tools, so two thumbs up to the authors!
I'm the person with the Mac. Thanks, kewl. Good idea on the cursor left and right.
A couple of quick comments. First, this seems to be done on revision 208, whereas 209 was the release version. It makes a pretty short patch against r208. Yes, I know that's what tagging is for, and we absolutely should have tagged r209 as REL-6-0 and so on all the way back to REL-5-0. Especially since we don't use development branches much. There are only about 13 diffs with r208, which I'm attaching as a patch file.
Second, the text colors except for background and foreground are easily set in Preferences->Appearance, and they're likely to be saved already in the user's ~/.tkdiffrc. I kept seeing Tomato until I remembered that my ~/.tkdiffrc was probably overriding your defaults :-) Maybe we could interrogate the system for dark background rather than hard-coding white.
Third, I don't remember whether Michael has an objection to using ttk::scrollbar. We argue about ttk:: all the time :-)
Thanks @dorothyr!
Yes, I know the preferences. I've added the colors to the defaults because it took me some time to get it the way I liked it and I wanted to make life easier for first-time users :)
As for release 209, it seems like the 209 was released literally an hour after I downloaded 208, bad luck on my side...
Maybe we could interrogate the system for dark background rather than hard-coding white.
Good idea!
After not touching tk for many years, it was a little revelation for me to see how terribly slow SwiftUI can be with large files, compared to the old tcl/tk combo which runs like a race car in comparison on recent Apple Silicon.
Last edit: Ralph Schauner 2026-05-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now that I think about it, maybe adding a new "dark mode" preference is the way to go. It would probably require a restart, but some things do.
Also possibly I'm wrong about exactly which revision 6.0 was. I'll figure it out for sure and then I'll tag.
It's funny to hear that tcl/tk is fast at something, because at work I used to hand off to Perl to do any intensive parsing that was needed. I guess it's still good for some things!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't invent the default settings (and there are a TON of them) I just figured that because the ability to concoct foreground/background colors for practically EVERYTHING (via the User Preferences) existed, there wasn't much point in trying to "pre-package" a LOOK -- the old saw about beauty and the eye of the beholder and such. For what its worth, I changed my defaults a LONG TIME ago (its actually easier on the eyes to read white text on dark background - something I learned 40 years ago - less eyestrain). For that matter, TkDiff SUPPOSEDLY derives its widget defaults based on TK itself (or at least thats what it SAYS happens). We create strawman widgets and then extract key data settings FROM them to establish a baseline, which is THEN overriddden by the long litany of user adjustable settings. So I guess I'm a little lost on why if a so-called "dark mode" is a MAC "Thing" why it wouldn't already be making itself known. Maybe TK itself gets in the way? Or maybe its OUR defaults -- anyway, could be looked into.
Actually I'm not that surprised at the speed of TK; its based on XWindows which dates back to when networking delays made a BIG difference, and so they (then) paid an IMMENSE amount of consideration to providing 'responsiveness'. These days, that just translates directly to raw speed given the increase to high-bandwidth communication, and/or DIRECT (eg. null-network) situations of PC's versus ancient network terminals. Nevertheless, TkDiff still takes the viewpoint that if its worth doing, its worth doing FAST. Responsiveness is CRITICAL for something that is intended to be "interactive" and we work VERY hard to see it happens.
Sorry about that quick-turn on R208/R209. I had no sooner finished making the release than a flurry of "grammar"-related Tickets came in (primarily about missing apostrophes in code COMMENTS). I entertained just ignoring it, but curiosity of "How Many are there REALLY?" took hold. But in truth, I don't think I actually made a RELEASE afterward (although I DID commit the changes to the trunk). Yet I'm finding that various users aren't really WAITING AROUND for an official release and are simply ASSUMING the trunk is safe to snatch. I'd warn against DOING that, unless you are willing to deal with program features that might not function exactly correct. As the near-sole support developer on TkDiff, I often undertake development arcs that take months to complete, but are broken-down into "phased" development stages, each ENDING with a commit. And while I try to keep the trunk SANE (eg. no flat-out disasters) sometimes it takes a few sequential commits to achieve what I would term "stability". Grab the trunk at the wrong time and you IMPLICITLY become an unofficial development TESTER; and WORSE you haven't the slightest idea why it was changed, or where its really headed, making it nearly impossible to repair on your own. My feeling is you wanna play with the bleeding edge, join the team. If we had a larger development contingent, working from a branch would be more reasonable to expect, but as it stands now, branches just makes overhead work.
As to "ttk::" I don't have any reason to prefer it versus "plain"-TK for anything EXCEPT the "combobox" widget (where we DO prefer the 'plain' implementation BECAUSE we can -and have- made specific improvements FOR TkDiff). But there is a lot to be said for working with the basest form of the TCL language. For example, in the recent TK8.x.x to TK9.x.x update, the manner of Variable name-scoping was CHANGED. Yet owing to our non-use of namespaced libraries, TkDiff skated past any issues (except ONE) related to them. I highly prize stability in addition to speed.
Not exactly sure what was meant by "added Left/Right Cursor Keys" to 'p'rev and 'n'ext although haven't really LOOKED at whatever attachments are here (yet). Keyboard repeat is supposedly a given of the platform, so maybe this was some issue with the MAC graphics driver? - Admittedly, I generally defer such things to Dorothy as I don't OWN a Mac.
As to a 'dark-mode' preference. The only concern I have there is it makes practically EVERY base colorization decision a ternary. I get WHY the choice to adjust the so-called DEFAULT values was made (and is depicted in the provided example picture - thanks D.), but those values only serve as the active values when NO UserPref has yet been SAVED and also BECOMES the UserPref unless they are first modified prior to saving. In short, by making that change you are effectively CHOOSING 'Dark Mode' for every first-time user. Of course you could say the same of ?"Light Mode"? as it currently stands right now. Thus a 'light/dark' mode PREFERENCE would need to pretty much SUPPLY a PALLETE of multiple pre-chosen values (times two) to let the USER make THEIR choice, not yours. Yeah, a dark/light preference is possible, but even YOU admitted to tweaking it several times before you were satisfied. As long as you CAN change them, it really comes down to how important it is to you. When it comes to preferences all I know is whatever one person picks, it'll be WRONG for someone else. There is color-blindness, different monitor characteristics, and God knows what else to consider. There is even the online-help (which IS KEYED to the defined defaults). Wanna try to explain to someone what a blue/pink/purple stoplight analogy is trying to convey? Preferences can be very DIFFICULT. They are like opinions, everyone has one.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After a bunch of downloads, I determined that tkdiff 6.0 was actually r207, which is what Ralph actually had, so he wasn't exploring. That was me - I had r209 checked out.
I'm working backward tagging some 5.x releases - the important, non-janky ones, I hope - so we don't have to guess every time. Unless you happen to have a list, Michael? That would save me a few hours of work.
Linux has dark modes too. People do like them. I think dark mode should be implemented cross-platform, not just on Mac. I don't know if many changes should be made to the default colors for that. I picked out some of the current text colors, but many people think I'm nuts :-) I say, adjust any that are invisible on one mode or other, and otherwise let people pick their own.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK - having now LOOKED at Ralph's actual changes, I'd agree that they are tilted toward the Mac platform a bit too much to consider retaining as mainline code. One question I STILL have is what was the point of ADDING the Left/Right arrow keys as ALTERNATE keyboard accelerators? Why not just CHANGE the accelerators directly (something the EXISTING Preferences allows you to do: see the 'Behavior' Tab)? Did you really need TWO accelerators EACH to jump to a Next (or Prev) difference region?
While its true that Linux systems DO recognize the IDEA of 'light/dark' themes, It's NOT an Operating System ability, but a Window/Display manager feature. But then there is GNOME, KDE, just to name TWO, making it impractical to try to incorporate into a tool (TkDiff) that tries VERY HARD to stay platform agnostic. But that's not to say TkDiff won't consider trying to PROVIDE an equivalent means of accomplishing the GOAL of 'light/dark' -- but it could require a bit of individual tuning to achieve a further aspect (Desktop harmony) which some people conflate with the notion of "light/dark".
In any event, it will be considered for a future enhancement, so thanks for the interest and effort. You are (of course) free to modify anything you choose (its Open Source after all), but keeping you modifications up-to-date will be yours to deal with.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi!
In case anyone's interested, I've tweaked version 6.0 from 2025-07-07 as follows:
tkdiff is running great here on MacOS 26 with the homebrew version of tcl-tk.
As of 2026, I still consider tkdiff to be one of the fastest and wonderfully straightforward graphical diff tools, so two thumbs up to the authors!
Last edit: Ralph Schauner 2026-05-14
I'm the person with the Mac. Thanks, kewl. Good idea on the cursor left and right.
A couple of quick comments. First, this seems to be done on revision 208, whereas 209 was the release version. It makes a pretty short patch against r208. Yes, I know that's what tagging is for, and we absolutely should have tagged r209 as REL-6-0 and so on all the way back to REL-5-0. Especially since we don't use development branches much. There are only about 13 diffs with r208, which I'm attaching as a patch file.
Second, the text colors except for background and foreground are easily set in Preferences->Appearance, and they're likely to be saved already in the user's ~/.tkdiffrc. I kept seeing Tomato until I remembered that my ~/.tkdiffrc was probably overriding your defaults :-) Maybe we could interrogate the system for dark background rather than hard-coding white.
Third, I don't remember whether Michael has an objection to using ttk::scrollbar. We argue about ttk:: all the time :-)
dorothyr
Screenshot on the Mac with default settings, so Michael knows what we're talkin' about.
Thanks @dorothyr!
Yes, I know the preferences. I've added the colors to the defaults because it took me some time to get it the way I liked it and I wanted to make life easier for first-time users :)
As for release 209, it seems like the 209 was released literally an hour after I downloaded 208, bad luck on my side...
Good idea!
After not touching tk for many years, it was a little revelation for me to see how terribly slow SwiftUI can be with large files, compared to the old tcl/tk combo which runs like a race car in comparison on recent Apple Silicon.
Last edit: Ralph Schauner 2026-05-15
Now that I think about it, maybe adding a new "dark mode" preference is the way to go. It would probably require a restart, but some things do.
Also possibly I'm wrong about exactly which revision 6.0 was. I'll figure it out for sure and then I'll tag.
It's funny to hear that tcl/tk is fast at something, because at work I used to hand off to Perl to do any intensive parsing that was needed. I guess it's still good for some things!
OK - a bunch of points:
After a bunch of downloads, I determined that tkdiff 6.0 was actually r207, which is what Ralph actually had, so he wasn't exploring. That was me - I had r209 checked out.
I'm working backward tagging some 5.x releases - the important, non-janky ones, I hope - so we don't have to guess every time. Unless you happen to have a list, Michael? That would save me a few hours of work.
Linux has dark modes too. People do like them. I think dark mode should be implemented cross-platform, not just on Mac. I don't know if many changes should be made to the default colors for that. I picked out some of the current text colors, but many people think I'm nuts :-) I say, adjust any that are invisible on one mode or other, and otherwise let people pick their own.
OK - having now LOOKED at Ralph's actual changes, I'd agree that they are tilted toward the Mac platform a bit too much to consider retaining as mainline code. One question I STILL have is what was the point of ADDING the Left/Right arrow keys as ALTERNATE keyboard accelerators? Why not just CHANGE the accelerators directly (something the EXISTING Preferences allows you to do: see the 'Behavior' Tab)? Did you really need TWO accelerators EACH to jump to a Next (or Prev) difference region?
While its true that Linux systems DO recognize the IDEA of 'light/dark' themes, It's NOT an Operating System ability, but a Window/Display manager feature. But then there is GNOME, KDE, just to name TWO, making it impractical to try to incorporate into a tool (TkDiff) that tries VERY HARD to stay platform agnostic. But that's not to say TkDiff won't consider trying to PROVIDE an equivalent means of accomplishing the GOAL of 'light/dark' -- but it could require a bit of individual tuning to achieve a further aspect (Desktop harmony) which some people conflate with the notion of "light/dark".
In any event, it will be considered for a future enhancement, so thanks for the interest and effort. You are (of course) free to modify anything you choose (its Open Source after all), but keeping you modifications up-to-date will be yours to deal with.