Re: auto-save now with confirmation (was: 2.2.0 and auto-save)
Am Donnerstag, 5. Juli 2007 16:56 schrieb Derek Atkins: 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: Implemented in r16256. Anyone with suggestions for improved wording? The current wording is: Title: Save file automatically? Text: (Your data file needs to be saved to your harddisk to save your changes. GnuCash has a feature to save the file automatically every %d minutes, just as if you had pressed the \Save\ button each time. \n\n You can change the time interval or turn off this feature under Edit - Preferences - General - Auto-save time interval. \n\n Should your file be saved automatically?), (_Yes, this time) (Yes, _always) (No, n_ever) (_No, not this time) The last button is the default one. Also, I added a checkbox in the preferences for showing this confirmation dialog again. Thanks for all the feedback. Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
dogtail test suite test harness
Hi Josh, Sorry for my long silence i got some issues with my PC lately, I solved it at last, currently i have a mix of good news and bad news. the good news is: 1 - Currently we have wrapper to most of dialogs, our wrapper module reach more than 1000 LOC. 2 - I'm able to test the register and i compelete a smplified version of tutorial 1 and 2. the bad news is: 1 - In order to be able to access some components, I use some raw inputs, according to dogtail the raw input is to do mouse click using the coordinate, Like rawClick(wiget.position[0], widget.position[1]) 2 - I got a problem with expanding the tree in the account pages so i only could create an account like Expenses:Taxs only parent and child more account like Expense:Taxs:Insurance currently no luck with them also to access the register I use some tricks and work around Like === def set_cell_text(self, text): relative_pos = self.column_val - self.prev_col_val print relative_pos if relative_pos 0 : for i in range(relative_pos): self.keyCombo(Tab) else: for i in range(abs(relative_pos)): self.keyCombo(ShiftISO_Left_Tab) self.typeText(text) in this code i save my previos position in if it is after my current position press tab for n times else press shit-tab for n times, something like this. ofcourse i was expecting more from dogtail unlike other Testing tool, i used or read about but the register needs some work to make it play nice with dogtail(make it accessible), BTW: i tried to play with gnucash register code, and atk but i make a very slight progress, like making dogtail read the register as table but it will require a lot of time the register code is too big. 3 - i have a problem with my svn account I contacted Derek to help me solving it. The news ends here, :) Back to testplan running: you suggested some approach like Junit, I tried pyunit and it looks nice to me, do you have any issues regarding using it to organize our test cases. Best regards, Ahmed Sayed Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Auto-Saving implemented in r16227 (to become 2.1.5) - Feedback wanted
El mar, 03-07-2007 a las 21:28 -0700, Bill Wohler escribió: For me, saving takes about four seconds. It's not enough to cause hardship, but it would be a pain while I was actively entering transactions. So, I might imagine a configuration like (every 5 minutes or 10 transactions) and 1 minute idle. With my data file savings takes more than 20 seconds, I agree with Bill, we need a control on idle gnucash time. I try to suggest an alternative, too. The developers say that during the saving process gnucash can't permit data change. My suggestion is to perform the saving in these steps: 1. save to memory a copy of the data file (gnucash doesn't permit data entry) - fast operation, should't interfere with data entry 2. return the user the permission to enter data 3. save to disk the copy What about implementing this schema for all saving operation? -- don Paolo Benvenuto http://guaricano.diocesi.genova.it è il diario che scrivo, principalmente io, ma anche altri: puoi trovarvi la vita della missione, giorno per giorno Contribuisci a wikipedia, l'enciclopedia della quale tu sei l'autore e il revisore: http://it.wikipedia.org ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: dogtail test suite test harness
Ahmad, It's a good thing you said something here. Your private email landed in my spam folder so I would never have seen it! More in-line... Quoting ahmad sayed [EMAIL PROTECTED]: Hi Josh, Sorry for my long silence i got some issues with my PC lately, I solved it at last, currently i have a mix of good news and bad news. the good news is: 1 - Currently we have wrapper to most of dialogs, our wrapper module reach more than 1000 LOC. 2 - I'm able to test the register and i compelete a smplified version of tutorial 1 and 2. This is very good news... the bad news is: 1 - In order to be able to access some components, I use some raw inputs, according to dogtail the raw input is to do mouse click using the coordinate, Like rawClick(wiget.position[0], widget.position[1]) Hmm... Is the position based on pixels or based on other widget packing? 2 - I got a problem with expanding the tree in the account pages so i only could create an account like Expenses:Taxs only parent and child more account like Expense:Taxs:Insurance currently no luck with them I think that a two-level hierarchy MIGHT be enough to test everything. Honestly it might be better if we could have a three-level hierarchy, but I think we can live with two for now. also to access the register I use some tricks and work around Like === def set_cell_text(self, text): relative_pos = self.column_val - self.prev_col_val print relative_pos if relative_pos 0 : for i in range(relative_pos): self.keyCombo(Tab) else: for i in range(abs(relative_pos)): self.keyCombo(ShiftISO_Left_Tab) self.typeText(text) in this code i save my previos position in if it is after my current position press tab for n times else press shit-tab for n times, something like this. That's perfectly reasonable. Note that you should also test the arrow keys and 'enter' as input methods. ofcourse i was expecting more from dogtail unlike other Testing tool, i used or read about but the register needs some work to make it play nice with dogtail(make it accessible), Is there some other Unix/Gnome testing tool that you'd prefer? I dont think any of us are whetted to Dogtail specifically. BTW: i tried to play with gnucash register code, and atk but i make a very slight progress, like making dogtail read the register as table but it will require a lot of time the register code is too big. Honestly I wouldn't waste too much time trying to hack the register. 3 - i have a problem with my svn account I contacted Derek to help me solving it. As I said, thanks for mentioning that here as I didn't see the original message. In the future if you don't hear back from me within 24 hours you should try contacting me on IRC (or better yet, try IRC first!) The news ends here, :) Back to testplan running: you suggested some approach like Junit, I tried pyunit and it looks nice to me, do you have any issues regarding using it to organize our test cases. I dont, but keep in mind that right now we don't have different sets of test cases, there is only make check which runs EVERY test, and users can manually run specific tests by running make check TESTS=... where ... is the list of tests to run. In the end I'd sort of like to see the dogtail tests made a part of make check so that the self-test runs all the GUI tests too. So much of our code is GUI code that really make check doesn't test enough of our code. Just my opinion. Best regards, Ahmed Sayed -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: auto-save now with confirmation (was: 2.2.0 and auto-save)
On Sat, Jul 07, 2007 at 11:49:47AM +0200, Christian Stimming wrote: #4) (a refinement of #2) Leave auto-save enabled by default, but change the behavior slightly: - When autosave triggers prompt the user with: Implemented in r16256. Anyone with suggestions for improved wording? The current wording is: Title: Save file automatically? Text: (Your data file needs to be saved to your harddisk to save your changes. GnuCash has a feature to save the file automatically every %d minutes, just as if you had pressed the \Save\ button each time. \n\n You can change the time interval or turn off this feature under Edit - Preferences - General - Auto-save time interval. \n\n Should your file be saved automatically?), (_Yes, this time) (Yes, _always) (No, n_ever) (_No, not this time) The last button is the default one. Also, I added a checkbox in the preferences for showing this confirmation dialog again. I like it! Only change I'd make is add a space in harddisk. harddisk - hard disk --Beth Beth Leonard http://www.LeonardFamilyVideos.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
small doc patch
$ cd gnucash-docs-trunk $ svn diff Index: guide/C/ch_capgain.xml === --- guide/C/ch_capgain.xml (revision 16247) +++ guide/C/ch_capgain.xml (working copy) @@ -59,7 +59,7 @@ titleEstimating Valuation/title paraAs mentioned in the introduction to this chapter, capital gains are -the profits received from the same of an asset. This section will describe +the profits received from the sale of an asset. This section will describe how to record capital gains in GnuCash./para paraThe accounting methods for handling asset appreciation differs This email communication and any files transmitted with it may contain confidential and or proprietary information and is provided for the use of the intended recipient only. Any review, retransmission or dissemination of this information by anyone other than the intended recipient is prohibited. If you receive this email in error, please contact the sender and delete this communication and any copies immediately. Thank you. http://www.encana.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: small doc patch
Hale Boyes, Kevin [EMAIL PROTECTED] writes: $ cd gnucash-docs-trunk $ svn diff Index: guide/C/ch_capgain.xml === --- guide/C/ch_capgain.xml (revision 16247) +++ guide/C/ch_capgain.xml (working copy) @@ -59,7 +59,7 @@ titleEstimating Valuation/title paraAs mentioned in the introduction to this chapter, capital gains are -the profits received from the same of an asset. This section will describe +the profits received from the sale of an asset. This section will describe Applied r16259; thanks! (Attachments work better than in-lined patches, especially – as above – because of wrapping.) -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpOKT4utZc2j.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Licensing clarification, updates
Am Freitag, 6. Juli 2007 23:22 schrieb Josh Sled: As per http://svn.gnucash.org/trac/changeset/16254: I've summarized the state of the LICENSEing at the top of the file. Thanks, Josh, for adding this summary to the license text. Actually I'm wondering whether different copyrights are assigned on a per-file basis from a law point of view. I would have thought they are rather assigned on a per-contribution basis, which corresponds mainly to a per-contributer basis. If that is true, I'd rather suggest a summary like the following: * All source is licensed under GPLv2 * In addition to this, contributions by the following devs have the exception for linking against OpenSSL: jsled, cstim, ... * In addition to this, contributions by the following devs are licensed under GNU GPL, Version 2, or (at your option) any later version: cstim, ..., and all source code files that contain this clause. Also (or alternatively), couldn't we also say All contributions before [some date in the past] are licensed under GPLv2 or any later version? When thinking about the license on a per-contribution basis, I think the most precise wording could include the fact that you used to contribute code under GPLv2 or later, but then changed your mind at [some date in the past] and everything since then is GPLv2-only? Also, I think I'd be interested to license my contributions under (brand-new) GPLv3 in addition to the common GPLv2 license. I think this could be added in the LICENSE file by stating something like In addition to this, contributions by ..., cstim, ... are licensed under GPLv3 as well. Should something like this rather be avoided, or would that be fine? What do the others plan so far? I've added specific text for the OpenSSL exception as derived from http://en.wikipedia.org/wiki/Openssl#The_exception. I've added this text to files I have copyright on that do not include the or any later version text. Thanks. Err, do you think we could achieve the same effect by saying only ... yadda yadda GPLv2. For this program, the OpenSSL exception as noted in the LICENSE file is granted as well. If that would be sufficient, I think something along these lines avoids quite some text overhead :-) Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
