I'm tackling this bug as my first contribution to the project and have a few technical questions.
To track pending matches within the current import process there are two main possibilities that come to mind. I'm almost sure the first is a bad practice, but I don't want to make assumptions about the general system architecture and use patterns. The first is that it appears the Split on the GNCImportMatchInfo objects are somewhat persistent (I didn't jump into the bowels of the query system, but I didn't see them being freed anywhere in import-export). Therefore, I could piggy back on the Split to store information about whether it was a pending match for one of the imported transactions. This seems like a bad idea since it breaks encapsulation of the feature, plus if these are truly persistent throughout the application it just creates a mess and cleanup issues. The second route (and the one I've already started on) is to have a new object which ref counts pending matches (essentially, a map of match info's to their ref count and some metadata for display). An instance of this object lives in GNCImportMainMatcher and is passed to the GNCImportMatchPicker providing fast lookup for each match. If this doesn't pass the sniff test please let me know. Since this is brand new, mostly self-contained code, I'm going the C++ route with it. I'm curious what the state is of the recommended Google Test integration. The Testing page on the wiki has a blank section for this, and I wasn't able to locate any other examples in maint. I see several uses in master, so maybe this isn't something that has been merged to maint? If that's the case I can test through the C interface to the C++ class as it's a fairly trivial object (or I can nix the C++ idea altogether if that's preferred). Lastly, I've read the wiki on translations but I didn't see anything about a preferred process for getting new strings translated. Is it good enough to add the _() as documented and someone will pick it up eventually, is a bug preferred, or something else? Thanks! -Jesse _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
