Re: set_selection_bounds() and select_text()

[Bill Haneman <bill haneman sun com>]

Brian Cameron wrote:
> 
> Mark:
> 
> > I like this.  I have just a couple comments.
> >
> > >I propose this interface.  What do you think?  Does this meet our needs?
> > >Do we also need a function to return the maximum number of selections?
> > >
> > >No, imho I think we can get by returning a boolean if the selection can't
> > >be added.
> 
> Just to clarify, I am anticipating that the "selection num" works as
> follows.  selection num "1" corrisponds to the selection with the lowest
> start offset, num "2" has the next higher offset, etc., so that the last
> selection num has the highest start offset.

We have been using "zero-offset" everywhere, I think we should
continue that.  This is a C API after all :-)

> This means that the numbering can change if the user deletes a selection
> that is in front of other selections, or uses the "atk_text_set_selection()"
> function to move a selected area in front of or behind another selected area.

That seems OK, I do not think we should rely on the numbering. 
Perhaps this mitigates against the use of the "int" out parameter in
the add/remove API.  I don't see that it's all that necessary anyhow,
and if it's not reliable than I don't think we should include it.

My thought is use a boolean return for "add_selection". 
"get_selection" is intended for use immediately after a
"get_n_selections" call (and should return NULL if an invalid index is
used).

I *really* don't like the GList API, though you are right, it solves
the numbering issues.  However there is still no guarantee that it
will be current once received, if a selection changes between the
receipt of the selections list and the use of the offsets (ultimately
one wants to do a get_text() using the offset pairs, right?).  So in
any case the client must be listening for selection events if it wants
to stay current (the simple approach is to re-read the selections if
an event is received while processing).

-Bill

> Is this okay?  If it is a problem that the numbering can change, then
> I think we'll have to try a different design.
> 
> One idea would be to get rid of the "selection_num" and just refer to each
> selection by its start/end offsets.  Then, instead of a function called
> atk_text_get_n_selections, there would be a function that would return the
> start/end offsets for each selection.  This would be a little ugly.  Perhaps
> it would be a GList of AtkSelection structures, like this:
> 
>   AtkSelection
>   {
>      int start_offset
>      int end_offset
>   }
> 
> But this would solve the problem of the numbers changing on the fly.
> 
> What do you think?  Do we need to add this complexity, or is the fact that
> the "selection_num" can change not a problem.  Or do you have any ideas
> of how we could provide more perminant id's to the selected areas.
> 
> Brian

-- 
--------------
Bill Haneman
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland