Re: set_selection_bounds() and select_text()

[Brian Cameron <Brian Cameron sun com>]

Bill:

> > 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 :-)

Fair enough.
 
> > 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.

Good.  I agree with you.  I just wanted to raise the issue before writing
the code.
 
> 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).

Yes, I think there is no point in returning the index as an argument
from the add or delete function calls since they aren't really stable.

Brian