Re: Register2
Robert, Yet another option is to use gnucash' --extra switch. This is a runtime command line switch that is used to show some additional menu items in a menu called Extra. While developing you could move the actions related to Register2 to this menu and every user can test them simply by adding --extra to the gnucash command line. The added advantage is that your code will get compiled each time. This helps prevent bitrot. With a configure option your code will only get compiled if a developer explicitly enables the option. Geert On Wednesday 23 October 2013 14:12:36 Robert Fewell wrote: OK, I have worked out how to add a configure option to disable the register2 parts, will raise bug with patch later. Robert On 23 October 2013 11:41, Geert Janssens janssens-ge...@telenet.be wrote: ** On Tuesday 22 October 2013 12:49:57 John Ralls wrote: On Oct 22, 2013, at 11:34 AM, Geert Janssens janssens-ge...@telenet.be wrote: I do encourage you to get used to svn/git, and as John proposes, clone the gnucash repository on github. I'm not sure what would be the best starting point for a branch, r23314 (which you would revert immediately in your next commit), or r23313, which doesn't need any reverting. Both will cause some rebasing/merging issues eventually. Perhaps John has a better idea. In any case, it would be good if you regularly push your development branch in your github clone so other developers can follow your progress. On Oct 22, 2013, at 12:09 PM, Christian Stimming christ...@cstimming.de wrote: Just removing the code will almost surely introduce plenty of merging errors the next time any of us or you try to merge non-trivial changes from gnucash SVN. Basically, if you remove the code, it means you are going to maintain a private branch of gnucash SVN, not in any git or svn management, but just by keeping the changed files on your local harddisk. Out of the many available options of maintaining a separate branch (be it git somewhere or svn somewhere or whatever), this one is definitely the worst choice. I'd strongly suggest to create a configure switch instead, and keeping almost all code in SVN as well. Looks like Geert reverted the reversion patch. I was going to suggest that Robert branch after the reversion patch and immediately revert it in his branch: git revert 22eff28 Then he can rebase from trunk periodically git rebase trunk reg-2-branch to prevent bit-rot on his branch. I do this on my private feature branches, it works quite well. That approach is fine with me as well, but wouldn't that result in more merge conflicts as time goes by ? Hmm, I'll just stop reverting reversals and let Robert choose what he prefers. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Register2
Another thing I did not know about. I have added bug 710830 which adds a configure option --enable-register2 and with this set will compile Gnucash as is. If not enabled, default, Gnucash will look like before and operate the same way. There is also an option to use Gnucash with the --extra switch which adds some basic options to the Extensions menu, Open Account, Open Sub Account and GL for testing. I think I have correctly added the configure option but this may need changing. Was unsure about the number of #ifdef's but I think they are correct to achieve what is required. Regards. Robert On 24 October 2013 08:32, Geert Janssens janssens-ge...@telenet.be wrote: ** Robert, Yet another option is to use gnucash' --extra switch. This is a runtime command line switch that is used to show some additional menu items in a menu called Extra. While developing you could move the actions related to Register2 to this menu and every user can test them simply by adding --extra to the gnucash command line. The added advantage is that your code will get compiled each time. This helps prevent bitrot. With a configure option your code will only get compiled if a developer explicitly enables the option. Geert On Wednesday 23 October 2013 14:12:36 Robert Fewell wrote: OK, I have worked out how to add a configure option to disable the register2 parts, will raise bug with patch later. Robert On 23 October 2013 11:41, Geert Janssens janssens-ge...@telenet.be wrote: ** On Tuesday 22 October 2013 12:49:57 John Ralls wrote: On Oct 22, 2013, at 11:34 AM, Geert Janssens janssens-ge...@telenet.be wrote: I do encourage you to get used to svn/git, and as John proposes, clone the gnucash repository on github. I'm not sure what would be the best starting point for a branch, r23314 (which you would revert immediately in your next commit), or r23313, which doesn't need any reverting. Both will cause some rebasing/merging issues eventually. Perhaps John has a better idea. In any case, it would be good if you regularly push your development branch in your github clone so other developers can follow your progress. On Oct 22, 2013, at 12:09 PM, Christian Stimming christ...@cstimming.de wrote: Just removing the code will almost surely introduce plenty of merging errors the next time any of us or you try to merge non-trivial changes from gnucash SVN. Basically, if you remove the code, it means you are going to maintain a private branch of gnucash SVN, not in any git or svn management, but just by keeping the changed files on your local harddisk. Out of the many available options of maintaining a separate branch (be it git somewhere or svn somewhere or whatever), this one is definitely the worst choice. I'd strongly suggest to create a configure switch instead, and keeping almost all code in SVN as well. Looks like Geert reverted the reversion patch. I was going to suggest that Robert branch after the reversion patch and immediately revert it in his branch: git revert 22eff28 Then he can rebase from trunk periodically git rebase trunk reg-2-branch to prevent bit-rot on his branch. I do this on my private feature branches, it works quite well. That approach is fine with me as well, but wouldn't that result in more merge conflicts as time goes by ? Hmm, I'll just stop reverting reversals and let Robert choose what he prefers. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Register2
On Monday 21 October 2013 21:39:45 Robert Fewell wrote: I just thought it would be simpler, I must admit that I still do not really use SVN / GIT as it should, just the bit I need to get the source to my VM. Leaving it there would involve adding a load of idef's so I took the simpler option, may be I will go the git way and work out how to use that properly but in the mean time just removing it made sense to me.. Robert Robert, I have applied your reversing patch (r23314). I had to tweak the changes to dialog-preferences.glade because of my changes to that file in the previous commit, but that's not important. I do encourage you to get used to svn/git, and as John proposes, clone the gnucash repository on github. I'm not sure what would be the best starting point for a branch, r23314 (which you would revert immediately in your next commit), or r23313, which doesn't need any reverting. Both will cause some rebasing/merging issues eventually. Perhaps John has a better idea. In any case, it would be good if you regularly push your development branch in your github clone so other developers can follow your progress. Geert On 21 October 2013 21:15, Derek Atkins de...@ihtfp.com wrote: Is removing them necessarily the best option? Can they just be disabled (perhaps integrated by a configure script)? For example, I can imagine adding a --enable-register2 that would turn on the new register code integration points via an #ifdef REGISTER2_ENABLED in the code.. But the r2-specific files can be built always even if they aren't integrated. This would at least help make sure they don't bitrot, and would allonw people to continue working and testing the code in the interim. -derek On Mon, October 21, 2013 4:10 pm, Robert Fewell wrote: I have added a patch to bug 673193 to remove all new register2 files and amend existing files to restore the register back to the original setup. I will progress the register2 changes off line and try to resolve the existing open bugs. Regards, Robert On 14 October 2013 18:52, Geert Janssens janssens-ge...@telenet.be wrote: ** Hi Robert, Sorry to hear about your computer crash. I wish you good luck in restoring your working environment(s). Based on your feedback I propose to disable the register2 work for now to get 2.6 out of the door as planned in December. I seem to remember you were rather careful to keep the register2 code separate from the old code, so disabling should be a relatively simple matter, right ? On which road is best for the new register, I can't really comment. I have no experience at all with cairo, nor with the current register's internals. So I can't estimate which path would be the easiest/fastest, and much less so which one would be the best in the long run. Geert On Sunday 13 October 2013 10:47:19 Robert Fewell wrote: Guy's, I have had a bit of a disaster with my PC recently, I accidentally deleted six VM hard disks by mistake which were on an XFS file system partition. I have tried various programs to recover them, each being 10G - 40G but to no avail and the backup I did have was way out of date to be of use, must remember to do more regular backups. As a result, I need to rebuild these VM's before I can continue with the changes but two of them are more important to me than the one I use to build GnuCash on so it will probably take a couple of weeks before I get going again. Obviously I will need to remember / redo all the changes I had lined up which included getting the scrollbar back to one, fixed the crash on exit and some others I had sorted out partly. John's email beat mine, I do not wish to delay the release and would be happy if the changes were pulled as I am not sure how long it would be to get an acceptable register2 update. I would also like to ask if people think this register2 update is the way to go, there is still a lot of work to be done but all the elements are there OR scrap it and go down the rewrite what is there with cairo calls replacing the canvas stuff. Not sure how much work that would be, may be quicker or simpler ? Regards, Bob ___ 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
Re: Register2
Hi Robert, Thanks for picking up the work on the register2 again. Also thanks for the proposal for the next release. However, I strongly suggest *not* to remove the register2 code from SVN currently. Instead, any of us other developers can add a configure option or something similar easily. I'd expect to have maybe 6-8 places for an #ifdef, where the opening of the register2 windows was started, to have that redirected into the conventional register1. Just removing the code will almost surely introduce plenty of merging errors the next time any of us or you try to merge non-trivial changes from gnucash SVN. Basically, if you remove the code, it means you are going to maintain a private branch of gnucash SVN, not in any git or svn management, but just by keeping the changed files on your local harddisk. Out of the many available options of maintaining a separate branch (be it git somewhere or svn somewhere or whatever), this one is definitely the worst choice. I'd strongly suggest to create a configure switch instead, and keeping almost all code in SVN as well. We have plenty of such places throughout gnucash. It's surely not a problem for the project code base. Oh well, now that the patch is already in SVN, we need to revert this first to change this decision. Regards, Christian Am Montag, 21. Oktober 2013, 16:15:18 schrieb Derek Atkins: Is removing them necessarily the best option? Can they just be disabled (perhaps integrated by a configure script)? For example, I can imagine adding a --enable-register2 that would turn on the new register code integration points via an #ifdef REGISTER2_ENABLED in the code.. But the r2-specific files can be built always even if they aren't integrated. This would at least help make sure they don't bitrot, and would allonw people to continue working and testing the code in the interim. -derek On Mon, October 21, 2013 4:10 pm, Robert Fewell wrote: I have added a patch to bug 673193 to remove all new register2 files and amend existing files to restore the register back to the original setup. I will progress the register2 changes off line and try to resolve the existing open bugs. Regards, Robert On 14 October 2013 18:52, Geert Janssens janssens-ge...@telenet.be wrote: ** Hi Robert, Sorry to hear about your computer crash. I wish you good luck in restoring your working environment(s). Based on your feedback I propose to disable the register2 work for now to get 2.6 out of the door as planned in December. I seem to remember you were rather careful to keep the register2 code separate from the old code, so disabling should be a relatively simple matter, right ? On which road is best for the new register, I can't really comment. I have no experience at all with cairo, nor with the current register's internals. So I can't estimate which path would be the easiest/fastest, and much less so which one would be the best in the long run. Geert On Sunday 13 October 2013 10:47:19 Robert Fewell wrote: Guy's, I have had a bit of a disaster with my PC recently, I accidentally deleted six VM hard disks by mistake which were on an XFS file system partition. I have tried various programs to recover them, each being 10G - 40G but to no avail and the backup I did have was way out of date to be of use, must remember to do more regular backups. As a result, I need to rebuild these VM's before I can continue with the changes but two of them are more important to me than the one I use to build GnuCash on so it will probably take a couple of weeks before I get going again. Obviously I will need to remember / redo all the changes I had lined up which included getting the scrollbar back to one, fixed the crash on exit and some others I had sorted out partly. John's email beat mine, I do not wish to delay the release and would be happy if the changes were pulled as I am not sure how long it would be to get an acceptable register2 update. I would also like to ask if people think this register2 update is the way to go, there is still a lot of work to be done but all the elements are there OR scrap it and go down the rewrite what is there with cairo calls replacing the canvas stuff. Not sure how much work that would be, may be quicker or simpler ? Regards, Bob ___ 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: Register2
On Tuesday 22 October 2013 21:09:22 Christian Stimming wrote: Hi Robert, Thanks for picking up the work on the register2 again. Also thanks for the proposal for the next release. However, I strongly suggest *not* to remove the register2 code from SVN currently. Instead, any of us other developers can add a configure option or something similar easily. I'd expect to have maybe 6-8 places for an #ifdef, where the opening of the register2 windows was started, to have that redirected into the conventional register1. Just removing the code will almost surely introduce plenty of merging errors the next time any of us or you try to merge non-trivial changes from gnucash SVN. Basically, if you remove the code, it means you are going to maintain a private branch of gnucash SVN, not in any git or svn management, but just by keeping the changed files on your local harddisk. Out of the many available options of maintaining a separate branch (be it git somewhere or svn somewhere or whatever), this one is definitely the worst choice. I'd strongly suggest to create a configure switch instead, and keeping almost all code in SVN as well. We have plenty of such places throughout gnucash. It's surely not a problem for the project code base. Oh well, now that the patch is already in SVN, we need to revert this first to change this decision. Christian, I had my reservations as well, but considered it Robert's choice. I agree though that maintaining everything locally is the most difficult option. So I have reverted the patch. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Register2
On Oct 22, 2013, at 11:34 AM, Geert Janssens janssens-ge...@telenet.be wrote: I do encourage you to get used to svn/git, and as John proposes, clone the gnucash repository on github. I'm not sure what would be the best starting point for a branch, r23314 (which you would revert immediately in your next commit), or r23313, which doesn't need any reverting. Both will cause some rebasing/merging issues eventually. Perhaps John has a better idea. In any case, it would be good if you regularly push your development branch in your github clone so other developers can follow your progress. On Oct 22, 2013, at 12:09 PM, Christian Stimming christ...@cstimming.de wrote: Just removing the code will almost surely introduce plenty of merging errors the next time any of us or you try to merge non-trivial changes from gnucash SVN. Basically, if you remove the code, it means you are going to maintain a private branch of gnucash SVN, not in any git or svn management, but just by keeping the changed files on your local harddisk. Out of the many available options of maintaining a separate branch (be it git somewhere or svn somewhere or whatever), this one is definitely the worst choice. I'd strongly suggest to create a configure switch instead, and keeping almost all code in SVN as well. Looks like Geert reverted the reversion patch. I was going to suggest that Robert branch after the reversion patch and immediately revert it in his branch: git revert 22eff28 Then he can rebase from trunk periodically git rebase trunk reg-2-branch to prevent bit-rot on his branch. I do this on my private feature branches, it works quite well. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Register2
I am fine with what ever is best, mine was the simple solution which I knew how to do but if a configure option can be added then please do. Regards, Robert On 22 October 2013 20:49, John Ralls jra...@ceridwen.us wrote: On Oct 22, 2013, at 11:34 AM, Geert Janssens janssens-ge...@telenet.be wrote: I do encourage you to get used to svn/git, and as John proposes, clone the gnucash repository on github. I'm not sure what would be the best starting point for a branch, r23314 (which you would revert immediately in your next commit), or r23313, which doesn't need any reverting. Both will cause some rebasing/merging issues eventually. Perhaps John has a better idea. In any case, it would be good if you regularly push your development branch in your github clone so other developers can follow your progress. On Oct 22, 2013, at 12:09 PM, Christian Stimming christ...@cstimming.de wrote: Just removing the code will almost surely introduce plenty of merging errors the next time any of us or you try to merge non-trivial changes from gnucash SVN. Basically, if you remove the code, it means you are going to maintain a private branch of gnucash SVN, not in any git or svn management, but just by keeping the changed files on your local harddisk. Out of the many available options of maintaining a separate branch (be it git somewhere or svn somewhere or whatever), this one is definitely the worst choice. I'd strongly suggest to create a configure switch instead, and keeping almost all code in SVN as well. Looks like Geert reverted the reversion patch. I was going to suggest that Robert branch after the reversion patch and immediately revert it in his branch: git revert 22eff28 Then he can rebase from trunk periodically git rebase trunk reg-2-branch to prevent bit-rot on his branch. I do this on my private feature branches, it works quite well. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Register2
I have added a patch to bug 673193 to remove all new register2 files and amend existing files to restore the register back to the original setup. I will progress the register2 changes off line and try to resolve the existing open bugs. Regards, Robert On 14 October 2013 18:52, Geert Janssens janssens-ge...@telenet.be wrote: ** Hi Robert, Sorry to hear about your computer crash. I wish you good luck in restoring your working environment(s). Based on your feedback I propose to disable the register2 work for now to get 2.6 out of the door as planned in December. I seem to remember you were rather careful to keep the register2 code separate from the old code, so disabling should be a relatively simple matter, right ? On which road is best for the new register, I can't really comment. I have no experience at all with cairo, nor with the current register's internals. So I can't estimate which path would be the easiest/fastest, and much less so which one would be the best in the long run. Geert On Sunday 13 October 2013 10:47:19 Robert Fewell wrote: Guy's, I have had a bit of a disaster with my PC recently, I accidentally deleted six VM hard disks by mistake which were on an XFS file system partition. I have tried various programs to recover them, each being 10G - 40G but to no avail and the backup I did have was way out of date to be of use, must remember to do more regular backups. As a result, I need to rebuild these VM's before I can continue with the changes but two of them are more important to me than the one I use to build GnuCash on so it will probably take a couple of weeks before I get going again. Obviously I will need to remember / redo all the changes I had lined up which included getting the scrollbar back to one, fixed the crash on exit and some others I had sorted out partly. John's email beat mine, I do not wish to delay the release and would be happy if the changes were pulled as I am not sure how long it would be to get an acceptable register2 update. I would also like to ask if people think this register2 update is the way to go, there is still a lot of work to be done but all the elements are there OR scrap it and go down the rewrite what is there with cairo calls replacing the canvas stuff. Not sure how much work that would be, may be quicker or simpler ? Regards, Bob ___ 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: Register2
Is removing them necessarily the best option? Can they just be disabled (perhaps integrated by a configure script)? For example, I can imagine adding a --enable-register2 that would turn on the new register code integration points via an #ifdef REGISTER2_ENABLED in the code.. But the r2-specific files can be built always even if they aren't integrated. This would at least help make sure they don't bitrot, and would allonw people to continue working and testing the code in the interim. -derek On Mon, October 21, 2013 4:10 pm, Robert Fewell wrote: I have added a patch to bug 673193 to remove all new register2 files and amend existing files to restore the register back to the original setup. I will progress the register2 changes off line and try to resolve the existing open bugs. Regards, Robert On 14 October 2013 18:52, Geert Janssens janssens-ge...@telenet.be wrote: ** Hi Robert, Sorry to hear about your computer crash. I wish you good luck in restoring your working environment(s). Based on your feedback I propose to disable the register2 work for now to get 2.6 out of the door as planned in December. I seem to remember you were rather careful to keep the register2 code separate from the old code, so disabling should be a relatively simple matter, right ? On which road is best for the new register, I can't really comment. I have no experience at all with cairo, nor with the current register's internals. So I can't estimate which path would be the easiest/fastest, and much less so which one would be the best in the long run. Geert On Sunday 13 October 2013 10:47:19 Robert Fewell wrote: Guy's, I have had a bit of a disaster with my PC recently, I accidentally deleted six VM hard disks by mistake which were on an XFS file system partition. I have tried various programs to recover them, each being 10G - 40G but to no avail and the backup I did have was way out of date to be of use, must remember to do more regular backups. As a result, I need to rebuild these VM's before I can continue with the changes but two of them are more important to me than the one I use to build GnuCash on so it will probably take a couple of weeks before I get going again. Obviously I will need to remember / redo all the changes I had lined up which included getting the scrollbar back to one, fixed the crash on exit and some others I had sorted out partly. John's email beat mine, I do not wish to delay the release and would be happy if the changes were pulled as I am not sure how long it would be to get an acceptable register2 update. I would also like to ask if people think this register2 update is the way to go, there is still a lot of work to be done but all the elements are there OR scrap it and go down the rewrite what is there with cairo calls replacing the canvas stuff. Not sure how much work that would be, may be quicker or simpler ? Regards, Bob ___ 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 -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Register2
On Oct 21, 2013, at 1:10 PM, Robert Fewell 14ubo...@gmail.com wrote: I have added a patch to bug 673193 to remove all new register2 files and amend existing files to restore the register back to the original setup. I will progress the register2 changes off line and try to resolve the existing open bugs. Robert, Glad you've gotten your computer sorted. Are you sure you want to blow everything away rather than take Geert's suggestion to disable it with a configure option? If you're sure about that, would it help for you to have a branch in SVN so that other devs can build and test your work? We can make the branch before applying the reversion patch so that we won't be re-applying all of those earlier patches when you've got your fix-ups completed. There's an alternative as well: You can create an account on Github, clone the Gnucash repo, and create a branch there that you can push to at will. Regards, John Ralls On 14 October 2013 18:52, Geert Janssens janssens-ge...@telenet.be wrote: ** Hi Robert, Sorry to hear about your computer crash. I wish you good luck in restoring your working environment(s). Based on your feedback I propose to disable the register2 work for now to get 2.6 out of the door as planned in December. I seem to remember you were rather careful to keep the register2 code separate from the old code, so disabling should be a relatively simple matter, right ? On which road is best for the new register, I can't really comment. I have no experience at all with cairo, nor with the current register's internals. So I can't estimate which path would be the easiest/fastest, and much less so which one would be the best in the long run. Geert On Sunday 13 October 2013 10:47:19 Robert Fewell wrote: Guy's, I have had a bit of a disaster with my PC recently, I accidentally deleted six VM hard disks by mistake which were on an XFS file system partition. I have tried various programs to recover them, each being 10G - 40G but to no avail and the backup I did have was way out of date to be of use, must remember to do more regular backups. As a result, I need to rebuild these VM's before I can continue with the changes but two of them are more important to me than the one I use to build GnuCash on so it will probably take a couple of weeks before I get going again. Obviously I will need to remember / redo all the changes I had lined up which included getting the scrollbar back to one, fixed the crash on exit and some others I had sorted out partly. John's email beat mine, I do not wish to delay the release and would be happy if the changes were pulled as I am not sure how long it would be to get an acceptable register2 update. I would also like to ask if people think this register2 update is the way to go, there is still a lot of work to be done but all the elements are there OR scrap it and go down the rewrite what is there with cairo calls replacing the canvas stuff. Not sure how much work that would be, may be quicker or simpler ? Regards, Bob ___ 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Register2
Hi Robert, Sorry to hear about your computer crash. I wish you good luck in restoring your working environment(s). Based on your feedback I propose to disable the register2 work for now to get 2.6 out of the door as planned in December. I seem to remember you were rather careful to keep the register2 code separate from the old code, so disabling should be a relatively simple matter, right ? On which road is best for the new register, I can't really comment. I have no experience at all with cairo, nor with the current register's internals. So I can't estimate which path would be the easiest/fastest, and much less so which one would be the best in the long run. Geert On Sunday 13 October 2013 10:47:19 Robert Fewell wrote: Guy's, I have had a bit of a disaster with my PC recently, I accidentally deleted six VM hard disks by mistake which were on an XFS file system partition. I have tried various programs to recover them, each being 10G - 40G but to no avail and the backup I did have was way out of date to be of use, must remember to do more regular backups. As a result, I need to rebuild these VM's before I can continue with the changes but two of them are more important to me than the one I use to build GnuCash on so it will probably take a couple of weeks before I get going again. Obviously I will need to remember / redo all the changes I had lined up which included getting the scrollbar back to one, fixed the crash on exit and some others I had sorted out partly. John's email beat mine, I do not wish to delay the release and would be happy if the changes were pulled as I am not sure how long it would be to get an acceptable register2 update. I would also like to ask if people think this register2 update is the way to go, there is still a lot of work to be done but all the elements are there OR scrap it and go down the rewrite what is there with cairo calls replacing the canvas stuff. Not sure how much work that would be, may be quicker or simpler ? Regards, Bob ___ 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: Register2
On Saturday 12 October 2013 15:36:10 John Ralls wrote: I went searched bugzilla for bugs that mention register2 either in the title or a comment. For the ones which are clearly register2 problems I changed the category to a new one, Register2, and made them blockers on 673193, the original register2 bug. There are 17. There are 4 crashers. It's not a bug, but the widely derided double scrollbar is still there as well. This isn't shippable, and we were planning to release 2.6 in December. AFAICT no work has been done on Reg2 since the beginning of August. Do we rip it out or push back the release? Robert gave you the answer I think. I think we should disable the Register2 code (I suppose that's what you meant with rip it out) until he's ready to continue on it, or someone else steps up to work on it. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Register2
On Oct 14, 2013, at 10:54 AM, Geert Janssens janssens-ge...@telenet.be wrote: On Saturday 12 October 2013 15:36:10 John Ralls wrote: I went searched bugzilla for bugs that mention register2 either in the title or a comment. For the ones which are clearly register2 problems I changed the category to a new one, Register2, and made them blockers on 673193, the original register2 bug. There are 17. There are 4 crashers. It's not a bug, but the widely derided double scrollbar is still there as well. This isn't shippable, and we were planning to release 2.6 in December. AFAICT no work has been done on Reg2 since the beginning of August. Do we rip it out or push back the release? Robert gave you the answer I think. Yeah. I think we should disable the Register2 code (I suppose that's what you meant with rip it out) until he's ready to continue on it, or someone else steps up to work on it. No, by rip it out, I meant branch and then revert the patches in trunk. But wrapping it all in a configure option would be OK, too, as long as Robert can get back to working on it before bit-rot sets in. I did a little research yesterday on replacing libgnomecanvas. There's a replacement library called goocanvas [1] that's actively maintained, works with Gtk3, and is somewhat similar to libgnomecanvas. I think that's better than rewriting to cairo, which is pretty low-level. Regards, John Ralls [1] https://developer.gnome.org/goocanvas/stable/ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Register2
Guy's, I have had a bit of a disaster with my PC recently, I accidentally deleted six VM hard disks by mistake which were on an XFS file system partition. I have tried various programs to recover them, each being 10G - 40G but to no avail and the backup I did have was way out of date to be of use, must remember to do more regular backups. As a result, I need to rebuild these VM's before I can continue with the changes but two of them are more important to me than the one I use to build GnuCash on so it will probably take a couple of weeks before I get going again. Obviously I will need to remember / redo all the changes I had lined up which included getting the scrollbar back to one, fixed the crash on exit and some others I had sorted out partly. John's email beat mine, I do not wish to delay the release and would be happy if the changes were pulled as I am not sure how long it would be to get an acceptable register2 update. I would also like to ask if people think this register2 update is the way to go, there is still a lot of work to be done but all the elements are there OR scrap it and go down the rewrite what is there with cairo calls replacing the canvas stuff. Not sure how much work that would be, may be quicker or simpler ? Regards, Bob ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Register2
I went searched bugzilla for bugs that mention register2 either in the title or a comment. For the ones which are clearly register2 problems I changed the category to a new one, Register2, and made them blockers on 673193, the original register2 bug. There are 17. There are 4 crashers. It's not a bug, but the widely derided double scrollbar is still there as well. This isn't shippable, and we were planning to release 2.6 in December. AFAICT no work has been done on Reg2 since the beginning of August. Do we rip it out or push back the release? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
