Clarifications and guidance for a hopeful contributor
david.carlson.417 at gmail.com
Mon Jan 18 11:52:41 EST 2016
On 1/17/2016 7:03 AM, Tracy wrote:
> On 1/17/2016 01:31, John Ralls wrote:
>>> On Jan 16, 2016, at 5:02 PM, Jesse Olmer <jesse at wickedgoodtimes.com>
>>> I've spent a few days going through the wiki, uservoice, HACKING &
>>> files, commit history, list archive, and building and debugging the
>>> I'd like to start contributing but would appreciate some help with the
>>> following few questions:
>>> 1. How does the project prefer code submissions which are not fixes for
>>> bugzilla bugs? Several sources have contradictory information on how
>>> project prefers to receive commits/patches. It's clear that if
>>> there's a
>>> bug filed the project prefers a patch submitted in the bug. Beyond
>>> are pull requests allowed/encouraged, or ignored as the README
>>> 2. How accurate is the Roadmap in the wiki? Some of the goals there
>>> been changed since 2010 so I'm not sure if they're still a priority
>>> or not
>>> (e.g. replace deprecated libs that are gone from gtk3).
>>> 3. I believe I read that all new features should be written in C++. How
>>> strict is this (e.g. are feature additions to, say, the register,
>>> until the register is ported?)
>>> 4. Probably most important for now: What's the best place for me to
>>> contributing, get my feet wet in the code-base, and make an impact?
>>> over 1000 bugs in Normal priority it's hard to identify a true
>>> priority vs.
>>> an area which is likely to be rewritten "soon".
>> You'll also want to review the Doxygen-based documentation at
>> http://code.gnucash.org/docs/. There are two sets, MAINT and MASTER
>> for the stable and development branches.
>> Pull requests are encouraged, especially for complex changes where
>> multiple commits make clearer the stages of redevelopment. Work in a
>> feature branch and rebase it frequently on the branch it tracks.
>> The roadmap is up to date. It's also very ambitious and we're short
>> of resources so we expect it to take a long time.
>> The requirement for C++11 depends on what you're doing. On the one
>> hand there's plenty of work that can be done in C, on the other
>> anything that involves substantial rewriting should be done in C++11
>> so that it's done only once.
>> Register and its GtkTreeView sibling Register2 is a bit of a special
>> case. I don't think we've really figured out what to do with it at
>> this point. Its code is a bit messy and reg2 simply copied-and-pasted
>> huge swaths of reg code, changing a few pieces here-and-there to work
>> with GtkTreeView instead of the gnumeric-based custom code of reg. I
>> think that it all needs massive cleanup before it's even safe to add
>> features to it, but others might think otherwise.
>> The best way to get familiar with the code base is to work on bugs.
>> As you observed, there are plenty to choose from. The severity and
>> priorities are usually set by the submitter and seldom changed by the
>> developers so they're not very useful for selecting what to work on,
>> but I put crashers at the top of my list. I suggest that you pick a
>> single component to limit the amount of code you have to digest right
>> away, look at some of the bugs in that area, and then come back and
>> ask more questions.
>> John Ralls
> Here's a bug that shouldn't involve Register or Register2, but should
> be an easy fix, if you're looking for a convenient starting point... O:-)
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
In your example scenario you say ...
When I import the QFX file, the transactions are shown in the GITM, with
a default action chosen of "U+R". Now, before I allow GITM to match
these transactions, I want to verify the matches for the transactions.
So I double-click on one of the transactions. It opens a "Select
Matching Existing Transaction" window (hereafter "SMET") with the three
transactions that possibly match listed, and one transaction selected.
So I accept that match (returning to the GITM window) and change the
action from "U+R" to "R" (as I don't want the date or the payee
modified). At this point, I remove the default action from the other two
transactions referenced above, and choose "OK" in the GITM window."
My question is how do you "remove the default action"? Do you select the
action whatever the wording is to turn the transaction red? And then you
can import again from the same OFX file whichever transactions were red
in the first pass? If so, I think that should be in the GnuCash
As for the coding, I don't really know what the code is doing, but I do
know that beyond what is visible in the UI, the code is also looking for
a hidden value in the existing GnuCash transaction records by checking
for a match to the "FITID" that has to exist in the incoming OFX file
for each transaction to see if the transactions were imported before .
That is the main method used to filter out duplicates when the same or a
similar OFX import file appears from the same "FI". This does not
change the need for some better response from the program for your
example scenario, but it may complicate the code needed to implement a
There are several other issues in the "GITM" as you call it that I would
also like to see addressed if someone dares to touch that code. One
that really bugs me is the lack of a highlight in the "GITM" window for
the particular transaction selected for reference in the "SMET"
window. When the "SMET" window closes there is no way to know where the
user is in reviewing the list. That is reported as *Bug 673307*
I hope this does not scare Jesse Olmer, just whet his appetite. It is
also a brazen attempt to put my favorite "OFX" import issue at the top
of his list ;).
More information about the gnucash-devel