Re: [java-gnome-hackers] TextView frustrations

[Andrew C. <an...@op...>]

On Wed, 2008-06-11 at 21:42 -0400, Gerald Butler wrote:

> Change position of cursor within the text without regard to view, use
> the "TextBuffer" method. Place it with respect to a particular view,
> use the "TextView" method. Seems Right! No?

What it is is a pain in the ass to use.


> Do you want to move forward a logical line of text or a displayed line
> of text?

Once you know that's the way things are, this makes "sense". The problem
is one of discoverability. While we can (and will) heavily cross
reference our documentation, it is a right royal pain to have to jump
from one object to another to manipulate what is, in essence, the same
thing.

In TreeView, complex as it is, there is a clear progression; you set
things up and use one set of methods. You manipulate the view on that
data with a second set which you reach after a few hops from the first.
Yes, learning the hops is tricky (which is why I went to so much trouble
to document it) but as I look at the code I have using the TextView
stuff so far it is a right bloody mess, bouncing around all over the
place. Not intuitive, not discoverable [ie, code completion won't help
you a damn because 50% change what you're looking for isn't there. So
you've got to check both, what a pain]

That's what's bugging me.

++

The fact that it is so hard to force the cursor and the viewport to show
the end of the TextBuffer is, apparently, partially a bug in GTK, but
the java-gnome code for this was *hideous*:

TextBuffer buffer;
TextView view;
ScrolledWindow scroll;
TextIter start, end;
TextMark mark;

// populate
...

start = buffer.getIterStart();
end = buffer.getIterEnd();

// attempt to force TextView to calculate heights
buffer.placeCursor(start);

// now attempt to scroll the TextView. It may or may not work.
mark = buffer.createMark(end, false);
view.scrollToMark(mark, 0.0, 0.0, 0.0);

// now move the cursor to the end of the TextView.
buffer.placeCursor(end);


Even with the scrollTo() methods having collapsed to a series of
overrides, it's still back and forth and back and forth.
And if you're lucky, the thing will have scrolled. Working with the
Scrollbars/Ranges, Adjustments, and ScrolledWindow doesn't help either.

++

Just for comparison, I'll give you another example: I've just found out
that IconView does *not* use TreeSelection, having the selection related
methods and signals directly on IconView and not on a helper class like
TreeView has.

Either both should use a helper class, or neither. Consistency.

[So, yes, I am now vaguely considering that TreeSelection could go away.
It is, after all, "something that could have been on GtkTreeView" to
paraphrase the GTK documentation. In all likelihood we will just leave
this alone, but I *really* hate it when things aren't symmetrical and
have worked extraordinarily hard to preserve that quality in the
underlying plumbing, in the code generator, and in our public API. I
suppose there is a point where one just gives up and acknowledges that
the underlying GNOME library doesn't have the desired characteristic.
Alas.]

AfC
Sydney