Source directory restructuring

Aaron Laws dartme18 at gmail.com
Tue Aug 8 13:14:59 EDT 2017


On Mon, Aug 7, 2017 at 7:56 AM, Geert Janssens <geert.gnucash at kobaltwit.be>
wrote:

> So after my houskeeping message in which I have announced the changes to
> src/
> business and src/libqof, I'd like to bring up my eventual goal for the
> source
> tree.
>
> My main motivation to do all this restructuring is to simplify. There are
> currently plenty of directories and I often have to guess where to expect a
> file. The qof vs engine story was one example. Is gnc-date something for
> qof
> or for engine ? I find myself regularly searching for a file in the wrong
> directory.
>
> So here follows a first proposal for the directory structure I'm
> targetting:
>
> * data (for things like art, checks, account hierarchy templates,...)
> * doc (for all documenation)
> * lib (for all source required to build "libgnucash", see below)
> * ui (for all the user interfaces the project currently supports)
>
> I am omitting some smaller directories here, such as util and macros. They
> will probably stay on the current top level for now.
>
> I'm envisioning "libgnucash" as the core library that encapsulates all
> gnucash
> related concepts (the accounting concepts such as transaction, split, as
> well
> as the data backends). This library is what all applications in the gnucash
> sphere should depend on to implement the "gnucash" experience. The most
> obvious is of course the current gnucash as we know it. However at some
> point
> this library should ideally also become the core of the Android app and
> *who
> knows* one day an IOS app. And closer to the current state, it should also
> be
> the library that the guile and python bindings depend on. So all
> functionality
> encapsulated in one single library, the API. In practice I think the
> following
> directories belong in this libgnucash: core-utils, gnc-module, engine, the
> backends, app-utils. (Note I would like to get rid of gnc-module still, but
> that's a whole other discussion and task).
>
> The ui directory will have a subdirectory for each user interface we
> support.
> This is not necessarily a *graphical* user interface though. At this point
> there are already a number of them:
> gnucash
> cutecash
> bindings (with subdirectories for python and guile)
>
> The bulk of the other directories are support directories for one of the
> ui's
> and I propose to make them subdirectories of each respective ui.
>
> For example gtkmm is only used by cutecash, so let's store it there (until
> another ui would also require it, which I consider unlikely to happen
> still).
>
> The other directories (gnome-utils, gnome-search, gnome, register, html,
> report, import-export,...) are all used only in the gnucash application and
> hence should be moved there. In the move I'd like to try and reduce the 3
> gnome* directories to one and call it gtk as we're not using any gnome
> specific technology any more.
>
> In a later phase I think it would be nice if the core libgnucash could also
> spit out html reports, but that would require us to refactor the report
> modules, which I consider too much work to be done at the same time. When
> this
> eventually gets done the non-ui part of the report system can then be
> added in
> libgnucash to the benefit of all consumers (gnucash/cutecash/Gnc4Android/
> ...).
>
> Feedback or questions ?
>
> Geert
>

I echo the other sentiments: This will make it much easier to grok and
contribute to gnucash.

Concerning cutecash, "It's not maintained" may be the case now, but I
remember working on some libqof changes before and having to "maintain"
cutecash since it was breaking because of the changes. It was a bit
irritating. If it's a difficult thing to bring yourself to, perhaps you
could have a friend pull the trigger? ;-)

Thanks for thinking through this and putting it on paper. I look forward to
seeing the fruit of this labour.


More information about the gnucash-devel mailing list