Re: adding elastic tabstops to a widget

[Owen Taylor <otaylor redhat com>]

On Tue, 2008-08-19 at 23:39 +0200, Nick Gravgaard wrote:
> Hi all,
> 
> I'm trying to make a proper GTK text editing widget that supports
> elastic tabstops [1] with a view to being able to use it in the near
> future in a PyGTK project (a programmer's text editor), and perhaps one
> day getting it added to GtkTextView or GtkSourceView.
> 
> I have something pretty close to being finished. I've developed it by
> hacking the main Pango and GTK code directly rather than making new GTK
> objects that inherit from the standard objects - I figured I'd get the
> functionality working properly before moving the code into new files. It
> consists of 2 parts:
> 
> 1. Modified PangoTab structure to contain "width" (distance between tab
> characters) and "contents_width" (width of text between tabs) values,
> instead of "location" (distance from left margin to tab).
[...]

> 2. Modified gtktextview.c (or gtktextlayout.c - not sure which is a
> better place) to get and set PangoTabs' width and contents_width values
> as text is inserted/deleted etc. This makes up most of the code.
[...]

I talked with some with Nick about this yesterday on IRC and wanted to
summarize here.

My personal opinion on the elastic tab idea is that it's quite neat, and
if tabs worked that way, my life would be better. But it's hard for me
to see how to get from the way that tabs work now to the elastic tabs
model ... I wouldn't want to commit code that used elastic tabs to a
public project because then it would be indented weirdly for everybody
who didn't have elastic tabs. So, I think it's better to focus on how we
can make it possible to implement an elastic-tabs editor with
GtkTextView rather than adding the feature itself to GtkTextView. 

It turns out that the PangoTab changes are mostly an optimization .. to
be able to use the same structure to set tabs on a PangoLayout as to be
able to store the cached lengths of the different segments of a line.
So, I don't think they are needed in 

It also seems that you should mostly be able to do what is needed for
GtkTextView using the public API from a subclass or application. There
is one missing piece:

 - You need to be able to tell when parts of the GtkTextView are 
   revalidated (that is, layout has happpened for those lines.)

Right now, the only way to do this is to get the not-really-public
GtkTextLayout object for the GtkTextView and connect to it's ::changed
signal. This is hackish from C (requires accessing a non-public
structure field), and much more hackish from Python (I gave Nick some
code using ctypes that manages to pull out the GtkTextLayout with some
effort.) And such hacks won't work at all in GTK+ 3.0. So, I think a
::range-validated signal on GtkTextView would be a good addtion.

It also would be useful to have a way of attaching "user data" to a line
of a GtkTextView. (In this case, what you want to store is a cache of
the segment widths for a line.) It is possible to keep a lookaside data
structure in sync with the GtkTextView, but it's a bit awkward and
inefficient.

- Owen