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 <je...@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@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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
