Pardon the length of this posting. Too many issues for a single ticket.
Using a MacBook Pro running MacOS version 10.14.6 (Mojave), and with "tkdiff" in /Applications, the following 6 GUI-related findings were observed with TkDiff 5.0:
Un-Mac-like Terminal session window
Unlike behavior with TkDiff 4.2, an interactive Terminal session window appears after the user double-clicks on the icon for /Applications/tkdiff; an illustrative Terminal session printout reads as follows:
Is an interactive Terminal session necessary? Is the Terminal window display configurable? I work mostly on a Mac and sometimes on Windows in a Wish+console environment, and find the Terminal window distracting when no error occurs.
One of the great values of TkDiff 4.2 for my use is that it is generally available as a reliable kit that includes a Wish executable. As a feature request, could that packaging be repeated "in the 21st century" with a current binary release of Wish for MacOS, especially considering that the currently shipping MacOS "Catalina" requires 64-bit mode for all apps?
Either tooltips or button images+labels are not displayed properly.
With Wish 8.6.9, display of "New Diff" is normal, but tooltips do not appear upon mouse hovering over button images.
With Wish 8,5,9, display of "New Diff" is abnormal; the labels and images for dialog buttons are blank, but tooltips appear as expected upon mouse hovering over button images.
Both versions of Wish were obtained from ActiveTcl distributions. Other binary distributions of Wish that are current and generally available for Mac OSX could not be found.
See screenshots:
1 New Diff dlg w-fnames - after launch - Incomplete menu items.pdf
2 New Diff dlg wo:icons and wo:btn labels, but w:tooltip.pdf
Obscure warning message triggered from within TkDiff, but possibly due to system software
Terminal session appends the following "advisory message" when the user first clicks on a file icon using Tk's tk_getOpenFile, while navigating to select a file for the first time in TkDiff:
objc[33336]: Class FIFinderSyncExtensionHost is implemented in both /System/Library/PrivateFrameworks/FinderKit.framework/Versions/A/FinderKit (0x7fff8f5333d8) and /System/Library/PrivateFrameworks/FileProvider.framework/OverrideBundles/FinderSyncCollaborationFileProviderOverride.bundle/Contents/MacOS/FinderSyncCollaborationFileProviderOverride (0x10f1ddf50). One of the two will be used. Which one is undefined.
segmentation fault upon user clicking in menubar before diff action
With the "New Diff" dialog displayed but not completed, the user clicks in the Mac OSX menubar, to the right of the single menu item "Wish"; this triggers a segmentation fault. The fault occurs upon a Button-1 event in the menubar's blank area, or a Button-Release-1 event in the "Wish" menulist.
See the following error messages appearing in the Terminal session using Wish 8.6.9, or Wish 8.5.9, respectively:
Incorrect combobox pulldown action on a second monitor.
When a TkDiff window containing a combobox has been dragged to a second monitor, and the user clicks on the combobox button, the combobox pulldown widget may extend to bottom of the screen, to the bottom on a different monitor, or it may not appear at all.
The position of the window, relative to the boundaries of the main monitor, affects how the pulldown widget is rendered.
Inspection of Tcl source code suggests that combobox::ComputeGeometry may not adapt properly to a window that the user has repositioned to a location beyond the boundaries of the primary monitor. In particular, dragging a TkDiff window upward and/or leftward causes the combobox screen geometry to include negative offset values.
See screenshots:
3 Normal display, with combobox pulldown.pdf
(Note: screenshots 4 & 5 are paired, using a second monitor above a first monitor, respectively)
4 NewDiff dlg straddling monitors.pdf
5 NewDiff combobox pulldown spans primary monitor.pdf
(Note: screenshots 6 & 7 are paired, using a second monitor above a first monitor, respectively)
6 combobox window in upper monitor, pulldown on primary monitor.pdf
7 pulldown spans primary monitor while combobox on upper monitor.pdf
Probable typo in proc ::combobox::ComputeGeometry, line 12629:
" set height $screenheight" should be: "set height $screenHeight".
Correcting this typo does not correct the observed combobox pulldown behavior.
(Note: this may be an old bug; it can also be demonstrated in TkDiff 4.2, using a second monitor.)
Thanks in advance for any help you can provide,
Peter Martin
Wow.
First, let me thank you for taking the time to persue this avenue of communication. It'll be my first time trying to respond to something from this vantage point. Second I'll need to come clean and admit that I've been responsible for virtually everything that has happenned to TkDiff in the past 2 or so years (eg. V4.3 onward). The reasons why are unimportant, other than, like you (apparently), I was a long-time user of the package and had found the V4.2 version to be somewhat unusable - but in my case, from a Unix/Linux perspective . And it was because the Tcl/Tk environemnt had moved forward, while V4.2 languished a full decade in the past. Note that IN such an envronment, things like a "terminal window" is considered S.O.P (standard operating procedure)! But it also means something else in terms of the TkDiff "packaging" which is that BUNDLING of Wish, Tcl, etc. is NOT the norm for that platform.
As you've probably guessed by now, I dont OWN a Mac. SO alot of what you are describing leaves me kinda cold, for things you consider "normal". Nevertheless, I'm willing to TRY to understand your concerns, and to the extent I can figure out what is going on WITHOUT a Mac, I will do what I can. There is another ADMIN on this project (although not often her primary concern, EXCEPT for Mac issues [guess what machine she owns...]) and perhaps if she reads any of this she may chime in.
Now as I see it you kinda have 3 issues:
1. something with the display of buttons and/or tooltips
2. something else with the combobox and a multi-monitor setup
3. and finally some combination of packaging and/or invocation issues on the Mac itself.
I can speak, somewhat, to the first item. Mostly because I'm the one who has consistently screwed it up from release to release by making what I thought was a simplification of the code. After having fixed this problem (or actually my fellow admin did) I re-fixed it without realizing that on a MAC, the sequence of certain operations in TK are NOT interchangeable. When you DONT see the Tooltip appear, its likely because it is displaying UNDER the main window, and that is because ON A Mac, you CANT "raise" the window until AFTER you display it (Windows and X11 say either way is fine). I have since LEARNED this and from V5.1 on, I assure you THAT problem will not occur again. Ever.
But the part about the buttons being BLANK, Ive heard of before, and IIRC, the solution was a newer version of the TK software on the Mac platform it was reported on. Perhaps a search of closed tickets would identify the details. Hence, not specifically my problem, per se (and that's NOT an excuse I use lightly).
But that makes a sort-of segue' (sp?) to item #3 and your concerns about the former binary distributions of TkDiff. It was exactly for these kinds of reasons, we chose to get out of the business of "packaging" TkDiff, with the idiosyncracies of individual releases of the Tcl/Tk environment. We dont feel its OUR responsibility to ensure YOUR platform is consistent with what amounts to a "third party" offering. There are too many to track, we don't have the equipment to test with, and, when something is actually WRONG, we can't fix it! What we warrant (these days at least) is that the TkDiff SCRIPT is consistent with the defined behavior of the minimal VERSION of Tcl/Tk that we require for the script to operate properly. Right now (and as of V4.3 onward) that is TK8.5. We try NOT to push the envelope too hard, despite later versions offering advantages specifically because we do not wish to disadvantage the users who for whatever reasons are stuck in older environments. And while the binary distribution might mitigate that issue somewhat (by pre-packing a known environment) the overhead to do so is no small undertaking, let alone the lack of machinery with which to DO it. As to what happens with various windows or menus or anything else terribly Mac-ish, I'm lost.
That leaves Item #2 - the combobox. I will admit, the combobox is software that is likely nearly as old as TkDiff itself (and I'm talking DECADES). That it works at all is a testament to its author who graciously contributed it TO TkDiff MANY years ago. So if its not "playing nice" with the latest Mac incarnation of a multi-screen workstation, I'm really not that terribly surprised! It itself is a "pure" Tcl implementation (no modules or other system-level support) so with THAT in mind, if the distinctions of what HAPPENS to certain widgets as they cross the imaginary boundary of a virtual screen COULD be understood, there is a chance that the software could be enhanced to understand what is happening. But then there is that question of machinery, and now its not only Mac, but multiple screens. I've always wanted a dual screen, just because I have a frequent need to see considerable reference material when working, so I spend a LOT of time flipping back and forth among windows. But I can't even say if the combobox NOT working would occur in a platform OUTSIDE of Mac either, OR if the formulation of a multiscreen setup would necessarily be platform dependant!
I've only recently entertained the idea of trying to bring an Active State Tcl environment to an old Windows machine I happen to have, and so far, I can tell you that has NOT gone well. But I've been busy working toward TkDiff V5.1 (which I'm HOPING is not far off), so even the things I'd like to do with "other" machines is presently in a back seat. I will tell you that IF I can sucessfully get the Windows machine up and running, I did ruminate about trying to pickup an older, used Mac, specifically to be able to SEE that which I read about in various trouble tickets. But I can't speculate quite when that might be. Maybe someone will like me at Christmas?
So thats what I can tell you off the top of my head. But I tend to be a fairly conscientious fellow and I dont just "blow things off" because they are hard, or even seemingly impossible. I will look into your concerns as I can slot in the research time to read/google/experiment, I just can't promise a whole lot of action, particularly at the moment. Although I'll admit I'm curious, how would spreading TkDiff across TWO monitors really HELP whatever it is you are doing? Its kinda designed as a monlithic display entity?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, I'm the Mac consultant (though I too am mostly unix/linux when it comes to programming.). And I'm Windows-less, too.
What Michael said, with a couple additional comments.
Bundling a tcl/tk executable would, I think, solve more version-conflict conundrums than it would create. But doing so is getting to feel more and more like a lost cause with the increasingly walled gardens in which software can be deployed on Mac and Windows. Unless I pay $$ to become a Mac developer, and go through unkown permutations to authorize the software, you will still have to disable security settings to get my "foreign" package to run. I just invoke tkdiff from a terminal command line, since I always have a terminal open if I'm doing anything but surfing. Unix habits die hard, I guess.
Re the combobox specifically: there's a native ttk::combobox now, and using that instead of the older homemade one might work to good effect. I could possibly be persuaded to experiment with that, if Michael would like.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suppose it would have been a good idea to LOOK at some of the pictures before my earlier response, but between that and some careful READING of the OS-provided messages (and just some simple musings as I brushed my teeth). I have a couple of addtional comments:
1. Thanks Dorothy for stepping in (didn't know about your 2-monitor setup -- sweet!). But, in an odd sort of way, I kinda prefer Bryans combobox BECAUSE it is 'pure' Tcl (not to mention directly embedded and thus open to enhancement, which HAS occurred in the past). Also didn't realize about the $$ aspect; I think I'll stay in the altruistic world of Unix/Linux, thank you very much (and that has nothing to do with being a former Bell Labs employee - the land of Unix; really, it doesn't)!
2. The thing with the combobox pulldown makes me think that the implementation may be confused about which DISPLAY it should be talking to when it maps the pulldown window. I seem to recall reading about '-displayof' options (somewhere) that perhaps combobox is in (apparent) desperate need of. I'll try to locate where I read it and see if it might help. Perhaps such things were not "en vogue" when it was originally built (Bryan didn't generally miss much)?
3. I understand in the 'point-and-click' world that mundane text output feels passe'; but even MacOS -which, if I recollect my history, is actually a derivative of BSD-Unix, seems to understand that its pretty much the ideal spot for diagnostics that may be useful. To me, that means there has GOT to be a way to suppress or redirect it elsewhere which tells me this may have more to do with HOW TkDiff was installed into the Mac, or exactly what incantation is used to ACTUALLY invoke it. I can't believe that things like "stdout" or "stderr" output are simply NOT permitted for a Mac! Sometimes ya gotta take responsibility for what happens on your own machine.
4. In a similar sense, I noticed something strange in one of the messages that was provided. Again, keep in mind I'm no Mac-guru, but wasn't one of the complaints about some message (from the OS) about it finding TWO of something and warning you that it can't guarantee which one will actually be used? I saw a passing reference in one of the messages about '/usr/bin' and '/usr/local/bin' (I believe in reference to Wish) - Do you perhaps have TWO Tcl/Tk installations on your machine and it is MacOS that is confused about which it should be using? I don't know anything about this thing they call "Finder", but it makes me wonder some.
Thats all I've got, for now. I did track out the "other" references about the tk::fileOpen dialog messing up, and while most of that seemed to point more to Apple not getting SOMETHING quite right with its Tk implementation, there was a vague reference to the calling proc not "getting the focus BACK" on its return, which ONE person claimed could be resolved by forcing that focus shift. Again, hard for me to tell without a Mac.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks to the developers for your thoughtful and cooperative
replies. I get it that you're the current staff-in-full for
maintaining/upgrading TkDiff, and, oh yes, it's a volunteer effort.
Kudos; this is good to know.
The following indicators of multi-platform compatibility appear on
the SF project page for TkDiff:
1) Literally, "Windows | Mac
| Linux"
2) A screenshot of the TkDiff comparison view, clearly
indicating a Mac-based platform
The implication is that, as is the case for Tcl/Tk,
Python, and selected other scripting languages, TkDiff
is meant to perform as intended on the explicitly named
platforms. If serious faults are found in deliverables, then
users might wonder if you over-promised and under-delivered.
Alas, your motives and personal preferences won't affect the
users' perceptions. In the present case, you're also blessed with
people like me who want TkDiff 5.0 to look and feel like the
preceding TkDiff 4.2 that they're used to, and they want to enjoy
the upgrades that are newly incorporated. Now I understand why
TkDiff 5.0 has not been announced on comp.lang.tcl or on the
Tcler's Wiki -- you can't legitimately warrant that TkDiff
5.0 will perform as intended on platforms other than
Linux. This is not at all a criticism. From what you have said,
it is just the current state of affairs for a work in progress.
Michael has stated what can be warranted: "What we
warrant (these days at least) is that the TkDiff SCRIPT is
consistent with the defined behavior of the minimal VERSION of
Tcl/Tk that we require for the script to operate properly. Right
now (and as of V4.3 onward) that is TK8.5."
By inspection of the Tcl that is bundled in
TkDiff 4.2, I find that the value of Tcl's global variable
"tcl_patchLevel"is 8.5.9. This
suggests that what Michael is warranting now has not changed
since V4.2, and possibly earlier. It also suggests that
the difficulties that I reported cannot be completely discounted
based on version mismatches -- I was using Tcl/Tk 8.5.9, and I
demonstrated that what I observed applied comparably but not
exactly to a later version of Tcl/Tk.
So let's look at Tcl/Tk 8.5 more closely. The ActiveState website
currently provides binary distributions of ActiveTcl for Linux,
Windows, and Mac that are based on the final version in the Tcl/Tk
8.5 development stream:
These binary distributions
would seem to meet Michael's criterion for what could serve as
reference platforms for TkDiff 5.0. They are all 64-bit
compatible, derived from Tcl/Tk 8.5.18 (Windows/Mac), or Tcl/Tk
8.5.19 (Linux) and were committed by ActiveState on May 1,
2019. How convenient!
Going forward, these platform-specific binary releases, combined
with a consistent source release, could give you a consistent
technological basis for developing and evaluating TkDiff 5.x on
different platforms. Plus, they obviate a need to become a
registered developer, particularly at Apple.
Maybe you should have these builds at hand and operational for
testing your work-products.
On the question of delivering an executable
bundle that incorporates TkDiff, we can defer that for now. But
for future reference, I see signs in the binary code for TkDiff
4.2 that the mature, reliable Metakit was used to create the
deliverables. This is further good news, in that it reinforces
the belief that becoming a platform-specific certified developer
is unnecessary. For more on Metakit, see the following:
Within the current Tcl script for TkDiff, the current code for
combobox is ancient, on internet time. (See, for example, https://wiki.tcl-lang.org/page/combobox) Replacing it with
ttk::combobox would provide a widget where other people have
already thought a lot about platform compatibility issues in
current time. It should be added that dipping into ttk:-based
widgets may require a little learning curve for controlling
widget styles. A vetted implementation of tooltip has also been
in Tklib for a while. (See: https://core.tcl-lang.org/tklib/doc/trunk/embedded/www/tklib/files/modules/tooltip/tooltip.html)
You could replace existing Tcl code for both combobox and
tooltip with recent modules that come built-in with the binary
distributions mentioned above.
With regard to the split-monitors question, Apple agrees with
you. I only set that up for the sake of creating screenshots
that dramatize a point for the human viewers of the screenshots,
i.e., you, the developers. Usually on a Mac, a window split
across monitors is automatically snapped
at the time of completing a drag'n'drop action
to the monitor that was displaying the majority of the split
view. This is a Mac feature. (There's also an obscure use case
for split screening while calibrating adjacent monitors when the monitors use
different color balancing, which was a notorious problem in the
days of CRT's.)
Michael states, "the implementation may
be confused about which DISPLAY it should be talking to..."
This follows from an X11 model, and a limitation based on which
ports were available on a given machine. Tk follows a different
model that presumes a single virtual screen, even with multiple
monitors. The virtual screen is more like a bounding box within
which one or more monitors are configured as abutting rectangles
on a plane. See Tk help info for "wm maxsize." The default
values for max size depend on where the OS is told additional
monitors are located. The user can reconfigure the logical
positions of multiple monitors without physically moving them,
even while TkDiff is running. Therefore, TkDiff needs to be
dynamic with respect to window management. To be clear, this
does not represent a pressure to "modernize" TkDiff for changing
software, but rather a broadening from previously
uncommon conditions to what are now more
likely use cases.
Michael states, "I can't believe that
things like "stdout" or "stderr" output are simply NOT permitted
for a Mac!" Good; no such belief need apply. The console that
Wish provides on Mac and Windows is akin to a shell that
services the stdout and stderr channels. Using TkCon on Linux
would be comparable. Launching a debug version in development
might show the console by default, whereas launching a release
version in production might hide the console. Without the
console, Mac apps have to rely on a "status bar" with a one-line
text message, dialog boxes, log files, or other files. In the
other-than-Unix world, being forced to rely on a command-line
interpreter is considered user-unfriendly. I believe that
TkDiff should be user-friendly wherever it is supposed to be
serviceable.
Michael states, "Do you perhaps have
TWO Tcl/Tk installations on your machine and it is MacOS that is
confused...?" Yes, I intentionally have two installations, and
no, MacOS is not confused. I could have more than two
installations. I could install multiple versions of other
resources as well, and even on Windows, if I wanted to.
Installing multiple versions of Notepad++ on Windows comes to
mind. How does one perform root cause analysis of some fault
condition thought to be due to a dependency in an external
resource without being able to compare multiple versions
functionally? Nobody asked, but I
also use more than one login account to isolate possibly
confounding conditions, and I manage with
close attention the startup files, like .tclshrc, .wishrc, and
.tkdiffrc, when I run a test case.
Michael states, "I don't know anything
about this thing they call "Finder", but it makes me wonder
some." Uh-oh. I
would suggest that you consider posting to SourceForge a
statement regarding
System Requirements and current
Platform Compatibility. This is common practice for
commercial software products. It's clear that you wish
to offer to others what you wanted to be generally
available, but it's not clear that you can provide to
others what they would want and/or expect from a common
feature set. My impression is that the way that TkDiff
5.0 is currently presented is misleading to non-Linux
users.
Finally, the current situation
presents a need for a structured build-and-test process. It
seems that the current developers
wish to offer to others something that goes beyond what the
developers themselves wanted for their personal use (i.e.,
Mac/Windows compatibility beyond native Linux performance).
But this situation also presents a challenge that appears to
exceed initial expectations, initial commitments, and current
capabilities. Personally, I believe that you already need
additional human resources on the project. So, going forward,
what exactly do you want the TkDiff project to
deliver to users, and what will you be doing to ensure delivery
of reliable and vetted work-products?
I suppose it would have been a good idea to LOOK at some of
the pictures before my earlier response, but between that and
some careful READING of the OS-provided messages (and just
some simple musings as I brushed my teeth). I have a couple of
addtional comments:
1. Thanks Dorothy for stepping in (didn't know about your
2-monitor setup -- sweet!). But, in an odd sort of way, I
kinda prefer Bryans combobox BECAUSE it is 'pure' Tcl (not to
mention directly embedded and thus open to enhancement, which
HAS occurred in the past). Also didn't realize about the $$
aspect; I think I'll stay in the altruistic world of
Unix/Linux, thank you very much (and that has nothing to do
with being a former Bell Labs employee - the land of Unix;
really, it doesn't)!
2. The thing with the combobox pulldown makes me think that
the implementation may be confused about which
DISPLAY it should be talking to when it maps the pulldown
window. I seem to recall reading about '-displayof' options
(somewhere) that perhaps combobox is in
(apparent) desperate need of. I'll try to locate where I read
it and see if it might help. Perhaps such things were not "en
vogue" when it was originally built (Bryan didn't
generally miss much)?
3. I understand in the 'point-and-click' world that mundane
text output feels passe'; but even MacOS -which, if I
recollect my history, is actually a derivative of BSD-Unix,
seems to understand that its pretty much the ideal spot for
diagnostics that may be useful. To me, that means
there has GOT to be a way to suppress or redirect
it elsewhere which tells me this may have more to do with HOW
TkDiff was installed into the Mac, or exactly what incantation
is used to ACTUALLY invoke it. I can't believe that things
like "stdout" or "stderr" output are simply NOT permitted for
a Mac! Sometimes ya gotta take responsibility for what happens
on your own machine.
4. In a similar sense, I noticed something strange in one of
the messages that was provided. Again, keep in mind I'm no
Mac-guru, but wasn't one of the complaints about some message
(from the OS) about it finding TWO of something and
warning you that it can't guarantee which one will actually be
used? I saw a passing reference in one of the messages about
'/usr/bin' and '/usr/local/bin' (I believe in reference to
Wish) - Do you perhaps have TWO Tcl/Tk installations on your
machine and it is MacOS that is confused about which it should
be using? I don't know anything about this thing they call
"Finder", but it makes me wonder some.
Thats all I've got, for now. I did track out the "other"
references about the tk::fileOpen dialog messing up, and while
most of that seemed to point more to Apple not getting
SOMETHING quite right with its Tk implementation, there was a
vague reference to the calling proc not "getting
the focus BACK" on its return, which ONE person claimed
could be resolved by forcing that focus shift. Again, hard for
me to tell without a Mac.
Just to respond (as I STILL have not truly looked into many of the points raised) in no particular order:
1. That we mention 3 platforms on the SF website, owes more to the idea that TkDiff is implemented in a scripting language that has existing interpreters for each of the named platforms. To the degree that such interpreters do not fully implement exactly the same behavior on their respective machines (and they do NOT), we are often forced into arcane workarounds, which are neither desireable NOR (sadly) completely transparent. And that Mac screenshot? I think the reason it was placed there was simply to "announce" its original availability on OS X (years ago), by one of our admins that I'd guess had a hand in it, and has "gone quiet" since that time.
2. TkDiff is neither Linux-centric nor mired in X11. TK itself is predicated on the X11 graphic paradigm (its bind manpage makes that abundantly clear, referring the reader to the X11 manuals itself). To the extent that the TK implementation on Mac fails to emulate that environment sufficeintly is hardly the fault of TkDiff. Point in question is the difficulty you related with the menubar and some spurious mouseclick behavior. ALL that TK provides to us, as script developers, is a means to define our menu and subsequently identify such menu as belonging to the CONCEPT of a "menubar"; what happens after that is ALL TK and its implementation on any given platform. Further, according to your description, it occurred to "the right of the Wish item". I'm inclined to believe that it not only lies within TK itself, but belongs to Active State and/or the Tcl/Tk core team (as TkDiff does not POST a "Wish" item to any menu, let alone the menubar).
3. Given that last item, I reiterate that TkDiff is an open source project, with limited resources, and looks to be as usefull as possible, to the degree possible, given the realities of all that entails. Comparing it to "commercial offerings", or "best practices" in testing or support is a bit unfair. We are not a 'distribution channel' for bundling Active State products any more than we are a 'supplier' for the GNU Diff engine, despite implied interdependencies on both (or their equivalents). I get it. I really do. You want, what you want; and its apparent what that means is a "drop-in" component where all the kinks have been buffed and polished to fit seamlessly. And while I dont actually disagree with that viewpoint (from your perspective), frankly, what keeps me working on TkDiff is the intracacies of what TkDiff is intended to accomplish, not how well it can be 'packaged/sold' to the public at large. Should I lose that interest, then, well... you are free to use V4.2 or V5.0 or beyond as suits your needs. Its why we don't "End-of-Life" as a matter of course, nor prevent anyone from contributing. That TkDiff has not been mentioned on the Tcl'ers Wiki, or anywhere else, I think speaks more to its perceived existance as abandoned software by some (even the SF site classifies us as "mature")- and THAT was likely cultivated by its near decade of dormancy (long before I came on the scene) - not because I/we are rabid Linux developers trying to disadvantage other platforms, nor trying to mislead our potential users.
4. Dont mistake my musings over the minutiae of your very detailed observations (thank you for those, honestly) as anything more than simply looking for patterns of correlation. All I saw was 2 things in an error message, and 2 things claiming to exist. It was NOT a carefully crafted investigation. The fact that I may not know much about 'Finder' or the Mac platform in general, is nothing more than a logistics and exposure issue.
5. Your provided pictures were actually quite helpful, and I may have a real explanation about the combobox anomaly. I MAY even be able to fix it, fairly quickly, and given what I BELIEVE is wrong, I may not even require a dual monitor setup to test it. But remember - I still have not truly investigated it - because I'm doing other things. However, I promise to DO that investigation before sending my current work out-the-door; there's no point in making you wait forever for what MAY be a simple fix.
You are a valuable commodity - a user willing and capable of articulating your observations and viewpoints. Feedback is a crucial piece of the open source environment, and I appreciate your candidness. I will certainly take your concerns under advisement going forward. Please stay tuned for further developments.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You're quite right that we need contributors. I put out tkdiff releases for 14 YEARS even though it was never my project, because no one else stepped up until Michael did. And I never dived into the internals. I'm more of a short-order UI cook.
When I was working and had access to a wonderland of machines, I was positioned to do cross-platform work. That's not the case anymore. Then a MacOS update broke my ancient Windows VM and I no longer have the sweet, sweet tech income to buy Windows licenses for no good reason. I didn't know that starkit stuff still worked. It looked to me to be abandoned.
Anyway it's FOSS, folks are always welcome to jump in and help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Moments ago V5.1 of TkDiff was released to all platforms. Included in that release is a workaround for the mutiple-monitor display issues that were brought forth in this recent discussion. We intend to pursue this further as we have substantial proof that the root cause resides in the Tk-Core itself, and thus is not solvable by any means at the scripting language level. We sincerely hope that the workaround will suffice until such time as a real resolution can be put forth. The specifics of the workaround are inconsequential as they are both silently and automatically applied, requiring no particular action on the users part, but have been tested and appear to function as intended. The issues mentioned beyond the graphical rendering ones are still under consideration, but pertain more to the delivery of the tool than with the operational details of TkDiff proper. As such they are subject to other constraints such as available hardware and the variability of numerous aspects, not the least of which is the diversity of the supported base, and staffing levels. We will do our best, with the resources at hand.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Pardon the length of this posting. Too many issues for a single ticket.
Using a MacBook Pro running MacOS version 10.14.6 (Mojave), and with "tkdiff" in /Applications, the following 6 GUI-related findings were observed with TkDiff 5.0:
Unlike behavior with TkDiff 4.2, an interactive Terminal session window appears after the user double-clicks on the icon for /Applications/tkdiff; an illustrative Terminal session printout reads as follows:
Is an interactive Terminal session necessary? Is the Terminal window display configurable? I work mostly on a Mac and sometimes on Windows in a Wish+console environment, and find the Terminal window distracting when no error occurs.
One of the great values of TkDiff 4.2 for my use is that it is generally available as a reliable kit that includes a Wish executable. As a feature request, could that packaging be repeated "in the 21st century" with a current binary release of Wish for MacOS, especially considering that the currently shipping MacOS "Catalina" requires 64-bit mode for all apps?
With Wish 8.6.9, display of "New Diff" is normal, but tooltips do not appear upon mouse hovering over button images.
With Wish 8,5,9, display of "New Diff" is abnormal; the labels and images for dialog buttons are blank, but tooltips appear as expected upon mouse hovering over button images.
Both versions of Wish were obtained from ActiveTcl distributions. Other binary distributions of Wish that are current and generally available for Mac OSX could not be found.
See screenshots:
1 New Diff dlg w-fnames - after launch - Incomplete menu items.pdf
2 New Diff dlg wo:icons and wo:btn labels, but w:tooltip.pdf
Terminal session appends the following "advisory message" when the user first clicks on a file icon using Tk's tk_getOpenFile, while navigating to select a file for the first time in TkDiff:
objc[33336]: Class FIFinderSyncExtensionHost is implemented in both /System/Library/PrivateFrameworks/FinderKit.framework/Versions/A/FinderKit (0x7fff8f5333d8) and /System/Library/PrivateFrameworks/FileProvider.framework/OverrideBundles/FinderSyncCollaborationFileProviderOverride.bundle/Contents/MacOS/FinderSyncCollaborationFileProviderOverride (0x10f1ddf50). One of the two will be used. Which one is undefined.
With the "New Diff" dialog displayed but not completed, the user clicks in the Mac OSX menubar, to the right of the single menu item "Wish"; this triggers a segmentation fault. The fault occurs upon a Button-1 event in the menubar's blank area, or a Button-Release-1 event in the "Wish" menulist.
See the following error messages appearing in the Terminal session using Wish 8.6.9, or Wish 8.5.9, respectively:
When a TkDiff window containing a combobox has been dragged to a second monitor, and the user clicks on the combobox button, the combobox pulldown widget may extend to bottom of the screen, to the bottom on a different monitor, or it may not appear at all.
The position of the window, relative to the boundaries of the main monitor, affects how the pulldown widget is rendered.
Inspection of Tcl source code suggests that combobox::ComputeGeometry may not adapt properly to a window that the user has repositioned to a location beyond the boundaries of the primary monitor. In particular, dragging a TkDiff window upward and/or leftward causes the combobox screen geometry to include negative offset values.
See screenshots:
3 Normal display, with combobox pulldown.pdf
(Note: screenshots 4 & 5 are paired, using a second monitor above a first monitor, respectively)
4 NewDiff dlg straddling monitors.pdf
5 NewDiff combobox pulldown spans primary monitor.pdf
(Note: screenshots 6 & 7 are paired, using a second monitor above a first monitor, respectively)
6 combobox window in upper monitor, pulldown on primary monitor.pdf
7 pulldown spans primary monitor while combobox on upper monitor.pdf
Probable typo in proc ::combobox::ComputeGeometry, line 12629:
" set height $screenheight" should be: "set height $screenHeight".
Correcting this typo does not correct the observed combobox pulldown behavior.
(Note: this may be an old bug; it can also be demonstrated in TkDiff 4.2, using a second monitor.)
Thanks in advance for any help you can provide,
Peter Martin
Wow.
First, let me thank you for taking the time to persue this avenue of communication. It'll be my first time trying to respond to something from this vantage point. Second I'll need to come clean and admit that I've been responsible for virtually everything that has happenned to TkDiff in the past 2 or so years (eg. V4.3 onward). The reasons why are unimportant, other than, like you (apparently), I was a long-time user of the package and had found the V4.2 version to be somewhat unusable - but in my case, from a Unix/Linux perspective . And it was because the Tcl/Tk environemnt had moved forward, while V4.2 languished a full decade in the past. Note that IN such an envronment, things like a "terminal window" is considered S.O.P (standard operating procedure)! But it also means something else in terms of the TkDiff "packaging" which is that BUNDLING of Wish, Tcl, etc. is NOT the norm for that platform.
As you've probably guessed by now, I dont OWN a Mac. SO alot of what you are describing leaves me kinda cold, for things you consider "normal". Nevertheless, I'm willing to TRY to understand your concerns, and to the extent I can figure out what is going on WITHOUT a Mac, I will do what I can. There is another ADMIN on this project (although not often her primary concern, EXCEPT for Mac issues [guess what machine she owns...]) and perhaps if she reads any of this she may chime in.
Now as I see it you kinda have 3 issues:
1. something with the display of buttons and/or tooltips
2. something else with the combobox and a multi-monitor setup
3. and finally some combination of packaging and/or invocation issues on the Mac itself.
I can speak, somewhat, to the first item. Mostly because I'm the one who has consistently screwed it up from release to release by making what I thought was a simplification of the code. After having fixed this problem (or actually my fellow admin did) I re-fixed it without realizing that on a MAC, the sequence of certain operations in TK are NOT interchangeable. When you DONT see the Tooltip appear, its likely because it is displaying UNDER the main window, and that is because ON A Mac, you CANT "raise" the window until AFTER you display it (Windows and X11 say either way is fine). I have since LEARNED this and from V5.1 on, I assure you THAT problem will not occur again. Ever.
But the part about the buttons being BLANK, Ive heard of before, and IIRC, the solution was a newer version of the TK software on the Mac platform it was reported on. Perhaps a search of closed tickets would identify the details. Hence, not specifically my problem, per se (and that's NOT an excuse I use lightly).
But that makes a sort-of segue' (sp?) to item #3 and your concerns about the former binary distributions of TkDiff. It was exactly for these kinds of reasons, we chose to get out of the business of "packaging" TkDiff, with the idiosyncracies of individual releases of the Tcl/Tk environment. We dont feel its OUR responsibility to ensure YOUR platform is consistent with what amounts to a "third party" offering. There are too many to track, we don't have the equipment to test with, and, when something is actually WRONG, we can't fix it! What we warrant (these days at least) is that the TkDiff SCRIPT is consistent with the defined behavior of the minimal VERSION of Tcl/Tk that we require for the script to operate properly. Right now (and as of V4.3 onward) that is TK8.5. We try NOT to push the envelope too hard, despite later versions offering advantages specifically because we do not wish to disadvantage the users who for whatever reasons are stuck in older environments. And while the binary distribution might mitigate that issue somewhat (by pre-packing a known environment) the overhead to do so is no small undertaking, let alone the lack of machinery with which to DO it. As to what happens with various windows or menus or anything else terribly Mac-ish, I'm lost.
That leaves Item #2 - the combobox. I will admit, the combobox is software that is likely nearly as old as TkDiff itself (and I'm talking DECADES). That it works at all is a testament to its author who graciously contributed it TO TkDiff MANY years ago. So if its not "playing nice" with the latest Mac incarnation of a multi-screen workstation, I'm really not that terribly surprised! It itself is a "pure" Tcl implementation (no modules or other system-level support) so with THAT in mind, if the distinctions of what HAPPENS to certain widgets as they cross the imaginary boundary of a virtual screen COULD be understood, there is a chance that the software could be enhanced to understand what is happening. But then there is that question of machinery, and now its not only Mac, but multiple screens. I've always wanted a dual screen, just because I have a frequent need to see considerable reference material when working, so I spend a LOT of time flipping back and forth among windows. But I can't even say if the combobox NOT working would occur in a platform OUTSIDE of Mac either, OR if the formulation of a multiscreen setup would necessarily be platform dependant!
I've only recently entertained the idea of trying to bring an Active State Tcl environment to an old Windows machine I happen to have, and so far, I can tell you that has NOT gone well. But I've been busy working toward TkDiff V5.1 (which I'm HOPING is not far off), so even the things I'd like to do with "other" machines is presently in a back seat. I will tell you that IF I can sucessfully get the Windows machine up and running, I did ruminate about trying to pickup an older, used Mac, specifically to be able to SEE that which I read about in various trouble tickets. But I can't speculate quite when that might be. Maybe someone will like me at Christmas?
So thats what I can tell you off the top of my head. But I tend to be a fairly conscientious fellow and I dont just "blow things off" because they are hard, or even seemingly impossible. I will look into your concerns as I can slot in the research time to read/google/experiment, I just can't promise a whole lot of action, particularly at the moment. Although I'll admit I'm curious, how would spreading TkDiff across TWO monitors really HELP whatever it is you are doing? Its kinda designed as a monlithic display entity?
Hi, I'm the Mac consultant (though I too am mostly unix/linux when it comes to programming.). And I'm Windows-less, too.
What Michael said, with a couple additional comments.
Bundling a tcl/tk executable would, I think, solve more version-conflict conundrums than it would create. But doing so is getting to feel more and more like a lost cause with the increasingly walled gardens in which software can be deployed on Mac and Windows. Unless I pay $$ to become a Mac developer, and go through unkown permutations to authorize the software, you will still have to disable security settings to get my "foreign" package to run. I just invoke tkdiff from a terminal command line, since I always have a terminal open if I'm doing anything but surfing. Unix habits die hard, I guess.
Re the combobox specifically: there's a native ttk::combobox now, and using that instead of the older homemade one might work to good effect. I could possibly be persuaded to experiment with that, if Michael would like.
BTW, I completely understand needing two monitors, and I have such a setup on my Mac Mini :-)
I suppose it would have been a good idea to LOOK at some of the pictures before my earlier response, but between that and some careful READING of the OS-provided messages (and just some simple musings as I brushed my teeth). I have a couple of addtional comments:
1. Thanks Dorothy for stepping in (didn't know about your 2-monitor setup -- sweet!). But, in an odd sort of way, I kinda prefer Bryans combobox BECAUSE it is 'pure' Tcl (not to mention directly embedded and thus open to enhancement, which HAS occurred in the past). Also didn't realize about the $$ aspect; I think I'll stay in the altruistic world of Unix/Linux, thank you very much (and that has nothing to do with being a former Bell Labs employee - the land of Unix; really, it doesn't)!
2. The thing with the combobox pulldown makes me think that the implementation may be confused about which DISPLAY it should be talking to when it maps the pulldown window. I seem to recall reading about '-displayof' options (somewhere) that perhaps combobox is in (apparent) desperate need of. I'll try to locate where I read it and see if it might help. Perhaps such things were not "en vogue" when it was originally built (Bryan didn't generally miss much)?
3. I understand in the 'point-and-click' world that mundane text output feels passe'; but even MacOS -which, if I recollect my history, is actually a derivative of BSD-Unix, seems to understand that its pretty much the ideal spot for diagnostics that may be useful. To me, that means there has GOT to be a way to suppress or redirect it elsewhere which tells me this may have more to do with HOW TkDiff was installed into the Mac, or exactly what incantation is used to ACTUALLY invoke it. I can't believe that things like "stdout" or "stderr" output are simply NOT permitted for a Mac! Sometimes ya gotta take responsibility for what happens on your own machine.
4. In a similar sense, I noticed something strange in one of the messages that was provided. Again, keep in mind I'm no Mac-guru, but wasn't one of the complaints about some message (from the OS) about it finding TWO of something and warning you that it can't guarantee which one will actually be used? I saw a passing reference in one of the messages about '/usr/bin' and '/usr/local/bin' (I believe in reference to Wish) - Do you perhaps have TWO Tcl/Tk installations on your machine and it is MacOS that is confused about which it should be using? I don't know anything about this thing they call "Finder", but it makes me wonder some.
Thats all I've got, for now. I did track out the "other" references about the tk::fileOpen dialog messing up, and while most of that seemed to point more to Apple not getting SOMETHING quite right with its Tk implementation, there was a vague reference to the calling proc not "getting the focus BACK" on its return, which ONE person claimed could be resolved by forcing that focus shift. Again, hard for me to tell without a Mac.
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
Thanks to the developers for your thoughtful and cooperative
replies. I get it that you're the current staff-in-full for
maintaining/upgrading TkDiff, and, oh yes, it's a volunteer effort.
Kudos; this is good to know.
The following indicators of multi-platform compatibility appear on
the SF project page for TkDiff:
The implication is that, as is the case for Tcl/Tk,
Python, and selected other scripting languages, TkDiff
is meant to perform as intended on the explicitly named
platforms. If serious faults are found in deliverables, then
users might wonder if you over-promised and under-delivered.
Alas, your motives and personal preferences won't affect the
users' perceptions. In the present case, you're also blessed with
people like me who want TkDiff 5.0 to look and feel like the
preceding TkDiff 4.2 that they're used to, and they want to enjoy
the upgrades that are newly incorporated. Now I understand why
TkDiff 5.0 has not been announced on comp.lang.tcl or on the
Tcler's Wiki -- you can't legitimately warrant that TkDiff
5.0 will perform as intended on platforms other than
Linux. This is not at all a criticism. From what you have said,
it is just the current state of affairs for a work in progress.
Michael has stated what can be warranted: "What we
warrant (these days at least) is that the TkDiff SCRIPT is
consistent with the defined behavior of the minimal VERSION of
Tcl/Tk that we require for the script to operate properly. Right
now (and as of V4.3 onward) that is TK8.5."
By inspection of the Tcl that is bundled in
TkDiff 4.2, I find that the value of Tcl's global variable
"tcl_patchLevel" is 8.5.9. This
suggests that what Michael is warranting now has not changed
since V4.2, and possibly earlier. It also suggests that
the difficulties that I reported cannot be completely discounted
based on version mismatches -- I was using Tcl/Tk 8.5.9, and I
demonstrated that what I observed applied comparably but not
exactly to a later version of Tcl/Tk.
So let's look at Tcl/Tk 8.5 more closely. The ActiveState website
currently provides binary distributions of ActiveTcl for Linux,
Windows, and Mac that are based on the final version in the Tcl/Tk
8.5 development stream:
ActiveTcl-8.5.19.8519-x86_64-linux-glibc-2.5-403583.tar.gz
ActiveTcl-8.5.18.0.298892-win32-x86_64-threaded.exe
ActiveTcl-8.5.18.0.298892-macosx10.5-i386-x86_64-threaded.dmg
These binary distributions
would seem to meet Michael's criterion for what could serve as
reference platforms for TkDiff 5.0. They are all 64-bit
compatible, derived from Tcl/Tk 8.5.18 (Windows/Mac), or Tcl/Tk
8.5.19 (Linux) and were committed by ActiveState on May 1,
2019. How convenient!
See: https://platform.activestate.com/ActiveState/ActiveTcl-8.5/releases
The links for downloading these binary distributions are:
Linux build: https://platform.activestate.com/ActiveState/ActiveTcl-8.5/distributions?platformID=eef02e93-f4a9-5cca-a131-a388ecf57442
Windows build: https://platform.activestate.com/ActiveState/ActiveTcl-8.5/distributions?platformID=fb80c351-ff9a-5c0d-a655-251888eeab36
MacOS build: https://platform.activestate.com/ActiveState/ActiveTcl-8.5/distributions?platformID=aa7c0abf-d4a2-5896-8220-41c88b42c6c4
From the Tcl Community, the source releases for Tcl/Tk 8.5.19
are also available at: https://www.tcl.tk/software/tcltk/8.5.html
Going forward, these platform-specific binary releases, combined
with a consistent source release, could give you a consistent
technological basis for developing and evaluating TkDiff 5.x on
different platforms. Plus, they obviate a need to become a
registered developer, particularly at Apple.
Maybe you should have these builds at hand and operational for
testing your work-products.
On the question of delivering an executable
bundle that incorporates TkDiff, we can defer that for now. But
for future reference, I see signs in the binary code for TkDiff
4.2 that the mature, reliable Metakit was used to create the
deliverables. This is further good news, in that it reinforces
the belief that becoming a platform-specific certified developer
is unnecessary. For more on Metakit, see the following:
https://wiki.tcl-lang.org/page/Metakit
https://git.jeelabs.org/jcw/metakit
and
https://www.equi4.com/metakit.html (now sunsetted)
Within the current Tcl script for TkDiff, the current code for
combobox is ancient, on internet time. (See, for example,
https://wiki.tcl-lang.org/page/combobox) Replacing it with
ttk::combobox would provide a widget where other people have
already thought a lot about platform compatibility issues in
current time. It should be added that dipping into ttk:-based
widgets may require a little learning curve for controlling
widget styles. A vetted implementation of tooltip has also been
in Tklib for a while. (See:
https://core.tcl-lang.org/tklib/doc/trunk/embedded/www/tklib/files/modules/tooltip/tooltip.html)
You could replace existing Tcl code for both combobox and
tooltip with recent modules that come built-in with the binary
distributions mentioned above.
With regard to the split-monitors question, Apple agrees with
you. I only set that up for the sake of creating screenshots
that dramatize a point for the human viewers of the screenshots,
i.e., you, the developers. Usually on a Mac, a window split
across monitors is automatically snapped
at the time of completing a drag'n'drop action
to the monitor that was displaying the majority of the split
view. This is a Mac feature. (There's also an obscure use case
for split screening while calibrating adjacent monitors when the
monitors use
different color balancing, which was a notorious problem in the
days of CRT's.)
Michael states, "the implementation may
be confused about which DISPLAY it should be talking to..."
This follows from an X11 model, and a limitation based on which
ports were available on a given machine. Tk follows a different
model that presumes a single virtual screen, even with multiple
monitors. The virtual screen is more like a bounding box within
which one or more monitors are configured as abutting rectangles
on a plane. See Tk help info for "wm maxsize." The default
values for max size depend on where the OS is told additional
monitors are located. The user can reconfigure the logical
positions of multiple monitors without physically moving them,
even while TkDiff is running. Therefore, TkDiff needs to be
dynamic with respect to window management. To be clear, this
does not represent a pressure to "modernize" TkDiff for changing
software, but rather a broadening from previously
uncommon conditions to what are now more
likely use cases.
Michael states, "I can't believe that
things like "stdout" or "stderr" output are simply NOT permitted
for a Mac!" Good; no such belief need apply. The console that
Wish provides on Mac and Windows is akin to a shell that
services the stdout and stderr channels. Using TkCon on Linux
would be comparable. Launching a debug version in development
might show the console by default, whereas launching a release
version in production might hide the console. Without the
console, Mac apps have to rely on a "status bar" with a one-line
text message, dialog boxes, log files, or other files. In the
other-than-Unix world, being forced to rely on a command-line
interpreter is considered user-unfriendly. I believe that
TkDiff should be user-friendly wherever it is supposed to be
serviceable.
Michael states, "Do you perhaps have
TWO Tcl/Tk installations on your machine and it is MacOS that is
confused...?" Yes, I intentionally have two installations, and
no, MacOS is not confused. I could have more than two
installations. I could install multiple versions of other
resources as well, and even on Windows, if I wanted to.
Installing multiple versions of Notepad++ on Windows comes to
mind. How does one perform root cause analysis of some fault
condition thought to be due to a dependency in an external
resource without being able to compare multiple versions
functionally? Nobody asked, but I
also use more than one login account to isolate possibly
confounding conditions, and I manage with
close attention the startup files, like .tclshrc, .wishrc, and
.tkdiffrc, when I run a test case.
Michael states, "I don't know anything
about this thing they call "Finder", but it makes me wonder
some." Uh-oh. I
would suggest that you consider posting to SourceForge a
statement regarding
System Requirements
and
current
Platform Compatibility. This is common practice for
commercial software products. It's clear that you wish
to offer to others what you wanted to be generally
available, but it's not clear that you can provide to
others what they would want and/or expect from a common
feature set. My impression is that the way that TkDiff
5.0 is currently presented is misleading to non-Linux
users.
Finally, the current situation
presents a need for a structured build-and-test process. It
seems that the current developers
wish to offer to others something that goes beyond what the
developers themselves wanted for their personal use (i.e.,
Mac/Windows compatibility beyond native Linux performance).
But this situation also presents a challenge that appears to
exceed initial expectations, initial commitments, and current
capabilities. Personally, I believe that you already need
additional human resources on the project. So, going forward,
what exactly do you want the TkDiff project to
deliver to users, and what will you be doing to ensure delivery
of reliable and vetted work-products?
Regards,
Peter Martin
Just to respond (as I STILL have not truly looked into many of the points raised) in no particular order:
1. That we mention 3 platforms on the SF website, owes more to the idea that TkDiff is implemented in a scripting language that has existing interpreters for each of the named platforms. To the degree that such interpreters do not fully implement exactly the same behavior on their respective machines (and they do NOT), we are often forced into arcane workarounds, which are neither desireable NOR (sadly) completely transparent. And that Mac screenshot? I think the reason it was placed there was simply to "announce" its original availability on OS X (years ago), by one of our admins that I'd guess had a hand in it, and has "gone quiet" since that time.
2. TkDiff is neither Linux-centric nor mired in X11. TK itself is predicated on the X11 graphic paradigm (its bind manpage makes that abundantly clear, referring the reader to the X11 manuals itself). To the extent that the TK implementation on Mac fails to emulate that environment sufficeintly is hardly the fault of TkDiff. Point in question is the difficulty you related with the menubar and some spurious mouseclick behavior. ALL that TK provides to us, as script developers, is a means to define our menu and subsequently identify such menu as belonging to the CONCEPT of a "menubar"; what happens after that is ALL TK and its implementation on any given platform. Further, according to your description, it occurred to "the right of the Wish item". I'm inclined to believe that it not only lies within TK itself, but belongs to Active State and/or the Tcl/Tk core team (as TkDiff does not POST a "Wish" item to any menu, let alone the menubar).
3. Given that last item, I reiterate that TkDiff is an open source project, with limited resources, and looks to be as usefull as possible, to the degree possible, given the realities of all that entails. Comparing it to "commercial offerings", or "best practices" in testing or support is a bit unfair. We are not a 'distribution channel' for bundling Active State products any more than we are a 'supplier' for the GNU Diff engine, despite implied interdependencies on both (or their equivalents). I get it. I really do. You want, what you want; and its apparent what that means is a "drop-in" component where all the kinks have been buffed and polished to fit seamlessly. And while I dont actually disagree with that viewpoint (from your perspective), frankly, what keeps me working on TkDiff is the intracacies of what TkDiff is intended to accomplish, not how well it can be 'packaged/sold' to the public at large. Should I lose that interest, then, well... you are free to use V4.2 or V5.0 or beyond as suits your needs. Its why we don't "End-of-Life" as a matter of course, nor prevent anyone from contributing. That TkDiff has not been mentioned on the Tcl'ers Wiki, or anywhere else, I think speaks more to its perceived existance as abandoned software by some (even the SF site classifies us as "mature")- and THAT was likely cultivated by its near decade of dormancy (long before I came on the scene) - not because I/we are rabid Linux developers trying to disadvantage other platforms, nor trying to mislead our potential users.
4. Dont mistake my musings over the minutiae of your very detailed observations (thank you for those, honestly) as anything more than simply looking for patterns of correlation. All I saw was 2 things in an error message, and 2 things claiming to exist. It was NOT a carefully crafted investigation. The fact that I may not know much about 'Finder' or the Mac platform in general, is nothing more than a logistics and exposure issue.
5. Your provided pictures were actually quite helpful, and I may have a real explanation about the combobox anomaly. I MAY even be able to fix it, fairly quickly, and given what I BELIEVE is wrong, I may not even require a dual monitor setup to test it. But remember - I still have not truly investigated it - because I'm doing other things. However, I promise to DO that investigation before sending my current work out-the-door; there's no point in making you wait forever for what MAY be a simple fix.
You are a valuable commodity - a user willing and capable of articulating your observations and viewpoints. Feedback is a crucial piece of the open source environment, and I appreciate your candidness. I will certainly take your concerns under advisement going forward. Please stay tuned for further developments.
You're quite right that we need contributors. I put out tkdiff releases for 14 YEARS even though it was never my project, because no one else stepped up until Michael did. And I never dived into the internals. I'm more of a short-order UI cook.
When I was working and had access to a wonderland of machines, I was positioned to do cross-platform work. That's not the case anymore. Then a MacOS update broke my ancient Windows VM and I no longer have the sweet, sweet tech income to buy Windows licenses for no good reason. I didn't know that starkit stuff still worked. It looked to me to be abandoned.
Anyway it's FOSS, folks are always welcome to jump in and help.
Moments ago V5.1 of TkDiff was released to all platforms. Included in that release is a workaround for the mutiple-monitor display issues that were brought forth in this recent discussion. We intend to pursue this further as we have substantial proof that the root cause resides in the Tk-Core itself, and thus is not solvable by any means at the scripting language level. We sincerely hope that the workaround will suffice until such time as a real resolution can be put forth. The specifics of the workaround are inconsequential as they are both silently and automatically applied, requiring no particular action on the users part, but have been tested and appear to function as intended. The issues mentioned beyond the graphical rendering ones are still under consideration, but pertain more to the delivery of the tool than with the operational details of TkDiff proper. As such they are subject to other constraints such as available hardware and the variability of numerous aspects, not the least of which is the diversity of the supported base, and staffing levels. We will do our best, with the resources at hand.