[CC'ing gnucash-devel] On Sun, 2006-01-22 at 19:16 +0000, Neil Williams wrote:
> I don't understand what's happened to this routine. It was created initially > to use qof_book_merge but now it picks bad defaults and complains when the > book already contains accounts - the entire premise of the function! Yes, the druid complains when the accounts are different than the ones that exist ... specifically as you alude to later, when the status of the placeholder flag is different. > In the current design, I get an unintelligible error message telling me to > resolve a conflict I cannot even see in the dialogue. By arbitrarily clicking > on each column until something changed, I realised that it is the mysterious > column marked simply 'P' that needs the check mark removed - I thought the > point of the function was to handle existing accounts and allow them to be > updated with other account details. Yeah, this is pretty annoying. Here's a summarization of the situation: - The new-account-hierarchy druid's revised merge complains and prevents the merge if the new account-tree is different than the existing one, even in placeholder status. - The example-account trees have changed to have more reasonable placeholder values. - Since many users (Neil and myself included) have created account-trees from the *previous* version of the example accounts, where the placeholder flags were different, the druid complains in about conflicts in the most basic use-case. > Can't the columns be made resizeable? I think the flags need to be reversed > so > that *by default* accounts that already exist are NOT made into automatic > errors. The error message just doesn't seem to help. Yeah, I've never been happy about the width of the "placeholder" column; on my display it's not even a full "P", but instead a truncated one. Certainly "P" isn't a user-interface universal. And I believe the "use existing?" column does have a bit more text, but it is -- again -- not resizeable. Also, I'm not super-thrilled with the text here -- either the "use existing?" column-heading or the error help text. Suggestions for improvements are welcome. > I think this section is wrong: > if (xaccAccountGetPlaceholder(existing_acct) != > xaccAccountGetPlaceholder(new_acct)) > return GNC_ACCOUNT_MERGE_DISPOSITION_ERROR; > > If the new account (which is generated and arbitrary) is marked as a > placeholder, that's sign enough that the existing account takes precedence > and therefore the reading should be > GNC_ACCOUNT_MERGE_DISPOSITION_USE_EXISTING [deletia] > I think the GUI should just "do the right thing" which would be to use the > existing accounts wherever they exist and NOT complain. [I don't know what you mean that "new" accounts are generated and arbitrary, I wouldn't consider them either. I also don't understand the implication regarding precedence ... but both are immaterial...] You seem to be saying: "Difference in the value of the placeholder flag on an account should not prevent a merge". I agree. The current logic (basically: match on name and placeholder equality) was the output of an IRC discussion with David the other weekend [see line 167 of http://svn.gnucash.org/trac/browser/gnucash/trunk/GNOME2_STATUS?rev=12336 if you're curious of the discussion]. At the time we believed that the placeholder flag matters much. After implementing it and playing with it, I don't believe so anymore. However, that does introduce a problem in the UI ... the example-accounts on disk are marked Placeholder, and (presently) the UI indicates them as Placeholder. If an existing account of that name exists with a different Placeholder value, then we have 3 options: 1/ update the existing account to match the placeholder flag of the example account. 2/ fix the UI so that the placeholder column reflects post-merge reality (effectively the current state of the existing account). 3/ extend the UI so the user is prompted and can choose to use either the existing-account or example-account Placeholder value. I'm a fan of (2), personally. We then treat the example account's Placeholder flag as "advisory" or non-normative, and defer to how the user has their existing books configured ... but new users have their accounts setup "correctly". -- ...jsled http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel