java-gnome-hackers

[java-gnome-hackers] TextView frustrations

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

Well, maybe a quarter of the way into figuring out TextView, I have to
note that I am vastly dissatisfied. 

It's an ugly API. I mean, sure TreeView/TreeModel were complex, but
powerful and you could, once you'd wrapped your mind around it, deal
with that complexity.

TextView/TextBuffer on the other hand, are underwhelming. Whether the
cursor is visible or not is a method on TextView, but placeCursor() is a
method on TextBuffer. Oh, except for placeCursorOnscreen(), which is
back on TextView.

If you want to move a pointer forward you use TextIter's forwardLine().
Unless you want to move it forward a line in the Widget, in which case
it's TextView's forwardDisplayLine(). And so on.

Oh yeah - don't even try to make scrolling work sensibly.

It's all pretty discouraging. With TreeViewColumn/CellRenderer we made a
fairly significant API style change but one which introduced some real
sanity to the family as a whole. I'm pretty pleased with how that worked
out. With TextView/TextBuffer, however, I am at a bit of a loss. It
doesn't feel right. Every time I try to use it to do something it is
either not where I expect it to be or not there at all.

So obviously I am feeling the temptation to "do something about it" but
unlike before it is really not obvious what unifying vision would drive
such a divergence.

Even more  obviously I must be missing something, but without someone
who *knows* GtkTextView *really* well working on this it's been a bit
tough.

        [I already have more than enough to drive what I wrote 4-5 years
        ago, but then I was just displaying text, not manipulating it]

To this point Stefan Prelle has been contributing boat loads, and has
done much of the grunt work. So we're getting there. What's missing is
the big picture

Anyone who has an interest in seeing TextView coverage in java-gnome
would probably be of great help.

There has been a bit of tinkering; changing scroll_to_mark and
scroll_to_iter into a family of scrollTo() overrides seemed to make
sense. It didn't help that it turns out that the real
gtk_text_view_scroll_to_iter() is *busted* and doesn't work for shit.

My work is available on the branch at 'hackers/andrew/textview' branch;
and most of Stefan's contributions are included in there. That branch is
*NOT* anywhere near merge ready, but you can at least tinker with it.
This isn't 'mainline'; API subject to change, etc etc.

AfC
Sydney

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] TextView frustrations

[Gerald B. <ger...@gm...>]

Hi There. Just saw this. Thought I'd chime in. Here are some thoughts.....

On Wed, Jun 11, 2008 at 7:34 PM, Andrew Cowie <
an...@op...> wrote:

> Well, maybe a quarter of the way into figuring out TextView, I have to
> note that I am vastly dissatisfied.
>
> It's an ugly API. I mean, sure TreeView/TreeModel were complex, but
> powerful and you could, once you'd wrapped your mind around it, deal
> with that complexity.
>
> TextView/TextBuffer on the other hand, are underwhelming. Whether the
> cursor is visible or not is a method on TextView, but placeCursor() is a
> method on TextBuffer. Oh, except for placeCursorOnscreen(), which is
> back on TextView.
>

I've never used this API before, but, this feels and sounds correct to me.
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?


> If you want to move a pointer forward you use TextIter's forwardLine().
> Unless you want to move it forward a line in the Widget, in which case
> it's TextView's forwardDisplayLine(). And so on.


Again, seems right. Do you want to move forward a logical line of text or a
displayed line of text? Display -> View, Logical -> Buffer. Sounds right to
me. No?


>
> Oh yeah - don't even try to make scrolling work sensibly.
>

Can't comment on this. What seems not sensible? Just curious.


>
> It's all pretty discouraging. With TreeViewColumn/CellRenderer we made a
> fairly significant API style change but one which introduced some real
> sanity to the family as a whole. I'm pretty pleased with how that worked
> out. With TextView/TextBuffer, however, I am at a bit of a loss. It
> doesn't feel right. Every time I try to use it to do something it is
> either not where I expect it to be or not there at all.
>
> So obviously I am feeling the temptation to "do something about it" but
> unlike before it is really not obvious what unifying vision would drive
> such a divergence.
>
> Even more  obviously I must be missing something, but without someone
> who *knows* GtkTextView *really* well working on this it's been a bit
> tough.
>

Wish I could be of more help here. Never really used this API.
Unfortunately, don't have any spare time right now any-who (so feel free to
tell me to pound salt ;) )


>        [I already have more than enough to drive what I wrote 4-5 years
>        ago, but then I was just displaying text, not manipulating it]
>
> To this point Stefan Prelle has been contributing boat loads, and has
> done much of the grunt work. So we're getting there. What's missing is
> the big picture
>
> Anyone who has an interest in seeing TextView coverage in java-gnome
> would probably be of great help.
>
> There has been a bit of tinkering; changing scroll_to_mark and
> scroll_to_iter into a family of scrollTo() overrides seemed to make
> sense. It didn't help that it turns out that the real
> gtk_text_view_scroll_to_iter() is *busted* and doesn't work for shit.
>
> My work is available on the branch at 'hackers/andrew/textview' branch;
> and most of Stefan's contributions are included in there. That branch is
> *NOT* anywhere near merge ready, but you can at least tinker with it.
> This isn't 'mainline'; API subject to change, etc etc.
>
> AfC
> Sydney
>
> --
> Andrew Frederick Cowie
>
> Operational Dynamics is an operations and engineering consultancy
> focusing on IT strategy, organizational architecture, systems
> review, and effective procedures for change management. We actively
> carry out research and development in these areas on behalf of our
> clients, and enable successful use of open source in their mission
> critical enterprises, worldwide.
>
> http://www.operationaldynamics.com/
>
> Sydney   New York   Toronto   London
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>
>

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