[brailleblaster] Re: Implementing StyledTextContent
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Mon, 17 Oct 2011 19:03:44 -0500
Chris,
Adding to my previous message.
It appears that the only method in DefaultContent that user
StyledTextEvent and that I need be concerned about is replaceTextRange.
Hopefully I will not have to override it.
I'm considering adapting your code suggestion for the classes
BrailleContent and DaisyContent, which will be used by the two views,
respectively. Their requirelments are quite different. There will also
be a ContentCommons class for shared code. This will be like the
transcommon.ci module in liblouis, which is included by both
lou_translateString.c and lou_backTranslateString.c
I must say that i'm not very satisfied with my understanding of envents
and listeners in general and with how they are used in StyledText in
particular.
John
On Mon, Oct 17, 2011 at 12:02:46PM -0500, John J. Boyer wrote:
> Chris,
>
> This is a good start. However, in some of the methods that override the
> baseContent I will probably have to refer to StyledTextEvent and the
> problem will reappear. I don't really care what the compiler is
> complaining about as long as we have somehting that works.
>
> John
>
> On Mon, Oct 17, 2011 at 09:38:06AM -0700, Chris von See wrote:
> > If the default context can't be subclassed then can you do something like
> > this:
> >
> > public class BrailleBlasterContentModel implements StyledTextContent
> > {
> > private StyledTextContent baseContent;
> > private BrailleTranslator brailleTranslator;
> >
> > public BrailleBlasterContentModel(final StyledText styledText) {
> > baseContent = styledText.getContent();
> > styledText.setContent(this);
> >
> > brailleTranslator = new LiblouisThingThatTranslatesToBraille();
> > }
> >
> > public void addTextChangeListener(final TextChangeListener listener) {
> > baseContent.addTextChangeListener(listener);
> > }
> >
> > // continue to provide implementations from the StyledTextContent
> > interface and delegate them to the stored
> > // content model. For methods that need new behavior, do whatever you
> > need to do and call the stored
> > // content model only if needed.
> >
> > public String getTextRange(final int start, final int length) {
> > // here let's pretend that you need additional functionality,
> > so you take the content from the base model
> > // and do stuff to it
> > return
> > brailleTranslator.toBraille(baseContent.getTextRange(start, length));
> > }
> > }
> >
> >
> > I'm just trying to save you the pain of copying the Eclipse code and having
> > to maintain it if/when it evolves. I can't tell you what your compiler
> > error is unless I look at your code.
> >
> > Cheers
> > Chris
> >
> >
> > On Oct 17, 2011, at 8:47 AM, John J. Boyer wrote:
> >
> > > DefaultContent.java says it is not intended to be subclassed. The
> > > content model will have to conect what StyledText displays and the user
> > > changes with the underlying xml. Even if DefaultContent could be
> > > subclassed StyledTextEvent is still needed. It performs important
> > > functions in DefaultContent. The puzle is how the compiler can claim
> > > that a class with a different name is a duplicate of one in swt.custom
> > >
> > > John
> > >
> > > On Mon, Oct 17, 2011 at 08:12:01AM -0700, Chris von See wrote:
> > >> Can you just extend the default StyledTextContent implementation and
> > >> override the methods that you need to in order to implement the
> > >> functionality you want? What do you want to do that the default
> > >> implementation doesn't do?
> > >>
> > >> Cheers
> > >> Chris
> > >>
> > >>
> > >> On Oct 17, 2011, at 2:36 AM, John J. Boyer wrote:
> > >>
> > >>> The Braille and Daisy views have quite different requirements, so it is
> > >>> best to implement a StyledTextContent model for each one. I thought to
> > >>> use the DefaultContent class as a starting point. The Eclipse license
> > >>> permits this. Si I copied it to org.brailleblaster.wordprocessor and
> > >>> started modifying it. Various import statements had to be added. When I
> > >>> tried to import StyledTextEvent I was told that it was not public in
> > >>> the
> > >>> custom SWT package. So I copied that also. Then the compiler gave the
> > >>> message that it was a duplicate class, presumably because it had the
> > >>> same name as a class in the classpath. So I changed the name slightly.
> > >>> The compiler still gives the same message, claiming that a class with
> > >>> the changed name exists in swt.custom, which it does not. It appears to
> > >>> be important for the content model to use the StyledTextEvent. What is
> > >>> the work-around for this problem?
> > >>>
> > >>> Thanks,
> > >>> John
> > >>>
> > >>> --
> > >>> John J. Boyer; President, Chief Software Developer
> > >>> Abilitiessoft, Inc.
> > >>> http://www.abilitiessoft.com
> > >>> Madison, Wisconsin USA
> > >>> Developing software for people with disabilities
> > >>>
> > >>>
> > >>
> > >
> > > --
> > > John J. Boyer; President, Chief Software Developer
> > > Abilitiessoft, Inc.
> > > http://www.abilitiessoft.com
> > > Madison, Wisconsin USA
> > > Developing software for people with disabilities
> > >
> > >
> >
>
> --
> John J. Boyer; President, Chief Software Developer
> Abilitiessoft, Inc.
> http://www.abilitiessoft.com
> Madison, Wisconsin USA
> Developing software for people with disabilities
>
--
John J. Boyer; President, Chief Software Developer
Abilitiessoft, Inc.
http://www.abilitiessoft.com
Madison, Wisconsin USA
Developing software for people with disabilities
Other related posts:
