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