Version: 3.3 (using KDE 3.3.1, (3.1)) Compiler: gcc version 3.3.5 (Debian 1:3.3.5-4) OS: Linux (x86_64) release 2.6.9-ac6 If you delete a large chunk of text, the vertical slider doesn't rescale. It stay tiny and you have to move it a long way before it has any effect on the document. It feels like the sort of thing that should be handled by a generic subroutine (or whatever the term is in KDE's case).
Hi David, thanks for taking the time to fill out a bug report.. This is going to be interesting to fix. resizing the scrollbars does happen in a common subroutine, but that subroutine (or more likely it's helper functions) will need some modification to behave correctly in this case. If we have two documents, A (source) and B (destination), and a diff D, call A(D) the height of diff D in document A, likewise for B, then the current algorithm takes the height of D as MAX(A(D),B(D)). It should, instead, take into account wether A(D) has been pushed into B(D) by applying the diff, and in that case use A(D) instead of MAX(...) Some additional calls to slotUpdateScrollBars may be neccaray with this more refined scrollbar behaviour. I'll fix this in kompare3_branch when I get around to rewriting all the diff application stuff, but for HEAD i'll make this a JJ. As with all kompare JJs, if you want to take a look at this, I'd love to hear from you - either by email, or by irc (#kompare on irc.kde.org). - Jeff
Jeff Snyder wrote: >------- You are receiving this mail because: ------- >You reported the bug, or are watching the reporter. > >http://bugs.kde.org/show_bug.cgi?id=97055 >jeff-kdecvs caffeinated me uk changed: > > What |Removed |Added >---------------------------------------------------------------------------- > Status|UNCONFIRMED |NEW > everconfirmed|0 |1 > Summary|Vertical slider doesn't |JJ: Kompare: Vertical slider > |rescale with file length |doesn't rescale with file > |changes |length changes > > > >------- Additional Comments From jeff-kdecvs caffeinated me uk 2005-01-16 01:17 ------- >Hi David, thanks for taking the time to fill out a bug report.. > >This is going to be interesting to fix. resizing the scrollbars does happen in a common subroutine, but that subroutine (or more likely it's helper functions) will need some modification to behave correctly in this case. > >If we have two documents, A (source) and B (destination), and a diff D, call A(D) the height of diff D in document A, likewise for B, then the current algorithm takes the height of D as MAX(A(D),B(D)). > >It should, instead, take into account wether A(D) has been pushed into B(D) by applying the diff, and in that case use A(D) instead of MAX(...) > >Some additional calls to slotUpdateScrollBars may be neccaray with this more refined scrollbar behaviour. > >I'll fix this in kompare3_branch when I get around to rewriting all the diff application stuff, but for HEAD i'll make this a JJ. > >As with all kompare JJs, if you want to take a look at this, I'd love to hear from you - either by email, or by irc (#kompare on irc.kde.org). > >- Jeff > > Hi Jeff, What's a JJ? You've summarized the situation admirably. Here's an attempt to spell out the four conditions. Let M be the length relevant to the slider. These will always hold: * start condition: M is the length of the longest document, A or B * minimum value of M is always the length of A, since in kompare the source document doesn't change * maximum value of M is A+B, since all of A could be treated as a diff to B and added to all of B Second, we have a condition we don't need to worry about: * A > B and A(D)<B(D) (the diff removes material from B) ==> M is unchanged Third, we have a set of conditions where we need to rescale the slider in a simple manner: * A < B and A(D)>B(D) (the diff removes material from B) => M = B - ( A(D) - B(D) ) * A < B and A(D)<B(D) (the diff adds material to B) => M = B +( A(D) - B(D) ) Fourth, we have a tricky case: * If A > B and A(D)>B(D) (the diff adds material to B), then if [B +( A(D) - B(D) ] > A; then M = B + ( A(D) - B(D) ) else M = A (M is unchanged) I'm sure I've made some mistake somewhere. I don't do c programming, but I've just been doing this sort of thing in bash scripts. Dave
Hi Dave, On Sunday 16 January 2005 02:25, David Liontooth wrote: > What's a JJ? "JJ" stands for "Junior Job" - It marks the bug as a job suitable for someone who's new to kde programming - all the JJs are shown in a list linked off of the front page of bugs.kde.org so they're easy to find. > You've summarized the situation admirably. Here's an attempt to spell > out the four conditions. Well, I guess I could have been clearer :/ (read on..) > Let M be the length relevant to the slider. These will always hold: > > * start condition: M is the length of the longest document, A or B > * minimum value of M is always the length of A, since in kompare the > source document doesn't change > * maximum value of M is A+B, since all of A could be treated as a diff > to B and added to all of B <snip> Thanks for going to all the trouble to work this out, but I think we're talking about different things -- when I said a "D if a diff", i meant D is an instance of the class Diff2::Difference in kompare, which represents a single one of the coloured patches displayed in kompare, not diff asin a patch. I'll make a better distinction from here on.. In the psuedo-math I was using, "A+B" or "A+A(D)" are nonsensical - A and B were supposed to be just letters representing the two sides, not numbers (lengths?) of the whole documents. The total range of the slider is calculated by adding up MAX(A(D),B(D)) for all of the Differences in the diff being displayed, plus the height of the unchanged lines. so, to (hopefully) clarify: if A(D) > B(D), A(D) = MAX(....), so nothing needs to be done but if A(D) < B(D), and D is applied, the lines of D in B are not shown anywhere (since the lines of D in A are shown on both sides), so we should use A(D) as the total hight of D when calculating the total range of the slider. When it comes to coding that, there's no concept of "something needs to be done", since we'll just recalculate every time it might have changed, using if(applied) then A(D) else MAX(...) as the height of D. Cheers, Jeff
This is gonna be a little spammy... I'm reassigning everything that's currently assigned to bruggie (who's been the default assignee for bugs since time began) to the new list address. Bruggie: if you're working on one or more of these atm, please snatch 'em back.. Everyone, esp. Joshua and Bruggie: if this genrates 33 mails, my sincere apologies..
Ehm, is this bug still valid? It is currently listed as the only JJ job for Kompare, which is why I looked at it at all..
Well, trying to reproduce the bug is the first part of the job. ;-) But I can have a try at reproducing it as well. I don't know if this is still reproducible, I'd also have to test. If you're looking for other tasks you can do, you can have a look at the wishlist bugs, maybe you'll find something that's not too hard for you to implement. (Some of them are quite complex though, some are simpler.)
No worries. I just tried at first to reproduce and I thought it wasn't there anymore. I reproduced it now. Anyway, was mostly curious as to why you had kept a JJ open for four years (and no one picked it up). Then I realized it is really a small bug and a very nice JJ. I might have a look at it sometime when I have some time to spare. Love the excellent program you have made btw, makes my life that much easier!:)