Import transactions change proposal

Chris Morgan cmorgan at alum.wpi.edu
Mon Feb 3 17:18:43 CST 2003


On Monday 03 February 2003 11:06 pm, Benoit Grégoire wrote:
> 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.
>

It's pretty easy.  You handle button events and look for a GDK_2BUTTON_PRESS 
event.  And yes, it is a questionable decision on the part of the gtk 
designers to leave this event out, I suppose the assumption is if you need it 
you can make due with button event processing.


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

Yes, it would be useful to add a button to perform the action taken by the 
double click


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

I don't believe that the row will become unselected.  The behavior of clicking 
multiple times on the same row is to keep it selected so this isn't a 
problem.

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

Hmm...  any idea how ms money handles multiple transaction imports? Maybe its 
interface could be of some use to us.  I'll check tomorrow at work.


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

Ahh, I was hoping for more code comments, I'll look into the doxygen 
docs(debian isn't happy with some dependencies right now and can't get 
doxygen installed). 


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

Chris


More information about the gnucash-devel mailing list