[bt-devel] The design of the BackEnd

[Torsten Uhlmann]

----- Original Message ----- 
From: Joachim Ansorg <Jockel123@gmx.de>
To: <bt-devel@crosswire.org>
Sent: Sunday, January 16, 2000 11:12 PM
Subject: Re: [bt-devel] The design of the BackEnd


> Hi!
> 
> 
> >    > Mmh, how could a directory be prepared for the presenter?
> >
> >It could for instance be HTML with a link for each file. But as discuss
> >this you may be right. To be conform with our approach we would not need
> >a DirectoryInfo but a FileInfo, e.g. a module for each file that should
> >be presented. The FileInfo will then take care of how to present the
> >module. Yes I think this is better. But it does not change the overall
> >approach, just a detail.
> 
> 
> 
> >    > Mmh, this is IMO against using the module presenters or how would
> >    > you integrate the different views in the module presenters?
> >
> >There needs to be one presenter class for one type of data to be
> >presented. One for HTML, one for maps, I can't think of more. We
> >probably will present maps with an external prog. for now, so we now
> >only need the HTML presenter class.
> 
> Is HTML a text converted to HTML or an external HTML text?
> If it's a converted one we should use the different presenters (bible presenter,
> commentary presenter and lexikon presenter).

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.

> 
> 
> >    > Ok!  I'll post it the next time in this list.  One cool thing: The
> >    > KDE guys made a new Menubar. Now it's possible to have the
> >    > MDI-icons in the menubar like in MS-Office or in every win-app.  I
> >    > think we use QextMDI.
> >
> >I thought we agreed on QWorkspace. What is the advantage of QextMDI in
> >your eyes?
> 
> Mmh, I thiught we agreed on QextMDI. But w couls also use QWorkspace since it
> doesn't slow down or bloat BT 0.3.
> Now QWorkspace is our MDI widget, ok ? 

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.

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.
> 
> 
> -- Joachim
> BibleTime - the bible study program for KDE
> http://www.bibletime.de/
> info@bibletime.de