[webkit-gtk] Moving the caret with "enable-caret-browsing" set
Mario Sanchez Prada
mario at webkit.org
Tue Nov 6 07:43:49 PST 2012
On Sat, 2012-11-03 at 20:06 -0400, Nicholas Bishop wrote:
> As suggested, I am trying out the Atk API to move the caret. I didn't
> see any public webkit_web_view_get_accessible() function, but
> gtk_widget_get_accessible() seems to do the trick.
Yes, sorry for the confusion. gtk_widget_get_accessible() is what you
have to use, not the other one :-)
> I'm trying to figure out how to use the API for this by printing out
> the AtkObject tree of a webkit view. What I cannot see is any property
> that indicates where in the tree the caret currently is. Calling
> atk_text_get_caret_offset() on an AtkText object in the tree gives
> mysterious values -- objects that are nowhere near the caret have
> greater-than-zero values. There doesn't seem to be a signal value like
> -1 to indicate the caret isn't there.
In theory when you call atk_text_get_caret_offset() over an
accessibility object implementing AtkText you'll get the offset relative
to the start of the text for that object.
For instance, if you have this HTML rendered:
Some text with <a href="foo">a link</a> in the middle
You will have the following accessibility subtree:
AtkObject1 // For <p>, implementing AtkText
`--AtkObject2 // For <a>, implementing AtkText
The result of calling atk_text, get_text (object, 0, -1) over those two
objects would be:
- For AtkObject1: "Some text with a link in the middle"
- For AtkObject2: "a link"
Now, if the caret is right before the 'l' of 'link', calling
atk_text_get_caret_offset () over those two objects should give you
something like this:
- For AtkObject1: 17
- For AtkObject2: 2
Not sure if that answers your question, though.
> I also tried getting the AtkStateSet for text objects, but it only
> ever contains ATK_STATE_ENABLED, ATK_STATE_SENSITIVE,
> ATK_STATE_SHOWING, and ATK_STATE_VISIBLE. I was hoping the one with
> the caret would have ATK_STATE_FOCUSED, but seems not.
IIRC, objects representing non-editable text can't be "focused". That
would work for text entries and text areas.
> Finally, I tried atk_text_get_n_selections() to see if the caret
> counted as zero-length selection, but seems not.
Currently, atk_text_get_n_selections() is only implemented for range
selections. I think that's why it does not work.
> Any further hints?
It could be you spotted a bug. Would you mind sharing the exact HTML and
steps you're using to check this?
That way I could try to check it myself and hopefully help to advance on
this in a better way.
More information about the webkit-gtk