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 _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
