Jeremy Collins <[EMAIL PROTECTED]> writes:
> I do believe that certain areas of Gnucash are complex. The
> register is one that comes to mind. I spend several days combing
> through the code for the register and still probably don't have a
> good understanding of whats going on.
The register was one of the more complex bits of code I've tried to
understand, but I'm not sure how you could easily make it much
simpler. Linas and I have talked about that a couple of times, with
me coming up with "grand plans" on how to make it better, and him
pointing out the bits I forgot about that make my plan either a major
overhaul or unworkable.
> This new build system that is being worked on should hopefully make
> compiling easier. Speaking of which here is another thought on
> that. What about spliting the distribution of Gnucash into parts.
> One for each GUI. I personally think that all of this
> GUI-independent code is causing the code to get messy. Its great to
> reuse code.. but I think it is getting out of hand here.
I don't disagree about the splitting part. We should absolutely allow
people to just build one or the other interface without having to have
the other UI's bits installed on the system (you shuldn't have to have
less/motif installed to build the gnome version), but have you looked
carefully at the ui-independent bits in the register. Much of that is
*really* tricky ui independent engine related code that you don't want
to have replicate in each UI's source files. However, this is to some
extent an artifact of trying to have the "register/table*"
UI-independent abstraction layer in the first place. If you were to
just place the GUI directly on top of the engine, you might get a very
different code structure, but I don't think without *really* careful
evaluation, and even a proof of concept implementation, you could say
with any conviction that that would be a better way. Getting dynamic
updating and UI syncronization right is just a bit tricky, no matter
how you do it.
> We also probably need some sort of "guide" to developing Gnucash.
> It should contain an up to date list of what is being worked on, who
> is working on it, and what else needs to be worked on. It should
> also contain information on getting there patches accepted, and who
> they should send them to. etc, etc, etc... you get the picture.
Probably a good idea.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
