Re: A few outstanding issues with ATK API

[Peter Korn <peter korn sun com>]

Hi Bill,

> > ...
> >I think there is are fundemental problems with trying to abstract
> >this away from the application user interface:
> >
> > - Not all applications using a widget that supports styled text
> >   may support setting the styles. (Imagine a programming editor
> >   or plain text editor)
> >
> > - Not all applications supporting styles will support all possible
> >   styles.
> >
> > - Updating the styles may involve updating internal application
> >   data structures as well as updating the visual text. For instance,
> >   a HTML editor will need to update its editor tree.
> 
> It's not easy to abstract this out of the UI, Owen is right about that.
> But I think an attempt to do some will add a lot of value for some
> users, even if we cannot implement the interface fully for all "text
> entry" widgets.
> 
> This might be OK if we keep the convention of returning booleans from
> our set() methods (we haven't been entirely consistent to date, but we
> are fixing this at the moment).  That way we can expose useful features
> even if we expect that they will not always be implementable.
> 
> Admittedly it's a drag for a user to find an advertised interface that
> refuses admittance, but it's arguably better than bricking up the
> windows where they do occur :-)
> 
> We could perhaps break AtkText into a more detailed hierarchy, with
> AtkText, AtkStyledText, AtkEditableText, AtkStylableText, etc... but I'd
> do this only if consensus says that having "set" return FALSE sometimes
> is onerous.  Even in that scenario one can't count on all styles being
> available, as Owen points out.  I would prefer not to add a
> get_available_styles() method, etc., the interfaces would really start
> to bloat.

I think returning booleans on the set methods is the best choice.  Subclasses
will enable/disable things that worked/didn't work in the parent, as well as
specific implementations (our text fields can never have underlined text 'cause
we think it's ugly).  It also is more extensible, as additional styles are
supported (you don't need to go back and update the get_available_styles()
methods).  Finally, I don't see a clear argument for a finely grained
heirarchy.  I think what we have is probably sufficient, with the possible
factoring into editable and non-editable text as an option.

Peter