Source directory restructuring

Geert Janssens geert.gnucash at kobaltwit.be
Tue Aug 8 03:29:05 EDT 2017


On maandag 7 augustus 2017 21:27:18 CEST John Ralls wrote:
> These are to be top-level directories, so the current src goes away, right?
> The rest assumes that to be the case.
> 
Yes, I would drop src.

> Let's call the libgnucash directory libgnucash instead of just lib and keep
> lib as the place put code pinched from elsewhere like the bits of
> libgoffice.
> 
That's reasonable.

> I want to get rid of gnc-module too, but it's not easy.
> 
Indeed. I didn't plan this in the first phase. Except perhaps for some low 
hanging fruit (like what I did with a couple of reports subdirectories) I 
don't think this is something to target for 2.8.

> App-utils has stuff that belongs in libgnucash and other stuff (e.g.
> options) that belongs in the application directory (which I propose calling
> "gnucash" below). There's also code splattered all over everywhere else
> that belongs in libgnucash. How much of a prerequisite to rearrangement is
> getting the code in the right place?
> 
There's a gui and non-gui aspect to the options. The gui aspect clearly should 
go to the "gnucash" part. The non-gui aspect probably not. In my long term 
idea libgnucash should be able to generate reports (but not display them) to 
allow the bindings (and eventual smartphone apps) access to this feature. As 
things stand now, the report system requires the options. We all agree of 
course the options are currently a complicated mixture of C and guile code 
which needs serious modernization. That will not be for 2.8.

But your general message stands. Lots of code is in the wrong functional 
source group. And there definitely won't be time to reorganize all of that.

> I think that having separate documentation directories (there are two, doc
> and src/doc) is an abject failure from a maintenance standpoint. A lot of
> stuff was written 15-20 years ago and was marked obsolete 10 years ago
> because it's been left to rot. All documentation needs to be in the source
> files as Doxygen comments. We should look through the docs and src/docs
> stuff and copy anything that's still relevant into comments in the
> appropriate source files and delete the docs directories.
> 
Good idea.

> I'd prefer that the application code go into a directory named gnucash
> rather than "ui". I'm inclined toward removing cutecash entirely. It made
> sense for Christian to keep it in the Gnucash repository when we were using
> SVN, but now he should just publish it in his own Github repo.
> 
I realize I'm somewhat hesitant to drop cutecash from the repo. It looks I'm a 
bit emotionally attached to it (although I never used it and only built it 
once to test). That's probably because it's a decent first attempt to use qt 
instead of gtk. And qt for me is one of the few options that can bring us one 
code base for all form factors. (Drifting off into dreaming about Utopia...)

Anyway sticking with the current situation I believe you are right to consider 
removing it. It's not maintained, and based on the soon to be obsolete Qt4 and 
most importantly it can be recovered should we ever want to do so or are ready 
to go the Qt way and need a base to start from.

> The bindings are mostly (and should probably be entirely) libgnucash
> bindings. They really belong in libgnucash or failing that in their own
> TLD, not part of the application.
> 
TLD then.

> Reports might stand on their own as a separate dependency of gnucash or they
> could be a subdirectory of gnucash. The same is true of import-export. In
> one approach  the GUI parts of each would be part of the application while
> the functional bits would be part of libgnucash. Are the matchers
> libgnucash or gnucash?
> 
Long term I would like to see the functional part of both reports and import/
export be part of libgnucash and the gui's go into gnucash. I think there are 
use cases where smartphone apps and the bindings would benefit from this.

For 2.8 that would again be too much work. For this initial step I'd consider 
the plugins directory to be the location to store self-contained, loadable 
modules. There are already a few smaller ones in there. I'd add the report and 
import/export directories in there as well until we're ready to split them up. 
My work on the csv importer is an important step in the right direction. For 
the next major cycle I hope to continue this for the other importers and 
exporters as well.

> Gtk+ is very much Gnome and depends on other pieces of the Gnome project.
> The actual name of the directory isn't really important so we can call it
> gtk if you'd rather, but there are lots of other Gnome project dependencies
> that aren't going away as long as we're using Gtk+. Remember that in
> addition to gnome, gnome-util, and gnome-query there's also register-gnome,
> report-gnome, and (until your latest changes) business-gnome. There's also
> Gtk+ code in import-export, html, and probably a few other places that
> don't immediately come to mind. Setting that aside we still have all of
> that GValue and g_object_set/get code that we use for communicating between
> the engine, the backends, and the importers.
> 
> I'll point out once again that there's an immense amount of untangling to
> separate the actual UI code from glue and actual bits of libgnucash that
> are all mangled together in the various gnome directories.
> 
All true. I preferred gtk as that's the name of the toolkit the code is based 
on, whereas gnome these days refers more to a user community and a desktop 
environment.

> Does it really make sense to push much further with this for 2.8? I'd like
> to move towards releasing that as quickly as we can, then we can move on to
> extraction and rearrangement.

I share your concern about getting 2.8 out as soon as possible. I'm trying to 
balance this concern with a potential maintenance burden in the next major 
cycle. If we do the directory shuffling early in the next major cycle the 2.8 
(then to be maint branch) and the new master branch will have a rather 
diverging source directory structure which means developers have to keep two 
structures in their head for one major cycle.

I understand it's impossible to clean it all up in the few weeks we have left 
before we start the 2.8 end game. So I don't expect to be able to do more than 
some very basic top-level restructuring. My hope is this will more clearly set 
the intention for each source directory and may help in deciding which code 
should go where. And 2.8 maintenance and new master will have the same basic 
source structure reducing some of the confusion.

The real uncluttering will be for the next major cycle.

Geert


More information about the gnucash-devel mailing list