Re: Comment on interface
Vahur Lokk wrote: Hi all! Trying out Gnucash for my one-man-translation business (been using GC for my family bookkeeping on and off for couple of years). One note about business functions. In a small business like mine amount of customers is not really very big. I've got maybe 2-3 big ones plus bunch of smaller clients. The same with vendors - I get bills from ISP, phone company, mobile company, car lease and thats it. In order to pick a vendor from my huge 4-vendor list I have to use search. First, its bit of an overkill and not very convenient. Second, there is not a way to see, who I actually have in my list. It might sometimes come in handy (think dupes etc.). Maybe it would be more user-friendly to make some kind of list window for customers and vendors where one can search if one so wishes? Hi, Vahur! This is exactly what I've been wishing for, and the reason I've been lurking here. Since you've broken the silence, I'll chime in. I'm in the same boat - always creating invoices for the same 3-4 clients. It takes me about 10 clicks to get to the point where I can perform my most-used task - add a line item to an un-posted invoice. Sometimes I can leave some windows open, which helps, but not to the point that it doesn't bug me. I would offer to try to tackle this but GUI programming is not exactly my thing. JT -- Web:http://www.signless.com E-Mail: [EMAIL PROTECTED] Cell: (541) 543-4888 Skype: jt.justman ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re (IRC): 2.2.0 and auto-save
14:40:57 warlord Hmm, are we going to have a 2.1.6? 16:21:25 andi5 warlord: wrt 2.1.6, if we plan not to revert the auto-save feature, we might want to have another test version iff christian wants to extend / improve it if we just change the default to disabled auto-save, then i am fine with no 2.1.6 as well... 16:21:52 warlord andi5: ok I don't want to extend/improve the auto-save feature before 2.2.0 (not enough time available). For that reason I don't think we need another 2.1.6 but should plan for 2.2.0 on the weekend July 15th, http://wiki.gnucash.org/wiki/Release_Schedule It seems to me the perfect solution would be to have a separate save-to-checkpoint function as opposed to the save-to-working-file, with extra auto-restore questions at startup, as outlined here by Eric Ladner http://lists.gnucash.org/pipermail/gnucash-user/2007-July/020890.html This would require major changes in our saving infrastructure, which I'm not going to do in the upcoming 1-3 months. As an aside, I'd like to point out that the current auto-save behaviour represents exactly how gnucash would behave with a database-backend currently, as explained here correctly http://lists.gnucash.org/logs/2007-07-04.html#T15:30:38 But for 2.2.0 we have the following choices: #1: Auto-save-datafile is enabled by default, just with a different default value (5 minutes? 10 Minutes?), and the explanation dialog box pops up upon the very first auto-save activation. Users would have to into the preferences to disable this feature. #2: Auto-save-datafile will be enabled once, then on the explanation dialog box the user is asked whether she/he wants to have this enabled: auto-save ... blabla ... Do you want to enable or disable this? [Enable] [Disable] #3: Auto-save is disabled by default and users have to find out the Option by themselves to enable it. No extra dialog explanation will be shown for this option, neither after startup nor at activation time or whatever. Using this feature is therefore restricted to those users who happen to stumble upon this during browsing through the preferences. The feedback from gnucash-user clearly points toward #3. However, my main intention was to implement a feature that helps the normal user to decrease the negative outcome of when an error occurs. This boils down to the question what behaviour the normal user actually expects from gnucash. As a programmer I know that my way of understanding gnucash is probably rather different from what the normal user does. However, I'm not so sure whether the gnucash-user feedback talks more about the normal user expectation than what I would think of, because those subscribers are power-users just as we are. (For example, my wife says the new auto-save behaviour is just fine and understandable, whereas the abovementioned restore-checkpoint-at-startup behaviour would be utterly confusing for her - she never really understands what she is supposed to answer when a program asks at startup about restoring whatever thingy is also there. I'm just saying we developers have to find a decision which doesn't necessarily conform with the majority of feedback on our mailing lists. Neither we ourselves nor even the users of our mailing lists might correspond the normal user in a representative way. Decisions, decisions... Following this way of thought I would decide for choice #1, leave as-is for 2.2.0. What do the other developers say? Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Re (IRC): 2.2.0 and auto-save
I'm just saying we developers have to find a decision which doesn't necessarily conform with the majority of feedback on our mailing lists. Neither we ourselves nor even the users of our mailing lists might correspond the normal user in a representative way. Before you claim to make such decisions based on what the normal user wants, then, I suppose you need to agree on how to obtain the desires of the normal user. If not through feedback on gnucash-users, then how? How will you ever know what the normal user wants, if not through some feedback mechanism? You should also define the normal user. Is it an average of feedback from users, the loudest feedback, the closest feedback (e.g. our spouses or partners), the most feedback (popularity vote), or ??? If everyone is on the same page regarding that, then you may have an easier time deciding what the direction of gnucash ought to be. Then again, this is open source. You also need to be interested in coding features in order to put forth the effort. With gratitude for your ongoing efforts, Dan W. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Re (IRC): 2.2.0 and auto-save
Christian Stimming [EMAIL PROTECTED] writes: Following this way of thought I would decide for choice #1, leave as-is for 2.2.0. What do the other developers say? I like option 3. The implemented auto-save doesn't behave in the conventional way (with a separate checkpoint file); it probably should before being enabled by default. Regardless, some will still want the feature, especially since we have an alternate mechanism for creating checkpoint files that could be used in the case of an undesirable autosave. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpueP0dYjdDC.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Comment on interface
JT Justman [EMAIL PROTECTED] writes: Vahur Lokk wrote: lease and thats it. In order to pick a vendor from my huge 4-vendor list I have to use search. First, its bit of an overkill and not very convenient. Second, there is not a way to see, who I actually have in my [...] Hi, Vahur! This is exactly what I've been wishing for, and the reason [...] Sometimes I can leave some windows open, which helps, but not to the point that it doesn't bug me. Speaking of bugs, see http://bugzilla.gnome.org/show_bug.cgi?id=101456. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpIZwH8R3GQd.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Re (IRC): 2.2.0 and auto-save
On Thu, Jul 05, 2007 at 10:44:46AM +0200, Christian Stimming wrote: 14:40:57 warlord Hmm, are we going to have a 2.1.6? 16:21:25 andi5 warlord: wrt 2.1.6, if we plan not to revert the auto-save feature, we might want to have another test version iff christian wants to extend / improve it if we just change the default to disabled auto-save, then i am fine with no 2.1.6 as well... 16:21:52 warlord andi5: ok I don't want to extend/improve the auto-save feature before 2.2.0 (not enough time available). For that reason I don't think we need another 2.1.6 but should plan for 2.2.0 on the weekend July 15th, http://wiki.gnucash.org/wiki/Release_Schedule It seems to me the perfect solution would be to have a separate save-to-checkpoint function as opposed to the save-to-working-file, with extra auto-restore questions at startup, as outlined here by Eric Ladner http://lists.gnucash.org/pipermail/gnucash-user/2007-July/020890.html This would require major changes in our saving infrastructure, which I'm not going to do in the upcoming 1-3 months. As an aside, I'd like to point out that the current auto-save behaviour represents exactly how gnucash would behave with a database-backend currently, as explained here correctly http://lists.gnucash.org/logs/2007-07-04.html#T15:30:38 But for 2.2.0 we have the following choices: #1: Auto-save-datafile is enabled by default, just with a different default value (5 minutes? 10 Minutes?), and the explanation dialog box pops up upon the very first auto-save activation. Users would have to into the preferences to disable this feature. #2: Auto-save-datafile will be enabled once, then on the explanation dialog box the user is asked whether she/he wants to have this enabled: auto-save ... blabla ... Do you want to enable or disable this? [Enable] [Disable] #3: Auto-save is disabled by default and users have to find out the Option by themselves to enable it. No extra dialog explanation will be shown for this option, neither after startup nor at activation time or whatever. Using this feature is therefore restricted to those users who happen to stumble upon this during browsing through the preferences. The feedback from gnucash-user clearly points toward #3. However, my main intention was to implement a feature that helps the normal user to decrease the negative outcome of when an error occurs. This boils down to the question what behaviour the normal user actually expects from gnucash. As a programmer I know that my way of understanding gnucash is probably rather different from what the normal user does. However, I'm not so sure whether the gnucash-user feedback talks more about the normal user expectation than what I would think of, because those subscribers are power-users just as we are. (For example, my wife says the new auto-save behaviour is just fine and understandable, whereas the abovementioned restore-checkpoint-at-startup behaviour would be utterly confusing for her - she never really understands what she is supposed to answer when a program asks at startup about restoring whatever thingy is also there. I'm just saying we developers have to find a decision which doesn't necessarily conform with the majority of feedback on our mailing lists. Neither we ourselves nor even the users of our mailing lists might correspond the normal user in a representative way. Decisions, decisions... Following this way of thought I would decide for choice #1, leave as-is for 2.2.0. What do the other developers say? For better or for worse, we've conditioned users (me included) to expect that they can 1) open GnuCash, 2) make undesired changes for the purposes of exploration or experimentation, 3) close GnuCash w/o saving, and 4) re-open GnuCash with their data in exactly the state they last saved it. Purely as a matter of politeness, I think it would be rude to change this behavior without any user action. Given the current difficulty of implementing a autosave-to-alternate-file behavior, I'd suggest the following: #4) (a refinement of #2) Leave auto-save enabled by default, but change the behavior slightly: - When autosave triggers prompt the user with: Auto-save Do you want to auto-save your data file? [some explanation of the implications;] [explanation that this can be customized in Preferences] [Yes, just this once] [Yes, always] [No, not right now *] [No, never] === * default Until either (a) the user sets something in the preferences, or (b) they choose one of the always/never options, then this dialog should continue to appear _every_ time the auto-save triggers. This means: - The original behavior is one click away (No, never). - The fully automated auto-save behavior is one click away (Yes, always). - It leaves the user the option of full control. (with or
Re: 2.1.5 Binary
NEMMERS, BRENT [EMAIL PROTECTED] writes: When will the 2.1.5 binary for windows be available? SourceForge only has the executable for 2.1.4. Zoltan Levardy [EMAIL PROTECTED] writes: i have found the link has not working (http://download.sourceforge.net/gnucash). This link was coming from the http://www.gnucash.org/#070702-2-1-5.news feed. Where is the latest windows setup file 2.15? http://lists.gnucash.org/pipermail/gnucash-devel/2007-July/020864.html -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgphkvq5ZP3lD.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Using gnome-doc-utils for help files
Pierre-Antoine Lacaze [EMAIL PROTECTED] writes: I'm beginning the French translation of Gnucash's help, and have been suggested that it would be a good move to look into converting gnucash-help to gnome-doc-utils [1]. g-d-u is supposedly the preferred way for documentation handling, and make use of po files. I more or less ported it already, and would like to know if there is a compelling reason not to move over. I fear myself with po files the lack of flexibility required in highly technical, country-specific documentation. For a bit more color, you and I discussed this on IRC [1], though the other day you came back and seemed to indicate that it didn't work out so well [2]. So, is that a compelling reason to not move over? In any case, can you please post a patch against the gnucash-docs sources that implements gnome-doc-utils? [1] http://lists.gnucash.org/logs/2007-07-02.html#T16:29:51 [2] http://lists.gnucash.org/logs/2007-07-03.html#T14:35:27 -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgp2lJbrInCEu.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
2.1.5 Binary
When will the 2.1.5 binary for windows be available? SourceForge only has the executable for 2.1.4. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Using gnome-doc-utils for help files
Hi, I'm beginning the French translation of Gnucash's help, and have been suggested that it would be a good move to look into converting gnucash-help to gnome-doc-utils [1]. g-d-u is supposedly the preferred way for documentation handling, and make use of po files. I more or less ported it already, and would like to know if there is a compelling reason not to move over. I fear myself with po files the lack of flexibility required in highly technical, country-specific documentation. [1] http://live.gnome.org/GnomeDocUtils -- Pierre-Antoine ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
broken link
hi, i have found the link has not working (http://download.sourceforge.net/gnucash). This link was coming from the http://www.gnucash.org/#070702-2-1-5.news feed. Where is the latest windows setup file 2.15? thx z ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Check Printing - Addresses
Andrew Sackville-West [EMAIL PROTECTED] writes:
What's the definition of primary split? Is it the first split you
create? Is it the first split tied to the account register? What
about for transactions created through other methods, like the transfer
dialog or an importer -- which split is primary?
This is based on my *very limited*
understanding, BTW, so feel free to educate me in whatever manner is
expedient... (including STFU...)
Its purely arbitrary in that for almost every purpose it doesn't
matter. But for some purposes -- specifically in this context for the
purpose of attaching additional information to a transaction, such as
an address -- it does matter. Simply use the register that is
used to create the transaction. For an invoice payment, the register the
transaction is entered into is A/{R,P} (but maybe my assumption is wrong
there). The other split is checking (could be others, I know). When
the payment is printed, the printing engine can look for a primary
split, and if that exists, and has additional information attached to
it, it could be printed as well. With an invoice payment, there is
owner information on the A/{R,P} side that could be used to grab that
address, or account number, or whatever.
I still don't see why it matters. Something like the Payee should be
tied to the Description, which is part of the Transaction object, not
the Split object. So it doesn't matter which is the primary Split
in order to add ancillary information to the Transaction.
The main issue, tho, is that we just don't have a Payees database
anywhere to tie into. Sure, we could add an address to the
transaction for printing on checks, but there's no good way to save
that information in a way to reuse it again later.
I still don't see the need for a primary split.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
[EMAIL PROTECTED]PGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Re (IRC): 2.2.0 and auto-save
Chris Shoemaker [EMAIL PROTECTED] writes: [snip] Following this way of thought I would decide for choice #1, leave as-is for 2.2.0. What do the other developers say? For better or for worse, we've conditioned users (me included) to expect that they can 1) open GnuCash, 2) make undesired changes for the purposes of exploration or experimentation, 3) close GnuCash w/o saving, and 4) re-open GnuCash with their data in exactly the state they last saved it. * me too * :( Purely as a matter of politeness, I think it would be rude to change this behavior without any user action. Agreed. Given the current difficulty of implementing a autosave-to-alternate-file behavior, I'd suggest the following: #4) (a refinement of #2) Leave auto-save enabled by default, but change the behavior slightly: - When autosave triggers prompt the user with: Auto-save Do you want to auto-save your data file? [some explanation of the implications;] [explanation that this can be customized in Preferences] [Yes, just this once] [Yes, always] [No, not right now *] [No, never] === * default Until either (a) the user sets something in the preferences, or (b) they choose one of the always/never options, then this dialog should continue to appear _every_ time the auto-save triggers. This means: - The original behavior is one click away (No, never). - The fully automated auto-save behavior is one click away (Yes, always). - It leaves the user the option of full control. (with or w/o further dialog) - Even users that don't want autosave may appreciate the reminder to save manually, (or they can avoid it, if not). - It allows the use of the autosave feature even in cases where the user wants to make unsaved changes. In any case, I am against changing the default setting in a way that requires long-time users to set a Preference in order to restore the behavior they've become used to, and at least some find useful. OTOH, I think auto-save is a very compelling feature we should make very easy to enable. So, I'm fine with #2, #3, or #4, but not with #1. I like this option #4, too. I'm also with Chris here with #2, #3, or #4 but not #1. I think I'd prefer #4, then #3, then #2. And, thanks for the nice feature, Christian. :) DEFINITELY agreed! Thank you, Christian! -chris -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: broken link
Derek Atkins [EMAIL PROTECTED] writes: Hmm, yeah, it looks like that URL should be more like: http://sourceforge.net/project/showfiles.php?group_id=192package_id=5582 Updated. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpZJmmRWMyGI.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: broken link
Hmm, yeah, it looks like that URL should be more like: http://sourceforge.net/project/showfiles.php?group_id=192package_id=5582 -derek Zoltan Levardy [EMAIL PROTECTED] writes: hi, i have found the link has not working (http://download.sourceforge.net/gnucash). This link was coming from the http://www.gnucash.org/#070702-2-1-5.news feed. Where is the latest windows setup file 2.15? thx z ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Comment on interface
Josh Sled [EMAIL PROTECTED] writes: JT Justman [EMAIL PROTECTED] writes: Vahur Lokk wrote: lease and thats it. In order to pick a vendor from my huge 4-vendor list I have to use search. First, its bit of an overkill and not very convenient. Second, there is not a way to see, who I actually have in my [...] Hi, Vahur! This is exactly what I've been wishing for, and the reason [...] Sometimes I can leave some windows open, which helps, but not to the point that it doesn't bug me. Speaking of bugs, see http://bugzilla.gnome.org/show_bug.cgi?id=101456. I'm still waiting for someone to implement the GtkCombo + GtkCompletion code that plugs generically into the QofQuery code. If someone did that work I could plug it in relatively easily. I just dont have the time to research how to and do it myself. See http://bugzilla.gnome.org/show_bug.cgi?id=101456#c3 -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Re (IRC): 2.2.0 and auto-save
Speaking strictly as a user of GnuCash, I like the current auto-save as implemented i.e. save-to-working-file; thanks, Christian! I've never played around with a GnuCash file, decided I didn't like the changes and closed without saving (but strangely enough, I do that with other programs), but that's just me. I guess if I were intending to play with my data file, I would either disable the auto-save or work on a backup copy of the file (the latter probably the safer choice). On the other hand, I can see the benefits of a save-to-checkpoint-file. But, if I could put in my 2 cents, whatever the developers decide, please: 1) inform the user of any change in behaviour that could adversely affect their data file (similar to Chris Shoemaker's option #4) , and 2) decide which method to use (save-to-working-file or save-to-checkpoint-file) and stick with it. Nothing annoys me more than a too-frequently-changing data file behaviour. If the developers are uncertain as to which method will ultimately become permanent, I would say disable the feature for 2.2.0 John New On July 5, 2007 04:44 am, Christian Stimming wrote: 14:40:57 warlord Hmm, are we going to have a 2.1.6? 16:21:25 andi5 warlord: wrt 2.1.6, if we plan not to revert the auto-save feature, we might want to have another test version iff christian wants to extend / improve it if we just change the default to disabled auto-save, then i am fine with no 2.1.6 as well... 16:21:52 warlord andi5: ok I don't want to extend/improve the auto-save feature before 2.2.0 (not enough time available). For that reason I don't think we need another 2.1.6 but should plan for 2.2.0 on the weekend July 15th, http://wiki.gnucash.org/wiki/Release_Schedule It seems to me the perfect solution would be to have a separate save-to-checkpoint function as opposed to the save-to-working-file, with extra auto-restore questions at startup, as outlined here by Eric Ladner http://lists.gnucash.org/pipermail/gnucash-user/2007-July/020890.html This would require major changes in our saving infrastructure, which I'm not going to do in the upcoming 1-3 months. As an aside, I'd like to point out that the current auto-save behaviour represents exactly how gnucash would behave with a database-backend currently, as explained here correctly http://lists.gnucash.org/logs/2007-07-04.html#T15:30:38 But for 2.2.0 we have the following choices: #1: Auto-save-datafile is enabled by default, just with a different default value (5 minutes? 10 Minutes?), and the explanation dialog box pops up upon the very first auto-save activation. Users would have to into the preferences to disable this feature. #2: Auto-save-datafile will be enabled once, then on the explanation dialog box the user is asked whether she/he wants to have this enabled: auto-save ... blabla ... Do you want to enable or disable this? [Enable] [Disable] #3: Auto-save is disabled by default and users have to find out the Option by themselves to enable it. No extra dialog explanation will be shown for this option, neither after startup nor at activation time or whatever. Using this feature is therefore restricted to those users who happen to stumble upon this during browsing through the preferences. The feedback from gnucash-user clearly points toward #3. However, my main intention was to implement a feature that helps the normal user to decrease the negative outcome of when an error occurs. This boils down to the question what behaviour the normal user actually expects from gnucash. As a programmer I know that my way of understanding gnucash is probably rather different from what the normal user does. However, I'm not so sure whether the gnucash-user feedback talks more about the normal user expectation than what I would think of, because those subscribers are power-users just as we are. (For example, my wife says the new auto-save behaviour is just fine and understandable, whereas the abovementioned restore-checkpoint-at-startup behaviour would be utterly confusing for her - she never really understands what she is supposed to answer when a program asks at startup about restoring whatever thingy is also there. I'm just saying we developers have to find a decision which doesn't necessarily conform with the majority of feedback on our mailing lists. Neither we ourselves nor even the users of our mailing lists might correspond the normal user in a representative way. Decisions, decisions... Following this way of thought I would decide for choice #1, leave as-is for 2.2.0. What do the other developers say? Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Comment on interface
On Wed, Jul 04, 2007 at 10:56:06PM -0700, JT Justman wrote: Vahur Lokk wrote: Hi all! [...] In a small business like mine amount of customers is not really very big. I've got maybe 2-3 big ones plus bunch of smaller clients. The same with vendors - I get bills from ISP, phone company, mobile company, car lease and thats it. In order to pick a vendor from my huge 4-vendor list I have to use search. [...] I'm in the same boat - always creating invoices for the same 3-4 clients. It takes me about 10 clicks to get to the point where I can perform my most-used task - add a line item to an un-posted invoice. Sometimes I can leave some windows open, which helps, but not to the point that it doesn't bug me. the best window to leave open for this purpose is the Aging reports. These give you links to the specific vendor/customer reports and then you may click on the individual invoice to edit it *or* if you need a new invoice, click on any one invoice, then hit Alt-f n i to get a new invoice in two clicks and three keystrokes. hth A signature.asc Description: Digital signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Check Printing - Addresses
On Thu, Jul 05, 2007 at 10:37:10AM -0400, Derek Atkins wrote:
Andrew Sackville-West [EMAIL PROTECTED] writes:
What's the definition of primary split? Is it the first split you
create? Is it the first split tied to the account register? What
about for transactions created through other methods, like the transfer
dialog or an importer -- which split is primary?
This is based on my *very limited*
understanding, BTW, so feel free to educate me in whatever manner is
expedient... (including STFU...)
Its purely arbitrary in that for almost every purpose it doesn't
matter. But for some purposes -- specifically in this context for the
purpose of attaching additional information to a transaction, such as
an address -- it does matter. Simply use the register that is
used to create the transaction. For an invoice payment, the register the
transaction is entered into is A/{R,P} (but maybe my assumption is wrong
there). The other split is checking (could be others, I know). When
the payment is printed, the printing engine can look for a primary
split, and if that exists, and has additional information attached to
it, it could be printed as well. With an invoice payment, there is
owner information on the A/{R,P} side that could be used to grab that
address, or account number, or whatever.
I still don't see why it matters. Something like the Payee should be
tied to the Description, which is part of the Transaction object, not
the Split object. So it doesn't matter which is the primary Split
in order to add ancillary information to the Transaction.
I thought the business stuff was tied in through the a/p a/r register
and the owner information. And that getting to that split would get
you to that information thus eliminiating the need for some other
payees database as that information already exists in the business
features.
The main issue, tho, is that we just don't have a Payees database
anywhere to tie into. Sure, we could add an address to the
transaction for printing on checks, but there's no good way to save
that information in a way to reuse it again later.
I still don't see the need for a primary split.
I won't bother you about it anymore until I go read the code... :)
A
signature.asc
Description: Digital signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Comment on interface
Quoting Andrew Sackville-West [EMAIL PROTECTED]: I'm still waiting for someone to implement the GtkCombo + GtkCompletion code that plugs generically into the QofQuery code. If someone did that work I could plug it in relatively easily. I just dont have the time to research how to and do it myself. See http://bugzilla.gnome.org/show_bug.cgi?id=101456#c3 is this the phrasewheel that I still have sitting here? Yep. Or at least a variation thereof. GTK added the callbacks necessary, so it should be much easier to implement now. But I dont have the time to do it. A -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Using gnome-doc-utils for help files
Am Donnerstag, 5. Juli 2007 16:16 schrieb Josh Sled: Pierre-Antoine Lacaze [EMAIL PROTECTED] writes: I'm beginning the French translation of Gnucash's help, and have been suggested that it would be a good move to look into converting gnucash-help to gnome-doc-utils [1]. g-d-u is supposedly the preferred way for documentation handling, and make use of po files. Without having looked too much into g-d-u details I'd *strongly* adverse moving our user documentation to po files! Po files are great for smaller chunks of translations which can be translated more or less independent from one another. Our documentation, with the Guide and Concepts being the best part of it all, is clearly not at all translatable in a paragraph-by-paragraph way, independently of one another. Also, one of the largest advantages of po files, which is the easy visualization of changed strings, becomes moot if these strings are longer than 1-2 lines. For longer strings, po only says this whole paragraph has changed in *some* way, whereas .xml or .sgml or even .txt would give you a diff showing the exact line that changed. (Diffs are not possible for po.) IMHO the arbitrary division of the help documents into separate po strings doesn't offer any advantage at all. I don't agree with this being a preferred way. Well, maybe for a subset of user documentation: This *might* be suitable to the kind of help you'd expect when pressing F1 somewhere, which gives you 2-3 sentences about what is currently going on. But this is not at all suitable for our large Guide document. I more or less ported it already, and would like to know if there is a compelling reason not to move over. I fear myself with po files the lack of flexibility required in highly technical, country-specific documentation. If you still think this might be interesting, then I'd be interested to see the .pot file that comes out of the g-d-u conversion (or part of it). I would clearly recommend against it, though. Regards, Christian [1] http://lists.gnucash.org/logs/2007-07-02.html#T16:29:51 [2] http://lists.gnucash.org/logs/2007-07-03.html#T14:35:27 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Re (IRC): 2.2.0 and auto-save
Am Donnerstag, 5. Juli 2007 16:56 schrieb Derek Atkins: Following this way of thought I would decide for choice #1, leave as-is for 2.2.0. What do the other developers say? For better or for worse, we've conditioned users (me included) to expect that they can 1) open GnuCash, 2) make undesired changes for the purposes of exploration or experimentation, 3) close GnuCash w/o saving, and 4) re-open GnuCash with their data in exactly the state they last saved it. * me too * :( Not me, though. But interesting - I haven't thought about users who got accustomed to this particular behaviour. You're all right, this must not be changed silently. I was only thinking about new users. Auto-save Do you want to auto-save your data file? [some explanation of the implications;] [explanation that this can be customized in Preferences] [Yes, just this once] [Yes, always] [No, not right now *] [No, never] === * default So, I'm fine with #2, #3, or #4, but not with #1. I like this option #4, too. I'm also with Chris here with #2, #3, or #4 but not #1. I think I'd prefer #4, then #3, then #2. Okay, so we're going for this dialog with choices. Are you up for doing this? I don't know off-hand how to implement the bunch of buttons in gtk the easiest... Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Crash of latest SVN
Derek Atkins wrote: Quoting Nigel Titley [EMAIL PROTECTED]: Latest SVN, built under Ubuntu Feisty, after a make clean and into a new install tree gives me Try make maintainer-clean? QOF-ID-BOOK-SCM is defined in src/engine/engine.i but I dont know when it was added. When was your last build? Well, a complete build from a virgin source tree, installed into a brand-new install tree is working. Heaven knows what piece of lint caused this. I've been rebuilding every week for a couple of months. I guess it was just bit-rot again. Nigel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Using gnome-doc-utils for help files
Christian Stimming a écrit : Am Donnerstag, 5. Juli 2007 16:16 schrieb Josh Sled: Pierre-Antoine Lacaze [EMAIL PROTECTED] writes: I'm beginning the French translation of Gnucash's help, and have been suggested that it would be a good move to look into converting gnucash-help to gnome-doc-utils [1]. g-d-u is supposedly the preferred way for documentation handling, and make use of po files. Without having looked too much into g-d-u details I'd *strongly* adverse moving our user documentation to po files! Po files are great for smaller chunks of translations which can be translated more or less independent from one another. Our documentation, with the Guide and Concepts being the best part of it all, is clearly not at all translatable in a paragraph-by-paragraph way, independently of one another. Also, one of the largest advantages of po files, which is the easy visualization of changed strings, becomes moot if these strings are longer than 1-2 lines. For longer strings, po only says this whole paragraph has changed in *some* way, whereas .xml or .sgml or even .txt would give you a diff showing the exact line that changed. (Diffs are not possible for po.) IMHO the arbitrary division of the help documents into separate po strings doesn't offer any advantage at all. I don't agree with this being a preferred way. Well, maybe for a subset of user documentation: This *might* be suitable to the kind of help you'd expect when pressing F1 somewhere, which gives you 2-3 sentences about what is currently going on. But this is not at all suitable for our large Guide document. I more or less ported it already, and would like to know if there is a compelling reason not to move over. I fear myself with po files the lack of flexibility required in highly technical, country-specific documentation. If you still think this might be interesting, then I'd be interested to see the .pot file that comes out of the g-d-u conversion (or part of it). I would clearly recommend against it, though. Regards, Christian I suspected so, and pot files indeed look scary and unusable. Does someone know a good way of handling big doc translation in a collaborative fashion, without resorting to hard to use tools ? I know of a wiki engine capable of editing docbooks, or exporting to docbooks. -- Pierre-Antoine ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash 2.1.5 Released
And it's ready. Sorry for the delay. On 7/4/07, Nathan Buchanan [EMAIL PROTECTED] wrote: The windows binary should be ready tomorrow - I'm running a bit behind this time. Nathan -- _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Got Mole problems? Call Avogadro at 6.02 x 10^23. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Using gnome-doc-utils for help files
As a GNOME translator, I can say translating documentation with PO files is _much_ better than editing XML files. I agree PO files are much more handy when translating user interface, but editing XML files isn't any better. The translation tools (or vim/emacs/etc. po-mode) allow us to focus on the actual text, not on the document structure. I never ran into a GNOME document which paragraphs I needed to merge of split. Sometimes I think I would have structured the text differently, but that's not locale-specific. I never translated GnuCash documentation, but from what I read I believe I wouldn't have any problem using gnome-doc-utils with it. One advantage of gettext translation is that, if I translate the hole document and a documenter changes a paragraph, the rest of the document is still translated and only that paragraph will be shown in English. The lack of this features makes translators avoid translating man pages, for instance. I agree sometimes it's hard to spot where the message was changed, specially if it's a long paragraph. There ways to circunvent this, however: 1. You may run wdiff (http://www.gnu.org/software/wdiff/) between previous and current original message, and add the output to the comments. 2. You could adopt gettext 0.16 and use the --previous function in msgmerge I never saw a project using any of these, and I don't know if they are easy to implement. Between gnome-doc-utils without the tricks above and plain XML editing, I prefer the former. Maybe that's all because I'm used to gnome-doc-utils, but honestly I'll try to use xml2po (from gnome-doc-utils) even if I'll have to build XML latter to commit it. Leonardo Fontenelle http://leonardof.org/2007/07/01/gnome-user-guide-completely-translated-to-brazilian-portuguese/en/ 2007/7/5, Pierre-Antoine [EMAIL PROTECTED]: Christian Stimming a écrit : Am Donnerstag, 5. Juli 2007 16:16 schrieb Josh Sled: Pierre-Antoine Lacaze [EMAIL PROTECTED] writes: I'm beginning the French translation of Gnucash's help, and have been suggested that it would be a good move to look into converting gnucash-help to gnome-doc-utils [1]. g-d-u is supposedly the preferred way for documentation handling, and make use of po files. Without having looked too much into g-d-u details I'd *strongly* adverse moving our user documentation to po files! Po files are great for smaller chunks of translations which can be translated more or less independent from one another. Our documentation, with the Guide and Concepts being the best part of it all, is clearly not at all translatable in a paragraph-by-paragraph way, independently of one another. Also, one of the largest advantages of po files, which is the easy visualization of changed strings, becomes moot if these strings are longer than 1-2 lines. For longer strings, po only says this whole paragraph has changed in *some* way, whereas .xml or .sgml or even .txt would give you a diff showing the exact line that changed. (Diffs are not possible for po.) IMHO the arbitrary division of the help documents into separate po strings doesn't offer any advantage at all. I don't agree with this being a preferred way. Well, maybe for a subset of user documentation: This *might* be suitable to the kind of help you'd expect when pressing F1 somewhere, which gives you 2-3 sentences about what is currently going on. But this is not at all suitable for our large Guide document. I more or less ported it already, and would like to know if there is a compelling reason not to move over. I fear myself with po files the lack of flexibility required in highly technical, country-specific documentation. If you still think this might be interesting, then I'd be interested to see the .pot file that comes out of the g-d-u conversion (or part of it). I would clearly recommend against it, though. Regards, Christian I suspected so, and pot files indeed look scary and unusable. Does someone know a good way of handling big doc translation in a collaborative fashion, without resorting to hard to use tools ? I know of a wiki engine capable of editing docbooks, or exporting to docbooks. -- Pierre-Antoine ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
developer account created jeff
This is an automated e-mail via the add-new-developer script ($Revision: 1.7 $). Developer account Jeff Green has been created: [EMAIL PROTECTED]. Admins (root) should update CVS access for this user. Welcome to the team. -- (script run by root). ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Welcome to the GnuCash Developer gene pool
Welcome to svn.gnucash.org. You now have an account, jeff, which you can use to access the SVN sources. You can now access the sources by: $ svn checkout svn+ssh://svn.gnucash.org/repo/gnucash/trunk src-trunk [or maybe: $ svn checkout svn+ssh://[EMAIL PROTECTED]/repo/gnucash/trunk src-trunk if your username is different.] You will also have mail forward automatically. Good Luck, The GnuCash Server Maintainers ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
gnucash aborts
Dear Sirs and Madams, About a week ago I installed gnucash 2.1.4. I t was working OK on a windows XP system. Yesterday I tried using it from a user account and it failed, it still works from an admin account Today I downloaded and installed gnucash 2.1.5. It opens OK using a admin account, but still fails in a user account. The error message is unspecified fatal error encountered, aborting. I OK it and then it throws up a Microsoft Visual C++ Runtime Library error This application has requested the Runtime to terminate in an unusual way ... Where do I look to see what the problem is? Thanks in advance Yours Sincerely Stephen Grant Brown BEGIN:VCARD VERSION:2.1 N:Brown;Stephen;Grant;Mr FN:Stephen Grant Brown ORG:Sea Sauce Home Garden Maintainance TITLE:Owner TEL;WORK;VOICE:(03) 5862 2669 TEL;HOME;VOICE:(03) 5862 2669 TEL;CELL;VOICE:0400 857 651 ADR;WORK:;;3781 Goulburn Valley Highway;Numurkah;Victoria;3636;Australia LABEL;WORK;ENCODING=QUOTED-PRINTABLE:3781 Goulburn Valley Highway=0D=0ANumurkah, Victoria 3636=0D=0AAustralia ADR;HOME:;;3781 Goulburn Valley Highway;Numurkah;Victoria;3636;Australia LABEL;HOME;ENCODING=QUOTED-PRINTABLE:3781 Goulburn Valley Highway=0D=0ANumurkah, Victoria 3636=0D=0AAustralia EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20070706T050442Z END:VCARD ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
