[bt-devel] The design of the BackEnd

[Torsten Uhlmann]

----- Original Message ----- 
From: Thomas Philpot <tjphilpot@ou.edu>
To: <bt-devel@crosswire.org>
Sent: Monday, January 17, 2000 11:07 PM
Subject: Re: [bt-devel] The design of the BackEnd


> 
> >An internal text stream. I don't want the GUI to see where the data comes from 
> >nor to know how to retrieve it. I also thought it might good the differ between
> >normal text, bible, comment and dict but couldn' think of a real need for this.
> >But maybe it will come later. Anyway I will give you information about what type of
> >module text you get. You can now display everything in one presenter and make later
> >sub classes that you can specialy use.
> 
> So the back end classes will handle the conversion from the files on Disk to
> HTML and hand that information to the GUI?  In that case, there is right now
> only a need for one presenter that handles HTML since the back end will take
> care of formatting Bible Text, Commentaries, etc. correctly.  Of course, if we
> want to do something specific say in a BibleTextPresenter, we'd have to
> sub-class Presenter. 
> 
Right, for now I see not the need to sub class the bible/dict/comment presenters but it could
well happen in the future if we add more functionality and differentiate between those types.

> >Well I think so :) I have though not yet seen the programming API but I think
> >QWorkspace is enough for our need. But if you have good reasons to use QextMDI
> >please tell me, I'm open! In the end you program the GUI.
> 
> QWorkspace is in Qt 2.x right? I haven't looked at the API yet.
> 
Yes. There is an example with QWorkspace which looks quiet good. Also Opera (www.opera.com)
is made with QT 2.x and QWorkspace (at least it looks exactly so).

> >Speaking of class structure. I would like you to create a Container class that handles requests
> >to and from the backend (for instance) and gives information to it's registered widgets (presenters,
> >list view, etc.) and not to register each window. That way we can keep the data flow between
> >backend and frontend clean and easier to change.
> 
> I definitely think we need an interface layer to separate the GUI from the
> back end.   So this is basically what we have:
> 
> GUI <-> ContainerClass <-> CBackEnd <-> CModuleInfo <-> Modules on Disk
> 
> Is this close?  The GUI widgets that need info from the BackEnd register with
> the ContainerClass (name subject to change ;) and it gets the info from
> CBackEnd about which modules are there, etc.  I'm sure there's more the the
> back end than this...  

That is very close! Except I want to enable the Container class to speak directly to the
CModuleInfo, otherwise I would double the API to also present it in CBackEnd.
But CModuleInfo will implement not signals, that will be done thru CBackEnd.
So if the GUI needs to know info about the copyright of the module, version number, 
place on disc or whatever information is interesting it would directly ask the module.
This is imposible if for instance in the toolbar you enter a key. To handle this properly 
(in my eyes) the toolbar will ask the CFrontEndContainer to please give text for that key.
The frontend container knows the active module. Both information together is given to a slot in CBackEnd.
CBackEnd will call the right module, get the information back and either send it via SIGNAL or return it as
return value. I can imagine to implement both ways to use either where possible.

> 
> Oh and one other thing, which classes are handling the HTML conversions?
For SWORD they are directly registered with the SWModule class. These are basically filters
written from us and now part of the SWORD distribution. There is however a part which handles
fontifying, colorization which is still part of BT and will be part of CSWORDModuleInfo or some other class
that is used by it.
> 
> Tom