Re: AtkText and AtkEditableText

[Peter Korn <peter korn sun com>]

Hi Marc,

> Some thoughts on AtkText and AtkEditableText:
> 
> Since it doesn't seem reasonable that an object would implement AtkText and
> not AtkEditableText, it seems that AtkEditableText::SelectText and
> AtkText::SetSelectionBounds are redundant.  Selecting text seems to be
> something that one may wish to do, regardless oof whether the text is
> editable or not.  The two cases which come to mind offhand are selecting
> text from a terminal window to copy to the clipboard, and selecting text
> from a web page.  So, it seems as though text selection rightfully should
> live in AtkText.  Thoughts?
> 
> Along these same lines, I think the CopyText or CopySelection methods
> should also live in AtkText, as they don't affect the widget, and therefore
> don't seem to be a part of editing it.  The paste and delete functions seem
> appropriate for AtkEditableText.  Again, any comments?

Hmmm...  We are planning to implement AtkText on static text, labels and the
like, right?  Those generally can't be copied from in any case, nor selected.  I
think that use cases should drive this decision.  There is a lot of text in a UI
that cannot be copied or selected.  It seems like the right way to factor this
(given the preponderace of it) is to have AtkText not contain those methods. 
Then, any place where text can be selected (but not necessarily edited - such as
terminal windows), we implement AtkEditableText.

You can factor it other ways; there isn't a manifestly "right" answer here I
think.  But that's my personal feeling...

Peter Korn
Sun Accessibilty team