New transaction matcher

[Benoit Grégoire]

> > I honestly think you got the right basic idea for the matcher, and that
> > it's clearly the best idea (at least for now).  As you might have
> > guessed, there's a number of things I would like to change, but i am sure
> > we will find a common ground.  It mostly has to do with the lack of
> > status on the main page, and the gui behavior (tough I realize much of
> > the later it is probably because you haven't had time to code it.)
>
> Sure, go ahead and propose improvements. Of course for me everything's
> obvious, so your suggestions are definitely helpful.

OK, here I go (some of this is very superficial, I didn't really dive into the 
code yet)

-Right now, any added split are added balanced, no matter what you select 
(that is even the case in my old matcher now I checked).   This caused me to 
start hunting for bugs in the OFX module, until I realized the matcher added 
it's balancing split in the SAME account as the source account.  This is a 
bug, but illustrates a more fundamental problem:  The user is now FORCED to 
use double entry.  That is not necessarily a bad thing, but if we do that, it 
is imperative that we force the user not to click OK until he decided on the 
destination split or to reconcile any transaction where the match was 
inconclusive, or where the split is to be added but no matching string has 
been found.

-The actions must go back to the main window.  The actions would now be:
1) "New (Auto-Balance)" (Clicking that pops open the account picker if the 2) 
transactions isn't already balanced, if no account was selected, return to 
previous action.)
2) "New (Manual)" (Not for 1.8, but that would pop up a register with the 
transaction, which would allow the user to split the transaction in multiple 
accounts)
3) "Duplicate (Reconcile)" (Same behavior as current) 
4) "Duplicate (Edit)" (Not for 1.8, replaces the "REPLACE" action, would pop 
up a register with the matching transaction, to allow the user to add or edit 
notes or description)
5) "Do not import" (New name for SKIP)
The action names should be shortened, but for now these are explicit.  Now 
that we have more real estate (and until we can implement a drop down box).  
A different type of GUI (a list of pixmap, used like radio buttion) could be 
implemented.  It would fit the new model much better, but requires 5 
carefully designed new pixmaps (3 for now) that represent the actions well 
(In the short term, 5 buttons with a letter on each and a legend might be 
enough).  They would each be in their own column (with no title) and have a 
depressed version.  That way it would be obvious what action is about to be 
taken, and what to do to change it.  The action button would no longer exist 
in the pop-up transaction matcher.

-There must be visual feedback that the match was inconclusive.  I suggest we 
color the row in light red (or a tiny warning flag maybe?).  Also, the score 
pixmap for the top match should be included in the main window if action is 
to reconcile.  That pixmap would be replaced with another one if the 
transaction was auto-completed automatically, or is to be added but awaits 
selection of the destination account.

That's it for now, this message is already long enough.  The rest is 
relatively minor, and unlikely to lead to much debate.

-- 
Benoit Grégoire
http://step.polymtl.ca/~bock/