Re: set_selection_bounds() and select_text()

[Brian Cameron <Brian Cameron sun com>]

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.

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.

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

> >--proposal follows--
> >
> >gint     atk_text_get_n_selections()
> >
> >   - returns the current number of selections.
> >
> >gchar*   atk_text_get_selection(gint selection_num, gint *start_offset,
> >              gint *end_offset)
> >
> >   - returns the text of the specified selection.  Passes back the start
> >     & end offsets in the arguments.
> >
> >gboolean atk_text_add_selection(start_offset, end_offset)
> >
> >   - returns TRUE if success, FALSE if fail.  Will return FALSE if the
> >     widget already has the maximum number of selections turned on.
> >
> >I think this would be better as:
> 
> 
> gboolean atk_text_add_selection (gint *selection_num, gint *start_offset, 
> gint *end_offset);
> 
> This way you have a means to refer to the selection in fugure calls, as 
> well as know whether the selection add was successful.
> 
> 
> >gboolean atk_text_remove_selection(gint selection_num)
> >
> >   - removes the specifies selection.  Returns TRUE if success, FALSE if
> >     fail (like invalid selection_num).
> >
> >gboolean atk_text_set_selection(gint selection_num, gint start_offset,
> >             gint end_offset)
> >
> >   - moves the specified selection to the specified start & end offsets.
> >     Returns TRUE if success, FALSE if fail (like invalid selection_num).
> >
> >
> > > I agree with this-- I think we should consolidate these
> > > interfaces.  Changing the get/set selection functions to support multiple
> > > ranges seems useful.
> > >
> > > Marc
> > >
> > > At 04:09 PM 5/28/2001 +0100, Bill Haneman wrote:
> > >
> > > > >The AtkText interface contains set_selection_bounds() and
> > > >AtkEditableText
> > > > >contains select_text().
> > > > >
> > > > >Do we really need both of these?
> > > >
> > > >There is an open issue around whether we allow discontiguous selection
> > > >("multi-select") or not.
> > > >
> > > >If we do, then select_text() makes sense, set_selection_bounds() (and
> > > >similarly, get_selection_bounds) don't, unless they take an additional
> > > >gint parameter to indicate "which" selection range is being operated on.
> > > >
> > > >I think multi-select is probably useful, but tricky.  If we decide to
> > > >implement it then we need a get_n_selections() method as well, to go
> > > >with get/set_selection_bounds() [plus the new parameter to the
> > > >*_selection_bounds() methods).
> > > >
> > > > >If so, can anyone suggest a scenario in which the implementation of the
> > > >two
> > > > >intefaces might be different?
> > > > >
> > > > >Padraig
> > > > >
> > > > >
> > > > >_______________________________________________
> > > > >gnome-accessibility-list mailing list
> > > > >gnome-accessibility-list gnome org
> > > > >http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
> > > >
> > > >------
> > > >Bill Haneman x19279
> > > >Gnome Accessibility / Batik SVG Toolkit
> > > >Sun Microsystems Ireland
> > > >
> > > >
> > > >_______________________________________________
> > > >gnome-accessibility-list mailing list
> > > >gnome-accessibility-list gnome org
> > > >http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
> > >
> > >
> > > _______________________________________________
> > > gnome-accessibility-list mailing list
> > > gnome-accessibility-list gnome org
> > > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>