[brailleblaster] Re: Thoughts and questions on views
- From: Keith Creasy <kcreasy@xxxxxxx>
- To: "brailleblaster@xxxxxxxxxxxxx" <brailleblaster@xxxxxxxxxxxxx>
- Date: Tue, 15 Jan 2013 13:19:39 +0000
I'm not asking about interleaving, what are your plans to communicate between
the views and the document in Semantics? How do they update each other? We
haven't solved that, or at least I haven't seen the solution. We really can't
move forward until it's solved. If Semantics hands off nice, pretty text and
braille that's fine but what happens when someone edits something?
Text Styles really aren't a problem. The TextView can show the text styles but
the lines match the braille lines. The text in XML doesn't have hard line
breaks except for block text boundries. Block text, as far as I know, in braill
and text matches; i.e. paragraphs, headings, list items, etc.
-----Original Message-----
From: brailleblaster-bounce@xxxxxxxxxxxxx
[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J. Boyer
Sent: Tuesday, January 15, 2013 7:50 AM
To: brailleblaster@xxxxxxxxxxxxx
Subject: [brailleblaster] Re: Thoughts and questions on views
These are just my thoughts on interleaving. It just seems like a possibility.
John
On Tue, Jan 15, 2013 at 12:29:00PM +0000, Keith Creasy wrote:
> Ah, and just what do you have in mind for that? I proposed a model for doing
> it but since you've nixed my architecture I'm interested in what you have in
> mind. If we don't have a plan for this we need to stop and come up with one.
>
>
> -----Original Message-----
> From: brailleblaster-bounce@xxxxxxxxxxxxx
> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J.
> Boyer
> Sent: Monday, January 14, 2013 7:08 PM
> To: brailleblaster@xxxxxxxxxxxxx
> Subject: [brailleblaster] Re: Thoughts and questions on views
>
> Yes, the biggest problem is updating the document from the views.
>
> Interleaving print and Braille displays might not be too difficult using
> FormLayout. The two StyledText controls would be assigned the same screen
> area, except that the print one would be a little higher, so that its lines
> would appear between those of the Braille one. Line spacing would have to be
> appropriate. One of the controls would have to have a transparent background.
> I don'tknow if SWT can do this.
>
> John B
>
> On Mon, Jan 14, 2013 at 07:20:55PM +0000, Keith Creasy wrote:
> > Well, I expect we'll just get everything working with the synchronization
> > in place and go from there.
> >
> > The biggest hurdle in my opinion at this point is the mechanism for updates
> > from the view to the document, in the XML context, and vice-versa. If we
> > can get that worked out everything else seems pretty easy.
> >
> >
> >
> >
> > Keith Creasy
> > Software Developer
> > American Printing House for the Blind KCreasy@xxxxxxx
> > Phone: 502.895.2405
> > Skype: keith537
> >
> >
> > -----Original Message-----
> > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John
> > Gardner
> > Sent: Monday, January 14, 2013 2:16 PM
> > To: brailleblaster@xxxxxxxxxxxxx
> > Subject: [brailleblaster] Re: Thoughts and questions on views
> >
> > Sounds pretty user-friendly! However, a number of possibilities will work,
> > so I suggest you propose the spec for this based on what can be made to
> > work at reasonable effort. I hesitate to write down a spec and then
> > discover that something that works just as well would be fifty times easier
> > to implement.
> >
> > John G
> >
> >
> > -----Original Message-----
> > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Keith
> > Creasy
> > Sent: Monday, January 14, 2013 11:12
> > To: brailleblaster@xxxxxxxxxxxxx
> > Subject: [brailleblaster] Re: Thoughts and questions on views
> >
> > Just some ideas...
> >
> > Maybe we can make it so you can turn the line-by-line synchronization on
> > and off.
> >
> > Also, since you hopefully can close or hide any of the views, if you aren't
> > showing the braille view then there's really not much point in trying to
> > synchronize. So, if you're just working on composing text in a large
> > document you could just hide the braille view, maximize the text view and
> > write in something that is more like a word processor. Then, when you want
> > to see the braille, you could show the braille view and the synchronization
> > would become active.
> >
> >
> > Keith Creasy
> > Software Developer
> > American Printing House for the Blind KCreasy@xxxxxxx
> > Phone: 502.895.2405
> > Skype: keith537
> >
> >
> > -----Original Message-----
> > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John
> > Gardner
> > Sent: Monday, January 14, 2013 2:03 PM
> > To: brailleblaster@xxxxxxxxxxxxx
> > Subject: [brailleblaster] Re: Thoughts and questions on views
> >
> > Hi Keith, it would be a bit annoying to me, because the formatting would
> > make the lines really short. But this is a minor annoyance, not anything
> > that should change the direction you are going.
> >
> > John G
> >
> >
> > -----Original Message-----
> > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Keith
> > Creasy
> > Sent: Monday, January 14, 2013 10:56
> > To: brailleblaster@xxxxxxxxxxxxx
> > Subject: [brailleblaster] Re: Thoughts and questions on views
> >
> > John.
> >
> > Explain why it might be a bit annoying? Sounds like something I need to
> > hear.
> >
> >
> >
> > Keith Creasy
> > Software Developer
> > American Printing House for the Blind KCreasy@xxxxxxx
> > Phone: 502.895.2405
> > Skype: keith537
> >
> >
> > -----Original Message-----
> > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John
> > Gardner
> > Sent: Monday, January 14, 2013 1:18 PM
> > To: brailleblaster@xxxxxxxxxxxxx
> > Subject: [brailleblaster] Re: Thoughts and questions on views
> >
> > Interesting, this is getting closer and closer to where conversations on
> > BrailleBlaster started. If BrailleBlaster is being used to translate and
> > make small corrections to an existing document, this functionality should
> > be just fine. If one is authoring a long document in BrailleBlaster, it
> > could be a bit annoying.
> >
> > We didn't expect BrailleBlaster to be a full-featured authoring
> > application, so personally I think the functionality you describe is just
> > fine.
> >
> > John G
> >
> >
> > -----Original Message-----
> > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Keith
> > Creasy
> > Sent: Monday, January 14, 2013 10:09
> > To: brailleblaster@xxxxxxxxxxxxx
> > Subject: [brailleblaster] Re: Thoughts and questions on views
> >
> > See my comments, KC-, below.
> >
> > -----Original Message-----
> > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J.
> > Boyer
> > Sent: Monday, January 14, 2013 12:36 PM
> > To: brailleblaster@xxxxxxxxxxxxx
> > Subject: [brailleblaster] Re: Thoughts and questions on views
> >
> > How will the browser view get the information to show things in their
> > original context?
> >
> > KC- That's a good question and one we need to solve. Basically it contains
> > the original document (DOM) with a CSS and XSLT applied. There is an update
> > method to move the browser selection to the context element.
> >
> >
> > I've always thought that print editing would be done in a wordprocessor
> > view. The layout would not mimic that of the Braille view. I just want to
> > be clear on where we will be doing editing.
> >
> >
> > KC- The short answer is, at least in this first cycle, editing is done in
> > the text view. Right now there is no "word processor" view. I think in the
> > long term we are going to want a browser-style view that is editable. We
> > can talk about whether or not we want some kind of text view that does not
> > place line breaks at the same places as those in the braille view. If we
> > design it right then adding views is easy. I suggest we start with the text
> > and braille views in line-by-line synchronization. In XML documents line
> > length is based on the view window anyhow so there are no hard line breaks
> > in the print to conflict with the ones in the braille view.
> > .
> >
> >
> > John B
> >
> > On Mon, Jan 14, 2013 at 05:27:01PM +0000, Keith Creasy wrote:
> > > John.
> > >
> > > Yes, it is a Browser view. Sorry for the confusion. It's just to
> > > allow
> > users to see everything in its oribinal context.
> > >
> > > View Plus has just mentioned a time or two that they'd like to
> > > overlap
> > text and braille. Beyond that there isn't much more to say. I'd just like
> > to keep things open to do that if they want to at some point. For now the
> > text and braille views accomplish the same thing just in side-by-side views
> > rather than them being overlapped.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J.
> > > Boyer
> > > Sent: Monday, January 14, 2013 12:23 PM
> > > To: brailleblaster@xxxxxxxxxxxxx
> > > Subject: [brailleblaster] Re: Thoughts and questions on views
> > >
> > > Hi Keith,
> > >
> > > There are a lot of things in your original reply that I will be
> > > thinking
> > about. I agree that it might be best to srart over with Documentmanager (or
> > DocumentClient).
> > >
> > > What is ViewPlus doing about editing print and Braille? If this is
> > proprietary information we might discuss it in the steering committee?
> > >
> > > I can understand a tree view, but why do we need an html view?
> > > Isn't it
> > more properly a browser view?
> > >
> > > John B
> > >
> > > On Mon, Jan 14, 2013 at 05:04:29PM +0000, Keith Creasy wrote:
> > > > Hmmm, that would be an interesting approach, make one of the
> > > > views
> > transparent so the content could overlap in a clever way. It might work.
> > > >
> > > >
> > > >
> > > >
> > > > Keith Creasy
> > > > Software Developer
> > > > American Printing House for the Blind KCreasy@xxxxxxx
> > > > Phone: 502.895.2405
> > > > Skype: keith537
> > > >
> > > > -----Original Message-----
> > > > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > > > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John
> > > > Gardner
> > > > Sent: Monday, January 14, 2013 12:01 PM
> > > > To: brailleblaster@xxxxxxxxxxxxx
> > > > Subject: [brailleblaster] Re: Thoughts and questions on views
> > > >
> > > > Hi Keith, John B mentioned a text+Braille view. This is
> > > > something that
> > was discussed in the early planning stages of BrailleBlaster. But we
> > dropped it in favor of separate views. It would be nifty if the text view
> > and the Braille view could be superposed to show a "text+Braille" view - ie
> > the translation right above the Braille, something our users like. For
> > ViewPlus printer/embossers it would also be more or less what the final
> > output is.
> > > > As long as you are working on views, is it difficult to design
> > > > them so
> > that this is possible? Ie to make the top view semi-transparaent and easy
> > to drag on top of the other?
> > > >
> > > > John G
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > > > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Keith
> > > > Creasy
> > > > Sent: Monday, January 14, 2013 08:20
> > > > To: brailleblaster@xxxxxxxxxxxxx
> > > > Subject: [brailleblaster] Re: Thoughts and questions on views
> > > >
> > > > Hi John.
> > > >
> > > > Interesting. I'm working on views today. At least I'm reading
> > > > through
> > the code and coming up with some strategies.
> > > >
> > > > I do like the idea of moving views to a package. Initially we
> > > > have
> > potentially four views:
> > > >
> > > > TextView
> > > > BrailleView
> > > > TreeView
> > > > HtmlView
> > > >
> > > > I still want to attach the views to the document (DocumentBase)
> > > > in some
> > way with a common interface so that new views can be added easily. That way
> > we can document exactly what someone would need to create a text/braille
> > view.
> > > > We don't plan to do that but View Plus may.
> > > >
> > > > Optionally we can attach DocumentManager to DocumentBase and let
> > DocumentManager manage connecting views. Document Manager also handles a
> > client view that represents the window area for a single document.
> > WpManager is going to create each of DocumentManager and hand off the
> > client area that DocumentManager and it's view widgets occupy. If we want
> > to enable an MDI then WmManager just changes wich instance of
> > DocumentManager is displayed in the client area.
> > > >
> > > > Also, because it's such a mess, I'd suggest that someone rename
> > > > the
> > current DcocumentManager class DocumentManagerOld or something and start
> > over.
> > > > There's a lot in there that can be copied and used in the new
> > DocumentManager but in trying to comb through it and decide what should
> > stay and what should go I think starting over with the original as a
> > reference is simpler. In fact, what about renaming it DocumentClient? It is
> > mostly a view of sorts.
> > > >
> > > > Here are my notes so far, they are not complete:
> > > >
> > > > WpManager class:
> > > >
> > > > This is the main entry point for BB. It doesn't do much right
> > > > now but
> > I'm proposing that it do a bit more.
> > > >
> > > > 1. Sets up main application window, menu, toolbar, andclient area.
> > > > 2. Handles File/New and File/Recent command, most Window commands.
> > > > 3. Creates a DocumentManager instance when a new document is created.
> > > >
> > > > DocumentManager class (maybe renamed to DocumentClient?):
> > > >
> > > > 1. fills the client area of WpManager. The client frame contains
> > > > any
> > views to the document.
> > > > 2. Creates an instance of DocumentBase and any views that need
> > > > to be
> > attached.
> > > > 3. Handles most file commands; i.e. Open, Save, Save As,Export,
> > > > Import,
> > etc.
> > > >
> > > >
> > > > Views:
> > > >
> > > > All views are derived from AbstractView. This is so that all can
> > > > have
> > certain methods that are required for interfacing with the document and so
> > that the document can update them when necessary. Does it make sense for
> > each view to create it's own font? We definitely want to avoid code in
> > DocumentManager that is specific to a particular view; i.e. DocumentManager
> > knows how to create a BrailleView and put it somewhere but nothing more.
> > > >
> > > > Keith Creasy
> > > > Software Developer
> > > > American Printing House for the Blind KCreasy@xxxxxxx
> > > > Phone: 502.895.2405
> > > > Skype: keith537
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > > > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J.
> > > > Boyer
> > > > Sent: Monday, January 14, 2013 10:42 AM
> > > > To: brailleblaster@xxxxxxxxxxxxx
> > > > Subject: [brailleblaster] Thoughts and questions on views
> > > >
> > > > First, whatever APH and ViewaPlus want to do about view is fine with me.
> > > >
> > > > It seems that we are considering four views, a tree view, a
> > > > browser or
> > htmml view a combined Braille-and-print view and a word processor view.
> > > > Do we want the last view? Editing can be done in the
> > > > braille-and-print
> > view.
> > > > If we don't want a wordprocessor view we con't have to worry
> > > > about
> > styles, because the layout of the print in the print-Braille view will
> > mimic that of the Braille. Perhaps we should change the architecture to
> > have an org.brailleblaster.views package and within this package
> > subpackages for each view, brailleprintview, treeview, browserview and
> > wordprocessorview.
> > > >
> > > > 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, Executive Director
> > GodTouches Digital Ministry, Inc.
> > http://www.godtouches.org
> > Madison, Wisconsin, USA
> > Peace, Love, Service
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> --
> 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:
