[brailleblaster] Re: Thoughts and questions on views
- From: Keith Creasy <kcreasy@xxxxxxx>
- To: "brailleblaster@xxxxxxxxxxxxx" <brailleblaster@xxxxxxxxxxxxx>
- Date: Mon, 14 Jan 2013 16:20:27 +0000
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
Other related posts:
