Re: Making GtkEntry::scroll-offset read/write?

[David Trowbridge <davidt vmware com>]

The cursor logic looks sound, I think it's mostly an issue with the way that the pixel offsets are calculated in the presence of tabstops. I'll try to dig deeper and see if it's just a bug that can be fixed or a more structural problem.

I'll also go in and see what might be required to implement the widget directly in the GTK+ tree.

Thanks!
-David

----- Original Message -----
From: "Matthias Clasen" <matthias clasen gmail com>
To: "David Trowbridge" <davidt vmware com>
Cc: gtk-devel-list gnome org
Sent: Friday, February 8, 2013 6:38:44 AM
Subject: Re: Making GtkEntry::scroll-offset read/write?

On Thu, Feb 7, 2013 at 7:06 PM, David Trowbridge <davidt vmware com> wrote:
> I'm trying to port libview (http://view.sourceforge.net/) to Gtk+ 3.x, and something that I've run into is that the way that view::FieldEntry sets tabstops into the parent entry's PangoLayout causes the cursor position logic inside GtkEntry to break quite a bit. The way it's solved today is to have a notification callback on the scroll-offset field and always set it back to zero. This was always kind of hinky because the property is theoretically read-only, but it can't be done at all now that the property is sealed.
>
> Admittedly, FieldEntry's implementation is pretty ugly. If there's a better way to implement this widget with all the modern improvements to GTK, I'd love to hear suggestions.

>From what I understand, setting the scroll offset back is just a
workaround for lack of sufficient hooks into the entry cursor logic to
implement this ? So, maybe we should look at what you need there. In
any case, directly poking at the entrys PangoLayout sounds nasty.

Would be nice to have such a validating entry subclass in GTK+ itself
too; if you are willing to consider a move from C++ to  C