Jword design plan

The high-level design for jword, is to have independant GUI, middle layer, and file I/O modules. We plan to allow multiple GUI's: AWT, SWING, and whatever else someone is willing to write. Similarly, we plan to support as many different file formats as people are willing to write code for! That will be managed through the DocInterface interface, mentioned further down.

So, on a section by section basis:

#1: GUI front-end

Should provide user hooks for anything a beginning user might want to do. Change fonts, search/replace, save/load, help, ...?

I say "beginning user", because we won't be quite up to the expert stuff in the first release of jword! We're aiming more for level of .. erm... (certain copywrited low-level product included in an OS from richmond, that is the best word-processing you get in the basic OS itself, if you want to Write stuff)

Also handles keyboard input from the user, AKA actual typing of text. Basically, any direct contact by the user should be caught at this level, and then translated as appropriate for lower levels.

#2; Middle layer text handling

Needs to provide any and all text manipulation routines required by the front end. These include simple "add/delete char" type things, as well as potentially more complex items. For example, I think it makes sense for the middle section to keep track of things like page location, etc. But that means the middle section is then responsible for things like word wrap, page length, formatting, etc... It will then be the largest conceptual part, by a wide margin.

Note that the middle section is also responsible for implementing a version of DocInterface. This is so that it can receive a file loaded from disk. (or possibly from other sources, eventually? who knows...)

#3: Back end File Translation routines

For any one particular file format, there are two fundamental parts:

[Although sometimes we may chose to only implement one half of the above]

Examples of the file interface are currently given on the main page, http://www.bolthole.com/jword/

Design problems

There are a few design problems still to be worked out. Principle amoung them is that there is still no efficient, clean way to handle columns, and/or image embedding. Highlighting is also beginning to nag at me.

PLEASE EMAIL ME, if you have solutions to those! If possible, please email me specifics, not "go read this book". I have nothing against reading, but i can't seem to find the time to go out and hunt for them. If you want to donate the book to me, and MAIL it, that's another story :-)

We are moving ahead on the new design. It looks something like this: 


Make the middle layer keeps track of "cursor" position, and all other
grunginess. Make the front end be really really dumb, as far as
responsability. That way, it can concentrate on fru-fru features.
Data flow would go as follows:

INPUT: User input (insert char)

    GUI layer receives keystroke. It's a non-special char, so it says to the
    middle layer: "Hey, insert this char at 'current cursor position'

       Middle layer inserts char, wordwraps, etc. Then calls GUI layer for a
       screen update. In particular, it says
       "Hey, here's a piece of text. I need it drawn on page 1, exactly
        [here]"
       (it may also need to send "erase this area" commands)

          GUI layer gets called with a "draw stuff" request, and does so.
	  Hey, look, we're re-entrant with the GUI layer.
The problems I see with this are:

1. It requires loops in object control, whereas the current version has everything pretty much driven by the GUI layer. Yes, in true OOP design, this shouldn't matter. However, in the real world, having everything driven by one master, makes debugging much, MUCH cleaner. Not to mention the simple axiom "fewer mutexes == better"

2. Redraws generated by non-user-input become a little messier. For example, "highlight 'this' region". And/or "This part of the window was behind a different app. Now redraw it"

3. This makes the front layer potentially simpler, at the expense of making the middle layer potentially a lot more complicated. Generally, the simpler you can keep each module the better. (with a corollary being: If a single module gets high complicated, see if splitting it into two simpler ones makes more sense)

The benefits I see to this method are:

1. I finally have explicit Interfaces for GUI and middle end to follow.

2. This might make it easier to do column handling, since that stuff would now be only a headache in ONE (huge)module

3. preliminary code indicates this method should be as fast as the previous versions, if not faster.

Here's some interfaces to chew on

For access to current source, email phil.

jword top
Author: phil@bolthole.com