Import transactions change proposal

BenoitGrégoire bock at
Mon Feb 3 23:06:27 CST 2003

On February 3, 2003 04:09 pm, Chris Morgan wrote:
> There is no need to handle select and unselect signals as the actual
> selection of rows is performed internally to the clist, the signals are
> only if you want to take action upon selection/unselection.  Basically the
> user would select multiple rows either using the manual text search and
> highlight box, or by holding the space bar and highlighting rows, then they
> double click to sort the selected rows into an account.

That IS my point.  Currently, we take actions when a row is selected, actually 
three different actions, depending in which row the user clicked.  It's 
implemented using the select signals.  What do you plan to replace this with?  
There is no "clicked" or "double-clicked" signal for a row anywhere in the 
GTK docs.  Anyhow, I presume you'd somehow replace the actions currently 
taken by a simple click by double clicking in the same column.  I see two 
issues with this.

1-Say i select three transactions, and then want to double click (something is 
suppose you would implement with a timer) to change them all to add.  If I 
don't keep holding space during my double click, my first click (if memory 
serves) will cause the transaction selected to be the only one selected, and 
my second will deselect it, leaving me with no transaction on which to take 
the action.  

2-Say I just wan't to change a single transaction to 'add', and then select 
the destination account.  I have to first select it (you'll have to read the 
state of each row, since you will no longer be using the select/unselect 
signals, and if I just double click, it will unselect on the second click, 
causing the same problem as above).  Then I double click to add, and have to 
double click again to pick the account.  What used to take two clics now 
requires 5 (actually, click - mandatory pause - double click - double click).

GtkClists are just not flexible, and I just don't see how the API will allow 
you to maintain current functionnality while allowing multiple selections 
(which could be usefull I agree).  I'm affraid you'd have to put the add, 
clear and action buttons outside the Clist, which would be going back to the 
way it used to be, and make a lot of people unhappy.

> > > - Modification of run_account_picker_dialog() to accept a list of
> > > transactions instead of a single one.
> >
> > Err, I suppose you mean gnc_gen_trans_list_add_trans()?
> I believe run_account_picker_dialog() is correct, it is called around line
> 384 in import_main_matcher.c when a user has clicked(or in the new case
> double clicked) on DOWNLOADED_CLIST_ACTION_INFO(the right most column I
> believe) and if the current action is GNC_Import_ADD.

Ok, I see what you mean.  That's how it would probably be implemented.

> What does gnc_gen_trans_list_add_trans() do?  There are no code comments or
> use of this function in the import-export directory, it appears to be used
> when adding a transaction to the import matcher.  This would be a good
> place to put an auto matcher it seems as it would allow for each newly
> added transaction to be checked, it is a bit different than what I'm trying
> to do right now though.

It's the main entry point of the generic importer.  See the Doxygen developper 
docs (if you use CVS, you need to run make docs, and have doxygen installed 
to get them).  ALL functions and data structure of the generic import 
achitecture are documented.

> I think that idea makes a lot of sense.  I'm proposing adding a search box
> and search button that would allow the user to select the transactions
> themselves, rather than have gnucash do everything for them.  I think both
> could coexist without an issue.

Assuming you solve the "select" issue, yes.

Benoit Grégoire

More information about the gnucash-devel mailing list