H, I just upodated to 5.6 and I am having a very weird problem. When I do my diff between two files the diff keeps jumping up and down inside the tkdiff window without me doing anything. I have removed my old .tkdiffrc files but that did not help.
OK....going back to 5..5.3 has the same problem, which it did not have before. The differnce is that I have updated my systems from Fedora 36 to Fedora 37. Versions of tk and tcl dif not change, 8.6.12.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your description comes across as somewhat vague; Not exactly sure what is meant by "jumping up and down". Presuming you are correct about no changes to the Tcl/Tk versions in the Fedora upgrade you made, I can only comment on the nature of the changes made for TkDiff V5.6.
You should not have needed to remove the prior ".tkdiffrc" file, as all that would do is revert your personal preferences from whatever you had saved them as to NOW become the values that exist as the hardcoded (builtin) defaults (colors/fonts/etc).
TkDiff V5.6 addressed an unfortunate mental lapse in over-zealously applying a coding technique into a function that handled the jump-scroll WITHIN the Merge-Preview window (when displayed, and the CURRENT diff-region is changed) which, in fact, was simply INAPPROPRIATE. Additionally, it was discovered that recursion-based searching (for file candidates) was missing in the input-format case where only a SINGLE file specification had been provided. This proved limiting when the intended SCM was "Vpath" as it prevented the use of a source "tree" as opposed to a single Directory.
That constitutes the differences between V5.6 and V5.5.3, so GIVEN your description that both versions "behave the same" is actually a reasonable situation.
So this begs the following questions:
1. Was V5.5.3 the version you HAD been using before the Fedora upgrade?
2. On what platform (Mac,Linux,Unix,Windows)?
3. Does the specific file-pair being compared involve an SCM to supply one (or both) files?
4. Is this "jumping" regular (eg. a fixed amount) or random?
5. Is it cyclical (ie. bouncing among the SAME sets of lines)
6. Does it happen IN ADDITION to any scrolling attempts by you (eg. can you AFFECT it)?
7. Does it prevent you from introducing valid commands (eg. changing the current hunk)?
Frankly, it almost SOUNDS like a stuck key on the keyboard, but even that wouldn't quite explain the reversal of motion you described.
HOWEVER - there is a potential explanation that concerns me, given that the TK version is in excess of Tk8.6.5 --- where TkDiff automatically uses a DIFFERENT method of ensuring left/right text alignment as opposed to earlier TK versions. I cant say for certain just yet that this is a cause, but I find it unnerving that it "fits" your situation (scrolling actions -PLUS- a TK>8.6.5). I may need you to run with some extra command-line flags set, depending on the answers from above.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the extensive explanation. The problem is happening on desktop machines running Fedora 37 Linux, under KDE and NVIDIA graphics card. I just tried this on my laptop that is also running the same Fedora 37 but has Intel HD graphics. I tkdiff'ed the same files as on desktop and the jumping around is not there. I got an error message the first time I ran it but not on subsequent runs. The error messahe on laptop (I did not get this on desltop) was:
can't read "g(tooltip_id)": no such element in array
can't read "g(tooltip_id)": no such element in array
while executing
"after cancel $g(tooltip_id)"
(procedure "iTT_PopDown" line 4)
invoked from within
"iTT_PopDown"
(command bound to event)
UnfortunatelyduetotheThanksgivingholidayinUSIwon't be at work where my desktop machine is until Monday. At that point I will make a video of the problem.
PS: I am using X11 not Wayland on all machines,
~
~
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can safely ignore the error message. While I agree it shouldn't happen, it is innocuous and unrelated to the original problem. Its most likely nothing but an unfortunate confluence of your mouse position at the time the main display comes into existence, and then happens to DETECT the mouse being moved OUT of some screen element that was expected to have popped-up a ToolTip (which never happened, because the move INTO the screen element was never seen). I've made a note to repair this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, the problem has disappeared now. It was a problem on multiple machines. I presume some of the upgrades to Fedora 37 has fixed the problem. Must have been some graphical glitch. Thanks for your answers and if I see it again I will report it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Closing the ticket. Thanks for reporting (it's how things get better). For what its worth, a general review of the code under concern suggests it should NOT have been able to occur as described, but that doesn't mean it didn't happen for you. Apparently your computer wished to take off for the Thanksgiving break a day or two early (lol)! We will take this up should it ever be reported again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK....going back to 5..5.3 has the same problem, which it did not have before. The differnce is that I have updated my systems from Fedora 36 to Fedora 37. Versions of tk and tcl dif not change, 8.6.12.
Your description comes across as somewhat vague; Not exactly sure what is meant by "jumping up and down". Presuming you are correct about no changes to the Tcl/Tk versions in the Fedora upgrade you made, I can only comment on the nature of the changes made for TkDiff V5.6.
You should not have needed to remove the prior ".tkdiffrc" file, as all that would do is revert your personal preferences from whatever you had saved them as to NOW become the values that exist as the hardcoded (builtin) defaults (colors/fonts/etc).
TkDiff V5.6 addressed an unfortunate mental lapse in over-zealously applying a coding technique into a function that handled the jump-scroll WITHIN the Merge-Preview window (when displayed, and the CURRENT diff-region is changed) which, in fact, was simply INAPPROPRIATE. Additionally, it was discovered that recursion-based searching (for file candidates) was missing in the input-format case where only a SINGLE file specification had been provided. This proved limiting when the intended SCM was "Vpath" as it prevented the use of a source "tree" as opposed to a single Directory.
That constitutes the differences between V5.6 and V5.5.3, so GIVEN your description that both versions "behave the same" is actually a reasonable situation.
So this begs the following questions:
1. Was V5.5.3 the version you HAD been using before the Fedora upgrade?
2. On what platform (Mac,Linux,Unix,Windows)?
3. Does the specific file-pair being compared involve an SCM to supply one (or both) files?
4. Is this "jumping" regular (eg. a fixed amount) or random?
5. Is it cyclical (ie. bouncing among the SAME sets of lines)
6. Does it happen IN ADDITION to any scrolling attempts by you (eg. can you AFFECT it)?
7. Does it prevent you from introducing valid commands (eg. changing the current hunk)?
Frankly, it almost SOUNDS like a stuck key on the keyboard, but even that wouldn't quite explain the reversal of motion you described.
HOWEVER - there is a potential explanation that concerns me, given that the TK version is in excess of Tk8.6.5 --- where TkDiff automatically uses a DIFFERENT method of ensuring left/right text alignment as opposed to earlier TK versions. I cant say for certain just yet that this is a cause, but I find it unnerving that it "fits" your situation (scrolling actions -PLUS- a TK>8.6.5). I may need you to run with some extra command-line flags set, depending on the answers from above.
Thank you for the extensive explanation. The problem is happening on desktop machines running Fedora 37 Linux, under KDE and NVIDIA graphics card. I just tried this on my laptop that is also running the same Fedora 37 but has Intel HD graphics. I tkdiff'ed the same files as on desktop and the jumping around is not there. I got an error message the first time I ran it but not on subsequent runs. The error messahe on laptop (I did not get this on desltop) was:
can't read "g(tooltip_id)": no such element in array
can't read "g(tooltip_id)": no such element in array
while executing
"after cancel $g(tooltip_id)"
(procedure "iTT_PopDown" line 4)
invoked from within
"iTT_PopDown"
(command bound to event)
PS: I am using X11 not Wayland on all machines,
~
~
You can safely ignore the error message. While I agree it shouldn't happen, it is innocuous and unrelated to the original problem. Its most likely nothing but an unfortunate confluence of your mouse position at the time the main display comes into existence, and then happens to DETECT the mouse being moved OUT of some screen element that was expected to have popped-up a ToolTip (which never happened, because the move INTO the screen element was never seen). I've made a note to repair this.
Well, the problem has disappeared now. It was a problem on multiple machines. I presume some of the upgrades to Fedora 37 has fixed the problem. Must have been some graphical glitch. Thanks for your answers and if I see it again I will report it.
All's well that ends well?
Closing the ticket. Thanks for reporting (it's how things get better). For what its worth, a general review of the code under concern suggests it should NOT have been able to occur as described, but that doesn't mean it didn't happen for you. Apparently your computer wished to take off for the Thanksgiving break a day or two early (lol)! We will take this up should it ever be reported again.