To: lablgtk at kaba.or.jp
From: Alan Post <apost at recalcitrant.org>
Subject:  OT: text diff tools (was Re: Request for advice (long))
Date: Fri, 24 Mar 2006 07:10:25 +0000 (UTC)
Lines: 60
Message-ID:  <slrne276qv.7j9.apost at recalcitrant.org>
References:  <20060323205410.5bb789f8.ocaml-erikd at mega-nerd.com>
Content-Type: text
Content-Length: 2619

In article <20060323205410.5bb789f8.ocaml-erikd at mega-nerd.com>, Erik de Castro Lopo wrote:
> 
> The project I'm working on is a graphical diff program. The idea is
> to load up two sightly different versions of the same source code
> file and have them displayed side by side with the differences
> highlighted.

My response is about the problem domain, rather than lablgtk2.
Apologies in advance to any bored or otherwise annoyed people.

I don't know if you're shopping for algorithms, but when I wrote a
(Java) three-way merge tool at a summer job long ago, I used an
algorithm by Eugene Myers (the sequence guy):
  "4b.  A Linear Space Refinement"
from his 1986 paper:
  "An O(ND) Difference Algorithm and Its Variations"
  http://www.eecs.berkeley.edu/~gene/Papers/diff.pdf
found here:
  http://www.eecs.berkeley.edu/~gene/vita.htm

The algorithm was speedy (unless the minimal edit script was long),
precise (it found the minimal edit script), and used little additional
memory.  Also, it was pleasantly simple.

> The main requirements for this are two panes of text, separated by a
> narrow drawing_area widget that has a representation of the full
> file. There also needs to be a single horizontal and single vertical
> scroll bar which will act simultaneously on both text widgets.

One thing to watch out for is whether putting the whole file (or even
just all the differeces) in a text widget, then putting that text
widget in a scrollview, will use too much RAM.  I haven't tried that
with GTK2, but (Java) Swing used lots and lots of memory for each byte
of text in the text widget.  I ended up using a nonstandard text
display widget that integrated a scroll bar.

> After giving it a brief try, I don't think the scrolled_window
> container typesuggested by Olivier will work. The problem is that
> while it is possible to have the two text areas and the drawing area
> inside a scrolled_window I cannot figure out how to make the two
> text widgets appear stay at the same size regardless of the size of
> the parent window.

My (Java) program registered callbacks for window resize events, and
resized the document views to keep the ratio the same as before the
resize.

>   - Use two scrolled_window widgets side by side, with the un-needed
>     scrollbars hidden or disabled (not even sure if this is
>     possible). If its not possible to hide the unused scrollbars,
>     then they will need to be hooked up so that they act in unison
>     (is this possible).

My (Java) program registered callbacks for scrollbar movement events,
and kept the two scrollable entities in sync.

HTH,

  Alan