[brailleblaster] Re: Thoughts and questions on views

  • From: Keith Creasy <kcreasy@xxxxxxx>
  • To: "brailleblaster@xxxxxxxxxxxxx" <brailleblaster@xxxxxxxxxxxxx>
  • Date: Mon, 14 Jan 2013 19:11:50 +0000

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









Other related posts: