[bt-devel] Backend Proposal

[Gary Holmlund]

On 06/19/2011 03:46 PM, Greg Hellings wrote:
> On Sun, Jun 19, 2011 at 4:54 PM, Gary Holmlund<gary.holmlund at gmail.com>  wrote:
>> I would be willing to do the structural work of moving files into new
>> directories and changing the backend and rendering into libraries. We would
>> want to get agreement on the details before any work starts. The work should
>> be done so that there is never a commit that does not compile and run. It
>> can be broken down into a series of small steps that accomplish this.
> It's probably good to identify one component at a time to pull out of
> the code base and do it that way.  And it probably should be the task
> of whoever is going to take the reins for that component to move the
> files and modify them as necessary (in connection with people working
> on any components that rely on it).  Since each component probably
> requires more than just copying the files to the new folder structure,
> it's probably best for each component to be done in a branch of its
> own, that way every commit on main works even if there is some
> breakage in the branch. It also allows for multiple people, such as
> the person creating the component and people working on components
> that rely on it, to collaborate on factoring out each piece. Due to
> the interconnectedness, commits on the branch may not work but we'll
> be sure the project works before merging each component back onto
> main.
>
>> I wonder if 3 components (backend, render, and BibleTime) are the right
>> breakdown. There may be other things we should separate such as the config
>> system.
> I'm not sure what our config system does that isn't part of the normal
> Qt cross-platform config system.  I would have guessed that any config
> systems would be part of the GUI component, but you probably know
> better than I.
>
> --Greg
The config system is based on Qt's QSettings and manages the 
$HOME/.bibletime/bibletimerc file. It is currently located in the 
backend. We have discussed re-writing it to make it easier to use in the 
past. I think the main point is that if a alternate ui was written, it 
might want to share the config system, so the config system would need 
to be a separate component.

It would not surprise me that there are other functions that are used by 
the ui, but could also be used by an alternate ui. I think we should 
look for these and keep them separate from the ui.

Gary