Clarifications and guidance for a hopeful contributor

[David Carlson]

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> 
>>> wrote:
>>>
>>> Hello,
>>>
>>> I've spent a few days going through the wiki, uservoice, HACKING & 
>>> README
>>> files, commit history, list archive, and building and debugging the 
>>> code.
>>> 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 
>>> the
>>> 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 
>>> that,
>>> are pull requests allowed/encouraged, or ignored as the README 
>>> suggests?
>>>
>>> 2. How accurate is the Roadmap in the wiki? Some of the goals there 
>>> haven't
>>> 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, 
>>> locked
>>> until the register is ported?)
>>>
>>> 4. Probably most important for now: What's the best place for me to 
>>> start
>>> contributing, get my feet wet in the code-base, and make an impact? 
>>> With
>>> 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.
>>
>> Regards,
>> 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:-)
>
> https://bugzilla.gnome.org/show_bug.cgi?id=739571
>
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>


Tracy,

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 
documentation.

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 
solution.

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* 
<https://bugzilla.gnome.org/show_bug.cgi?id=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 ;).

David C