Re: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)
Op 24-02-13 00:23, Mike Alexander schreef: --On February 23, 2013 5:07:47 PM +0100 Christian Stimming christ...@cstimming.de wrote: I think the easiest way out here (as long as we're still using SVN) is to set the per-file SVN property svn:eol-style to some fixed value (here: LF). This ensures the file get one canonical set of eol markers. However, setting this property requires a client-side action: Either the file ~/.subversion/config needs some manual changes as described here http://stackoverflow.com/questions/5671406/force-svneol-style-native- on- the-server which sets the property at the initial checkin of each file, or we need to do one additional SVN commit to set that property, which I've just done in r22809. Note: For most of our *.h / *.c files I've also done this manually in e.g. r20217 or r18959, which explains why we didn't have any trouble with those files and line endings. I strongly suggest for every developer to modify one's own ~/.subversion/config to set svn:eol-style=LF for *.h, *.c so that we continue with a consistent setting of the line endings. Do you really want to use LF for eol-style for these file types? I would think that native would work better. That's what I've been using for years on various SVN projects and it seems to work well. I don't work on Windows much anymore, but I used to and often worked on the same file on both systems. Native is also what the stackoverflow article you mention suggests. If you specify this eol format then the local file will be in the native format but the repository version will always be with LF line endings. For a discussion of the eol-style property see http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style. Mike ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel Mike, At first sight it would make sense indeed to set native eol style on files, so that native files don't get confused. The key to our decision to use the LF EOL style lies in the same requirement: make sure native tools don't get confused. If you are now confused, let me explain: GnuCash is a program that originated on linux. The Windows build was added much later. This Windows build uses the same toolchain as on linux, but ported to Windows (autotools + gcc roughly). And even though this all runs on Windows natively, internally it shows these tools originally were written for linux. And one of the issues with these tools is that they are not completely EOL style agnostic. Mostly, but not completely. Over the years this has popped up in various small corner cases breaking the build. My most recent issue I remember was with the AC_CONFIG_FILES macro in configure.ac. For readability I had inserted some empty lines in there. Worked perfectly on linux, but caused the build to fail on Windows (before I fixed the EOL issue in git). Clearly on Windows the line was no longer considered an empty line, but a line containing one character CR. Forcing a line-ending style of LF on these files fixed the problem. Like that there are several small corner cases that tend to bite you when you least expect it. To avoid these tool chain hickups, we decided to force a line ending style we know to make the build work. As you can see this is a totally different motivation than the svn article, which is only concerned about checking in lots of EOL differences. That is important as well, and is equally taken care of by our policy. To be completely fair, it may not be necessary for *all* files to force a checked out line ending style. Only the ones that are known to potentially cause issues, or more broadly those files that have to be processed by a tool before distribution (like source files that have to be compiled, template files that are processed with sed or perl,...). In that sense the javascript files may not have required a force EOL style. It has become a habit though to do so to prevent any unexpected things to happen in the future. The only disadvantage of our chosen EOL style I see on Windows is that Notepad doesn't handle the files properly. Any other Windows text editor I have used to process the gnucash code handles the EOL's just fine. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)
Op 23-02-13 17:07, Christian Stimming schreef: Am Samstag, 23. Februar 2013, 11:57:18 schrieb Geert Janssens: Additionally, can you check if the eol attribute is already supported in your git version ? It is mentioned in man gitattributes on my system and is the attribute I'm using to force consistent line endings. It may be a more recent addition. I think the easiest way out here (as long as we're still using SVN) is to set the per-file SVN property svn:eol-style to some fixed value (here: LF). This ensures the file get one canonical set of eol markers. However, setting this property requires a client-side action: Either the file ~/.subversion/config needs some manual changes as described here http://stackoverflow.com/questions/5671406/force-svneol-style-native-on- the-server which sets the property at the initial checkin of each file, or we need to do one additional SVN commit to set that property, which I've just done in r22809. Note: For most of our *.h / *.c files I've also done this manually in e.g. r20217 or r18959, which explains why we didn't have any trouble with those files and line endings. I strongly suggest for every developer to modify one's own ~/.subversion/config to set svn:eol-style=LF for *.h, *.c so that we continue with a consistent setting of the line endings. As for git: The gitattributes feature is probably the most closely matching feature of git, related to the svn:eol-style property. Once git-1.8 has been distributed widely enough, we probably will have this problem solved with git's gitattributes file on the git side as well. Until then, we should probably keep an eye on setting svn:eol-style correctly. Regards, Christian You are not saying this explicitly, but should I conclude from your explanation that the .gitattributes file is new in git-1.8 ? I thought it was introduced in git 1.7.2 [1]. But if it was later, that certainly would explain why it worked on my system and not on Mike's or John's. Geert [1] At least that's what Tim Clem claims in his blog :http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)
Am Sonntag, 24. Februar 2013, 10:21:00 schrieb Geert Janssens: As for git: The gitattributes feature is probably the most closely matching feature of git, related to the svn:eol-style property. Once git-1.8 has been distributed widely enough, we probably will have this problem solved with git's gitattributes file on the git side as well. Until then, we should probably keep an eye on setting svn:eol-style correctly. Regards, Christian You are not saying this explicitly, but should I conclude from your explanation that the .gitattributes file is new in git-1.8 ? I thought it was introduced in git 1.7.2 [1]. But if it was later, that certainly would explain why it worked on my system and not on Mike's or John's. Sorry, I don't know. But as the feature is still relatively new (and I'm sure this feature was not yet available 1-2 years ago), I think it's safe to assume newer git version are still introducing additional flavours of that feature. That's why I would also assume your mismatch between Mike's and your system might be caused by the different git versions. Christian Geert [1] At least that's what Tim Clem claims in his blog :http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)
Am Samstag, 23. Februar 2013, 18:23:13 schrieb Mike Alexander: I think the easiest way out here (as long as we're still using SVN) is to set the per-file SVN property svn:eol-style to some fixed value (here: LF). This ensures the file get one canonical set of eol markers. Do you really want to use LF for eol-style for these file types? I would think that native would work better. That's what I've been using for years on various SVN projects and it seems to work well. I don't work on Windows much anymore, but I used to and often worked on the same file on both systems. Native is also what the stackoverflow article you mention suggests. If you specify this eol format then the local file will be in the native format but the repository version will always be with LF line endings. Yes, I do really want to set a deterministic eol-style instead of choosing the somewhat non-deterministic native style here. Think of it: We decide on one style, but with native you still say well, depending on the OS you're looking at SVN, the files will end up this or that way. Not what I would call deterministic. I have one specific use case where native really fails: Some co-workers and me regularly work with a dual-boot machine that runs either Linux or Windows, but uses a SVN checkout on the same partition. With eol-style=native, the files in the identical working copy end up differently depending on the last OS I've used to work with the working copy. In that (admittantly pecurliar) case, one specific eol-style (LF or CRLF) works but eol-style=native does not work. On the other hand, there were times when eol-style=native was necessary: Earlier windows compilers would refuse to compile source code that did not have CRLF line endings. For Microsoft Visual Studio, this was no longer the case with at least MSVC 2005 (but I've encountered other cross-platform IDEs on windows that would still require CRLF line endings). If such a compiler is in the set of target platforms, then yes, using eol-style=native or CRLF is better. But as this is not the case for our today's gnucash, we simply stick to LF and can be sure the files will look the same regardless which OS ran the checkout. Regards, Christian For a discussion of the eol-style property see http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html #svn.advanced.props.special.eol-style. Mike ___ 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: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)
Op 24-02-13 10:46, Christian Stimming schreef: Am Samstag, 23. Februar 2013, 18:23:13 schrieb Mike Alexander: I think the easiest way out here (as long as we're still using SVN) is to set the per-file SVN property svn:eol-style to some fixed value (here: LF). This ensures the file get one canonical set of eol markers. Do you really want to use LF for eol-style for these file types? I would think that native would work better. That's what I've been using for years on various SVN projects and it seems to work well. I don't work on Windows much anymore, but I used to and often worked on the same file on both systems. Native is also what the stackoverflow article you mention suggests. If you specify this eol format then the local file will be in the native format but the repository version will always be with LF line endings. Yes, I do really want to set a deterministic eol-style instead of choosing the somewhat non-deterministic native style here. Think of it: We decide on one style, but with native you still say well, depending on the OS you're looking at SVN, the files will end up this or that way. Not what I would call deterministic. I have one specific use case where native really fails: Some co-workers and me regularly work with a dual-boot machine that runs either Linux or Windows, but uses a SVN checkout on the same partition. With eol-style=native, the files in the identical working copy end up differently depending on the last OS I've used to work with the working copy. In that (admittantly pecurliar) case, one specific eol-style (LF or CRLF) works but eol-style=native does not work. I had not mentioned this in my reply, but I have a similar setup. Not dual boot, but a primary linux machine and a Windows installation in a VM, sharing a common directory. This worked fine as long as I was working with svn (because we had explicitly set the EOL styles already). Once I switched to git I started running into several EOL issues again, which prompted me to write the .gitattributes file to match the svn config. Recently I have moved away from the shared directory approach though. Now I use my linux repo as upstream repo for a dedicated repo for the Windows build. The disadvantage with this is that I have to check in anything I changed on the linux side before I can test in on the Windows side, but it's a minor inconvenience. On the other hand, there were times when eol-style=native was necessary: Earlier windows compilers would refuse to compile source code that did not have CRLF line endings. For Microsoft Visual Studio, this was no longer the case with at least MSVC 2005 (but I've encountered other cross-platform IDEs on windows that would still require CRLF line endings). If such a compiler is in the set of target platforms, then yes, using eol-style=native or CRLF is better. This is also why some of the files in the win32 directory are marked explicitly for CRLF EOL style. The inno setup compiler is one of those tools that has issues with LF only EOL style. And for safety we also mark all windows native scripts as CRLF (.BAT and friends). I seem to remember them also behaving oddly when they used LF EOL. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)
Op 23-02-13 05:52, John Ralls schreef: On Feb 22, 2013, at 11:14 AM, Geert Janssens janssens-ge...@telenet.be wrote: Op 22-02-13 19:45, Geert Janssens schreef: Op 22-02-13 19:23, Mike Evans schreef: Thanks for checking Geert. I removed my $HOME/.gitconfig and tried again with the same result. My git version is 1.7.6.5 on Fedora 15 not sure it that makes any difference. Anyway now we know where the problem is (me) I know the solution is local. Enough for today though I think. My git version is git-1.8.1.2-1.fc18.i686 on Fedora 18. I don't know if that makes a difference or not. What exact url are you using to clone from github ? Mine is g...@github.com:Gnucash/gnucash.git Any other devs seeing this ? Geert Additionally, can you check if the eol attribute is already supported in your git version ? It is mentioned in man gitattributes on my system and is the attribute I'm using to force consistent line endings. It may be a more recent addition. Yeah, I see it on OSX. When I follow the renormalizing procedure, I get warning: CRLF will be replaced by LF in src/report/jqplot/foo.js. The file will have its original line endings in your working directory. For all of the files that Mike listed. Curiously, changing the *.js entry in .gitattributes to crlf and repeating the procedure has no effect. It appears that you got those js files into the repo with crlf line endings. git version 1.7.9.6 (Apple Git-31.1) The eol attribute is documented in gitattributes(5) Regards, John Ralls Ok, that is very likely. Can you or Mike check in the proper conversions ? They don't show up on my system (which I don't understand why that is). Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)
On Sat, 23 Feb 2013 10:19:25 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 23-02-13 05:52, John Ralls schreef: On Feb 22, 2013, at 11:14 AM, Geert Janssens janssens-ge...@telenet.be wrote: Op 22-02-13 19:45, Geert Janssens schreef: Op 22-02-13 19:23, Mike Evans schreef: Thanks for checking Geert. I removed my $HOME/.gitconfig and tried again with the same result. My git version is 1.7.6.5 on Fedora 15 not sure it that makes any difference. Anyway now we know where the problem is (me) I know the solution is local. Enough for today though I think. My git version is git-1.8.1.2-1.fc18.i686 on Fedora 18. I don't know if that makes a difference or not. What exact url are you using to clone from github ? Mine is g...@github.com:Gnucash/gnucash.git Any other devs seeing this ? Geert Additionally, can you check if the eol attribute is already supported in your git version ? It is mentioned in man gitattributes on my system and is the attribute I'm using to force consistent line endings. It may be a more recent addition. Yeah, I see it on OSX. When I follow the renormalizing procedure, I get warning: CRLF will be replaced by LF in src/report/jqplot/foo.js. The file will have its original line endings in your working directory. For all of the files that Mike listed. Curiously, changing the *.js entry in .gitattributes to crlf and repeating the procedure has no effect. It appears that you got those js files into the repo with crlf line endings. git version 1.7.9.6 (Apple Git-31.1) The eol attribute is documented in gitattributes(5) Regards, John Ralls Ok, that is very likely. Can you or Mike check in the proper conversions ? They don't show up on my system (which I don't understand why that is). Geert OK checked in as r22808 4317a28b55655 Mike E -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)
Op 23-02-13 11:35, Mike Evans schreef: On Sat, 23 Feb 2013 10:19:25 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 23-02-13 05:52, John Ralls schreef: On Feb 22, 2013, at 11:14 AM, Geert Janssens janssens-ge...@telenet.be wrote: Op 22-02-13 19:45, Geert Janssens schreef: Op 22-02-13 19:23, Mike Evans schreef: Thanks for checking Geert. I removed my $HOME/.gitconfig and tried again with the same result. My git version is 1.7.6.5 on Fedora 15 not sure it that makes any difference. Anyway now we know where the problem is (me) I know the solution is local. Enough for today though I think. My git version is git-1.8.1.2-1.fc18.i686 on Fedora 18. I don't know if that makes a difference or not. What exact url are you using to clone from github ? Mine is g...@github.com:Gnucash/gnucash.git Any other devs seeing this ? Geert Additionally, can you check if the eol attribute is already supported in your git version ? It is mentioned in man gitattributes on my system and is the attribute I'm using to force consistent line endings. It may be a more recent addition. Yeah, I see it on OSX. When I follow the renormalizing procedure, I get warning: CRLF will be replaced by LF in src/report/jqplot/foo.js. The file will have its original line endings in your working directory. For all of the files that Mike listed. Curiously, changing the *.js entry in .gitattributes to crlf and repeating the procedure has no effect. It appears that you got those js files into the repo with crlf line endings. git version 1.7.9.6 (Apple Git-31.1) The eol attribute is documented in gitattributes(5) Regards, John Ralls Ok, that is very likely. Can you or Mike check in the proper conversions ? They don't show up on my system (which I don't understand why that is). Geert OK checked in as r22808 4317a28b55655 Mike E Thanks. Git is still happy on my system with the new commit and after renormalizing. So hopefully we fixed it properly this time. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)
Am Samstag, 23. Februar 2013, 11:57:18 schrieb Geert Janssens: Additionally, can you check if the eol attribute is already supported in your git version ? It is mentioned in man gitattributes on my system and is the attribute I'm using to force consistent line endings. It may be a more recent addition. I think the easiest way out here (as long as we're still using SVN) is to set the per-file SVN property svn:eol-style to some fixed value (here: LF). This ensures the file get one canonical set of eol markers. However, setting this property requires a client-side action: Either the file ~/.subversion/config needs some manual changes as described here http://stackoverflow.com/questions/5671406/force-svneol-style-native-on- the-server which sets the property at the initial checkin of each file, or we need to do one additional SVN commit to set that property, which I've just done in r22809. Note: For most of our *.h / *.c files I've also done this manually in e.g. r20217 or r18959, which explains why we didn't have any trouble with those files and line endings. I strongly suggest for every developer to modify one's own ~/.subversion/config to set svn:eol-style=LF for *.h, *.c so that we continue with a consistent setting of the line endings. As for git: The gitattributes feature is probably the most closely matching feature of git, related to the svn:eol-style property. Once git-1.8 has been distributed widely enough, we probably will have this problem solved with git's gitattributes file on the git side as well. Until then, we should probably keep an eye on setting svn:eol-style correctly. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)
--On February 23, 2013 5:07:47 PM +0100 Christian Stimming christ...@cstimming.de wrote: I think the easiest way out here (as long as we're still using SVN) is to set the per-file SVN property svn:eol-style to some fixed value (here: LF). This ensures the file get one canonical set of eol markers. However, setting this property requires a client-side action: Either the file ~/.subversion/config needs some manual changes as described here http://stackoverflow.com/questions/5671406/force-svneol-style-native- on- the-server which sets the property at the initial checkin of each file, or we need to do one additional SVN commit to set that property, which I've just done in r22809. Note: For most of our *.h / *.c files I've also done this manually in e.g. r20217 or r18959, which explains why we didn't have any trouble with those files and line endings. I strongly suggest for every developer to modify one's own ~/.subversion/config to set svn:eol-style=LF for *.h, *.c so that we continue with a consistent setting of the line endings. Do you really want to use LF for eol-style for these file types? I would think that native would work better. That's what I've been using for years on various SVN projects and it seems to work well. I don't work on Windows much anymore, but I used to and often worked on the same file on both systems. Native is also what the stackoverflow article you mention suggests. If you specify this eol format then the local file will be in the native format but the repository version will always be with LF line endings. For a discussion of the eol-style property see http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style. Mike ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
On Thu, 21 Feb 2013 18:55:31 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 18:19, Mike Evans schreef: On Thu, 21 Feb 2013 18:04:37 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 16:54, Mike Evans schreef: A git|svn|brain issue follows. Having updated to the latest source using git-update script I can't change branches because some of the files have the wrong line endings, unless I commit the changes. I get this message: Please, commit your changes or stash them before you can switch branches. Git stash doesn't work and I get similar output to that shown below. A git diff gives the following output. warning: CRLF will be replaced by LF in src/report/jqplot/excanvas.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/jquery.jqplot.min.js. The file will have its original line endings in your working directory. SNIP src/report/jqplot/plugins/jqplot.ciParser.min.js. The file will have its original line endings in your working directory. diff --git src/report/jqplot/excanvas.min.js src/report/jqplot/excanvas.min.js index 83373a5..e699a26 100644 --- src/report/jqplot/excanvas.min.js +++ src/report/jqplot/excanvas.min.js @@ -1,3 +1,3 @@ -/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com - jsDate | (c) 2010-2013 Chris Leonello +/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com + jsDate | (c) 2010-2013 Chris Leonello Um. Not sure what to do or why this situation occurred in the first place. I thought git took care of line ending translations. I can commmit locally then dcommit but is that going to screw it up for anyone else? Advice needed. My love/hate relationship with GIT continues. Mike Evans Mike, These happen because the git configuration didn't have a definition for the line ending style for javascript files (.js). While working on the charts I added this definition. Some files that were already in git before now are checked out with different line endings. Can you try to run git checkout src/report/jqplot/*.js git checkout src/report/jqplot/plugins/*.js Does that fix the issue ? Geert Hi Geert Afraid not. Can I modify my config file manually? What do I add|change if so? Mike E It looks like the solution needs slightly more work. Read the part Re-normalizing a repo on this page: https://help.github.com/articles/dealing-with-line-endings Be sure to commit or stash your real changes before following this procedure. If at the end there are still files complaining about CRLF vs LF, you commit those. That would mean I have messed up in my commit. Geert Hi Geert After doing that and making things somewhat worse, that is, getting even more files with line ending issues I git cloned a fresh copy of gnucash from GitHub. A git status gives me: # On branch trunk # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: src/report/jqplot/excanvas.min.js # modified: src/report/jqplot/jquery.jqplot.min.js # modified: src/report/jqplot/plugins/jqplot.BezierCurveRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.barRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.blockRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.bubbleRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasAxisLabelRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasAxisTickRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasOverlay.min.js # modified: src/report/jqplot/plugins/jqplot.canvasTextRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.categoryAxisRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.ciParser.min.js # Same files with line ending issues, but at least no warnings. It can't be just me surely? Although sometimes it seems to be :) Mike Evans -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
Op 21-02-13 20:53, Christian Stimming schreef: Am Donnerstag, 21. Februar 2013, 17:57:30 schrieb Geert Janssens: Op 21-02-13 12:47, Geert Janssens schreef: Well, it turns out I was too curious myself already, so I checked a bit further. ... And a random list of things that should/could be done still: - remove the gog code (should) I have removed the goffice/gog dependencies in our html/webkit code. Great! Thanks for the jqplot and throwing out of the gog plot. Unfortunately we're still stuck with goffice, because the CSV/Fixed-width indirectly depends on it (it uses code from lib/stf/ which is depending on goffice). Well, the CSV importer might use a rewrite as well, but currently we have to live with that. However, I get a compile error after your r22799, ../../../src/gnome-utils/gnc-gnome-utils.c:31:26: fatal error: libxml/xmlIO.h: No such file or directory compilation terminated. make[4]: *** [gnc-gnome-utils.lo] Error 1 make[4]: Leaving directory `/home/cs/org/gnucash/git/trunk/build/src/gnome- utils' Regards, Christian This should be fixed as of r22804. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
Op 22-02-13 14:43, Mike Evans schreef: On Thu, 21 Feb 2013 18:55:31 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 18:19, Mike Evans schreef: On Thu, 21 Feb 2013 18:04:37 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 16:54, Mike Evans schreef: A git|svn|brain issue follows. Having updated to the latest source using git-update script I can't change branches because some of the files have the wrong line endings, unless I commit the changes. I get this message: Please, commit your changes or stash them before you can switch branches. Git stash doesn't work and I get similar output to that shown below. A git diff gives the following output. warning: CRLF will be replaced by LF in src/report/jqplot/excanvas.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/jquery.jqplot.min.js. The file will have its original line endings in your working directory. SNIP src/report/jqplot/plugins/jqplot.ciParser.min.js. The file will have its original line endings in your working directory. diff --git src/report/jqplot/excanvas.min.js src/report/jqplot/excanvas.min.js index 83373a5..e699a26 100644 --- src/report/jqplot/excanvas.min.js +++ src/report/jqplot/excanvas.min.js @@ -1,3 +1,3 @@ -/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com - jsDate | (c) 2010-2013 Chris Leonello +/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com + jsDate | (c) 2010-2013 Chris Leonello Um. Not sure what to do or why this situation occurred in the first place. I thought git took care of line ending translations. I can commmit locally then dcommit but is that going to screw it up for anyone else? Advice needed. My love/hate relationship with GIT continues. Mike Evans Mike, These happen because the git configuration didn't have a definition for the line ending style for javascript files (.js). While working on the charts I added this definition. Some files that were already in git before now are checked out with different line endings. Can you try to run git checkout src/report/jqplot/*.js git checkout src/report/jqplot/plugins/*.js Does that fix the issue ? Geert Hi Geert Afraid not. Can I modify my config file manually? What do I add|change if so? Mike E It looks like the solution needs slightly more work. Read the part Re-normalizing a repo on this page: https://help.github.com/articles/dealing-with-line-endings Be sure to commit or stash your real changes before following this procedure. If at the end there are still files complaining about CRLF vs LF, you commit those. That would mean I have messed up in my commit. Geert Hi Geert After doing that and making things somewhat worse, that is, getting even more files with line ending issues I git cloned a fresh copy of gnucash from GitHub. A git status gives me: # On branch trunk # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: src/report/jqplot/excanvas.min.js # modified: src/report/jqplot/jquery.jqplot.min.js # modified: src/report/jqplot/plugins/jqplot.BezierCurveRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.barRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.blockRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.bubbleRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasAxisLabelRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasAxisTickRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasOverlay.min.js # modified: src/report/jqplot/plugins/jqplot.canvasTextRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.categoryAxisRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.ciParser.min.js # Same files with line ending issues, but at least no warnings. It can't be just me surely? Although sometimes it seems to be :) Mike Evans Just to test I did the same: cloned a fresh copy from GitHub and it doesn't show any modified files. We seem to have a mystery here... Let's try to find what is different between your and my setup. The only difference I can imagine to cause this would be if you have configured line ending preferences locally. Is there some config parameter related to line endings in your $HOME/.gitconfig file (like autocrlf) ? I don't have anything in there. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
On Fri, 22 Feb 2013 18:47:48 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 22-02-13 14:43, Mike Evans schreef: On Thu, 21 Feb 2013 18:55:31 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 18:19, Mike Evans schreef: On Thu, 21 Feb 2013 18:04:37 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 16:54, Mike Evans schreef: A git|svn|brain issue follows. Having updated to the latest source using git-update script I can't change branches because some of the files have the wrong line endings, unless I commit the changes. I get this message: Please, commit your changes or stash them before you can switch branches. Git stash doesn't work and I get similar output to that shown below. A git diff gives the following output. warning: CRLF will be replaced by LF in src/report/jqplot/excanvas.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/jquery.jqplot.min.js. The file will have its original line endings in your working directory. SNIP src/report/jqplot/plugins/jqplot.ciParser.min.js. The file will have its original line endings in your working directory. diff --git src/report/jqplot/excanvas.min.js src/report/jqplot/excanvas.min.js index 83373a5..e699a26 100644 --- src/report/jqplot/excanvas.min.js +++ src/report/jqplot/excanvas.min.js @@ -1,3 +1,3 @@ -/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com - jsDate | (c) 2010-2013 Chris Leonello +/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com + jsDate | (c) 2010-2013 Chris Leonello Um. Not sure what to do or why this situation occurred in the first place. I thought git took care of line ending translations. I can commmit locally then dcommit but is that going to screw it up for anyone else? Advice needed. My love/hate relationship with GIT continues. Mike Evans Mike, These happen because the git configuration didn't have a definition for the line ending style for javascript files (.js). While working on the charts I added this definition. Some files that were already in git before now are checked out with different line endings. Can you try to run git checkout src/report/jqplot/*.js git checkout src/report/jqplot/plugins/*.js Does that fix the issue ? Geert Hi Geert Afraid not. Can I modify my config file manually? What do I add|change if so? Mike E It looks like the solution needs slightly more work. Read the part Re-normalizing a repo on this page: https://help.github.com/articles/dealing-with-line-endings Be sure to commit or stash your real changes before following this procedure. If at the end there are still files complaining about CRLF vs LF, you commit those. That would mean I have messed up in my commit. Geert Hi Geert After doing that and making things somewhat worse, that is, getting even more files with line ending issues I git cloned a fresh copy of gnucash from GitHub. A git status gives me: # On branch trunk # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: src/report/jqplot/excanvas.min.js # modified: src/report/jqplot/jquery.jqplot.min.js # modified: src/report/jqplot/plugins/jqplot.BezierCurveRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.barRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.blockRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.bubbleRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasAxisLabelRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasAxisTickRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasOverlay.min.js # modified: src/report/jqplot/plugins/jqplot.canvasTextRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.categoryAxisRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.ciParser.min.js # Same files with line ending issues, but at least no warnings. It can't be just me surely? Although sometimes it seems to be :) Mike Evans Just to test I did the same: cloned a fresh copy from GitHub and it doesn't show any modified files. We seem to have a mystery here... Let's try to find what is different between your and my setup. The only difference I can imagine to cause this would be if you have configured line ending preferences locally. Is there some config parameter related to line endings in your $HOME/.gitconfig file (like autocrlf) ? I don't have anything in there. Geert Thanks for checking Geert. I removed my $HOME/.gitconfig and tried again with the same result. My git version is 1.7.6.5 on Fedora 15 not sure it
CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)
Op 22-02-13 19:23, Mike Evans schreef: On Fri, 22 Feb 2013 18:47:48 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 22-02-13 14:43, Mike Evans schreef: On Thu, 21 Feb 2013 18:55:31 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 18:19, Mike Evans schreef: On Thu, 21 Feb 2013 18:04:37 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 16:54, Mike Evans schreef: A git|svn|brain issue follows. Having updated to the latest source using git-update script I can't change branches because some of the files have the wrong line endings, unless I commit the changes. I get this message: Please, commit your changes or stash them before you can switch branches. Git stash doesn't work and I get similar output to that shown below. A git diff gives the following output. warning: CRLF will be replaced by LF in src/report/jqplot/excanvas.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/jquery.jqplot.min.js. The file will have its original line endings in your working directory. SNIP src/report/jqplot/plugins/jqplot.ciParser.min.js. The file will have its original line endings in your working directory. diff --git src/report/jqplot/excanvas.min.js src/report/jqplot/excanvas.min.js index 83373a5..e699a26 100644 --- src/report/jqplot/excanvas.min.js +++ src/report/jqplot/excanvas.min.js @@ -1,3 +1,3 @@ -/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com - jsDate | (c) 2010-2013 Chris Leonello +/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com + jsDate | (c) 2010-2013 Chris Leonello Um. Not sure what to do or why this situation occurred in the first place. I thought git took care of line ending translations. I can commmit locally then dcommit but is that going to screw it up for anyone else? Advice needed. My love/hate relationship with GIT continues. Mike Evans Mike, These happen because the git configuration didn't have a definition for the line ending style for javascript files (.js). While working on the charts I added this definition. Some files that were already in git before now are checked out with different line endings. Can you try to run git checkout src/report/jqplot/*.js git checkout src/report/jqplot/plugins/*.js Does that fix the issue ? Geert Hi Geert Afraid not. Can I modify my config file manually? What do I add|change if so? Mike E It looks like the solution needs slightly more work. Read the part Re-normalizing a repo on this page: https://help.github.com/articles/dealing-with-line-endings Be sure to commit or stash your real changes before following this procedure. If at the end there are still files complaining about CRLF vs LF, you commit those. That would mean I have messed up in my commit. Geert Hi Geert After doing that and making things somewhat worse, that is, getting even more files with line ending issues I git cloned a fresh copy of gnucash from GitHub. A git status gives me: # On branch trunk # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: src/report/jqplot/excanvas.min.js # modified: src/report/jqplot/jquery.jqplot.min.js # modified: src/report/jqplot/plugins/jqplot.BezierCurveRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.barRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.blockRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.bubbleRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasAxisLabelRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasAxisTickRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasOverlay.min.js # modified: src/report/jqplot/plugins/jqplot.canvasTextRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.categoryAxisRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.ciParser.min.js # Same files with line ending issues, but at least no warnings. It can't be just me surely? Although sometimes it seems to be :) Mike Evans Just to test I did the same: cloned a fresh copy from GitHub and it doesn't show any modified files. We seem to have a mystery here... Let's try to find what is different between your and my setup. The only difference I can imagine to cause this would be if you have configured line ending preferences locally. Is there some config parameter related to line endings in your $HOME/.gitconfig file (like autocrlf) ? I don't have anything in there. Geert Thanks for checking Geert. I removed my $HOME/.gitconfig and tried again with the same result. My git version is 1.7.6.5 on Fedora 15 not sure it that makes any difference. Anyway now we know where the problem is (me) I know the solution is local. Enough for today though I think. My git version is git-1.8.1.2-1.fc18.i686 on
Re: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)
Op 22-02-13 19:45, Geert Janssens schreef: Op 22-02-13 19:23, Mike Evans schreef: On Fri, 22 Feb 2013 18:47:48 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 22-02-13 14:43, Mike Evans schreef: On Thu, 21 Feb 2013 18:55:31 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 18:19, Mike Evans schreef: On Thu, 21 Feb 2013 18:04:37 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 16:54, Mike Evans schreef: A git|svn|brain issue follows. Having updated to the latest source using git-update script I can't change branches because some of the files have the wrong line endings, unless I commit the changes. I get this message: Please, commit your changes or stash them before you can switch branches. Git stash doesn't work and I get similar output to that shown below. A git diff gives the following output. warning: CRLF will be replaced by LF in src/report/jqplot/excanvas.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/jquery.jqplot.min.js. The file will have its original line endings in your working directory. SNIP src/report/jqplot/plugins/jqplot.ciParser.min.js. The file will have its original line endings in your working directory. diff --git src/report/jqplot/excanvas.min.js src/report/jqplot/excanvas.min.js index 83373a5..e699a26 100644 --- src/report/jqplot/excanvas.min.js +++ src/report/jqplot/excanvas.min.js @@ -1,3 +1,3 @@ -/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com - jsDate | (c) 2010-2013 Chris Leonello +/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com + jsDate | (c) 2010-2013 Chris Leonello Um. Not sure what to do or why this situation occurred in the first place. I thought git took care of line ending translations. I can commmit locally then dcommit but is that going to screw it up for anyone else? Advice needed. My love/hate relationship with GIT continues. Mike Evans Mike, These happen because the git configuration didn't have a definition for the line ending style for javascript files (.js). While working on the charts I added this definition. Some files that were already in git before now are checked out with different line endings. Can you try to run git checkout src/report/jqplot/*.js git checkout src/report/jqplot/plugins/*.js Does that fix the issue ? Geert Hi Geert Afraid not. Can I modify my config file manually? What do I add|change if so? Mike E It looks like the solution needs slightly more work. Read the part Re-normalizing a repo on this page: https://help.github.com/articles/dealing-with-line-endings Be sure to commit or stash your real changes before following this procedure. If at the end there are still files complaining about CRLF vs LF, you commit those. That would mean I have messed up in my commit. Geert Hi Geert After doing that and making things somewhat worse, that is, getting even more files with line ending issues I git cloned a fresh copy of gnucash from GitHub. A git status gives me: # On branch trunk # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: src/report/jqplot/excanvas.min.js # modified: src/report/jqplot/jquery.jqplot.min.js # modified: src/report/jqplot/plugins/jqplot.BezierCurveRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.barRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.blockRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.bubbleRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasAxisLabelRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasAxisTickRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasOverlay.min.js # modified: src/report/jqplot/plugins/jqplot.canvasTextRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.categoryAxisRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.ciParser.min.js # Same files with line ending issues, but at least no warnings. It can't be just me surely? Although sometimes it seems to be :) Mike Evans Just to test I did the same: cloned a fresh copy from GitHub and it doesn't show any modified files. We seem to have a mystery here... Let's try to find what is different between your and my setup. The only difference I can imagine to cause this would be if you have configured line ending preferences locally. Is there some config parameter related to line endings in your $HOME/.gitconfig file (like autocrlf) ? I don't have anything in there. Geert Thanks for checking Geert. I removed my $HOME/.gitconfig and tried again with the same result. My git version is 1.7.6.5 on Fedora 15 not sure it that makes any difference. Anyway now we know where the problem is (me) I know the solution is local. Enough for today though I think. My git
Re: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)
On Feb 22, 2013, at 11:14 AM, Geert Janssens janssens-ge...@telenet.be wrote: Op 22-02-13 19:45, Geert Janssens schreef: Op 22-02-13 19:23, Mike Evans schreef: Thanks for checking Geert. I removed my $HOME/.gitconfig and tried again with the same result. My git version is 1.7.6.5 on Fedora 15 not sure it that makes any difference. Anyway now we know where the problem is (me) I know the solution is local. Enough for today though I think. My git version is git-1.8.1.2-1.fc18.i686 on Fedora 18. I don't know if that makes a difference or not. What exact url are you using to clone from github ? Mine is g...@github.com:Gnucash/gnucash.git Any other devs seeing this ? Geert Additionally, can you check if the eol attribute is already supported in your git version ? It is mentioned in man gitattributes on my system and is the attribute I'm using to force consistent line endings. It may be a more recent addition. Yeah, I see it on OSX. When I follow the renormalizing procedure, I get warning: CRLF will be replaced by LF in src/report/jqplot/foo.js. The file will have its original line endings in your working directory. For all of the files that Mike listed. Curiously, changing the *.js entry in .gitattributes to crlf and repeating the procedure has no effect. It appears that you got those js files into the repo with crlf line endings. git version 1.7.9.6 (Apple Git-31.1) The eol attribute is documented in gitattributes(5) Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
Op 12-02-13 18:46, Geert Janssens schreef: There was another feature that briefly appeared on the trunk branch: dynamic graphical reports with jqplot. I wonder whatever happened with it. The base for jqplot is in the code repo, and I also remember having seen some example reports using it. I can't find those anymore though. I wonder if the original author was unsure to invest further in it because his jqplot work triggered a long discussion on where to go with the current report system. Lots of possibilities were offered, but in the end we're still using the report system basically unchanged. Since there's still no clear plan for the report system on the horizon, I would love to see jqplot being used for our graphical reports. If the original author is still around, I'd love to hear from him (her?). Other than that, anyone interested in looking into what's needed to convert a report to jqplot ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel Well, it turns out I was too curious myself already, so I checked a bit further. I found the original mailinglist thread [1] and the missing patch to enable the jqplot alternatives for most of our chart types. Due to the age of the patch there were a few issues, but with some tweaking I managed to get it to work again. I like the result so much better than the old goffice based charts that I have chosen to remove the goffice based ones. The old list thread also pointed at some issues with the jqplot charts. I think I have fixed most of them, except the labels running over one another if there are lots of data points. If any other issues pop up, please let me know. And a random list of things that should/could be done still: - remove the gog code (should) - labels running over one another if there are many data points - dynamic sizing as an alternative option to the fixed width/height we now have to specify - some more code optimizations, like * linking to minimized versions of the js files * drop some unused/invalid chart options (in js code that is) - add/improve interaction to the charts Most of these are minor tweaks. Even as they are now, the jquery based charts are ready for feature freeze, IMO. Geert [1] https://lists.gnucash.org/pipermail/gnucash-devel/2011-March/031322.html ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
On Thu, 21 Feb 2013 12:47:18 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 12-02-13 18:46, Geert Janssens schreef: There was another feature that briefly appeared on the trunk branch: dynamic graphical reports with jqplot. I wonder whatever happened with it. The base for jqplot is in the code repo, and I also remember having seen some example reports using it. I can't find those anymore though. I wonder if the original author was unsure to invest further in it because his jqplot work triggered a long discussion on where to go with the current report system. Lots of possibilities were offered, but in the end we're still using the report system basically unchanged. Since there's still no clear plan for the report system on the horizon, I would love to see jqplot being used for our graphical reports. If the original author is still around, I'd love to hear from him (her?). Other than that, anyone interested in looking into what's needed to convert a report to jqplot ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel Well, it turns out I was too curious myself already, so I checked a bit further. I found the original mailinglist thread [1] and the missing patch to enable the jqplot alternatives for most of our chart types. Due to the age of the patch there were a few issues, but with some tweaking I managed to get it to work again. I like the result so much better than the old goffice based charts that I have chosen to remove the goffice based ones. The old list thread also pointed at some issues with the jqplot charts. I think I have fixed most of them, except the labels running over one another if there are lots of data points. If any other issues pop up, please let me know. And a random list of things that should/could be done still: - remove the gog code (should) - labels running over one another if there are many data points - dynamic sizing as an alternative option to the fixed width/height we now have to specify - some more code optimizations, like * linking to minimized versions of the js files * drop some unused/invalid chart options (in js code that is) - add/improve interaction to the charts Most of these are minor tweaks. Even as they are now, the jquery based charts are ready for feature freeze, IMO. Geert [1] https://lists.gnucash.org/pipermail/gnucash-devel/2011-March/031322.html ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel Lovely charts Geert. Two of the features I added in the Net Worth line chart are obsoleted/broken. Optional grid and optional data markers no longer work as advertised so I'll have to look at them or remove them. Not really sure if either are necessary anyway. All the charts could possibly use an alternate black and white stylesheet for printing, is this easier to achieve using jqplot? This is not new because of jqplot though. Mike Evans -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
On Thu, 21 Feb 2013 14:18:38 + Mike Evans mi...@saxicola.idps.co.uk wrote: On Thu, 21 Feb 2013 12:47:18 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 12-02-13 18:46, Geert Janssens schreef: There was another feature that briefly appeared on the trunk branch: dynamic graphical reports with jqplot. I wonder whatever happened with it. The base for jqplot is in the code repo, and I also remember having seen some example reports using it. I can't find those anymore though. I wonder if the original author was unsure to invest further in it because his jqplot work triggered a long discussion on where to go with the current report system. Lots of possibilities were offered, but in the end we're still using the report system basically unchanged. Since there's still no clear plan for the report system on the horizon, I would love to see jqplot being used for our graphical reports. If the original author is still around, I'd love to hear from him (her?). Other than that, anyone interested in looking into what's needed to convert a report to jqplot ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel Well, it turns out I was too curious myself already, so I checked a bit further. I found the original mailinglist thread [1] and the missing patch to enable the jqplot alternatives for most of our chart types. Due to the age of the patch there were a few issues, but with some tweaking I managed to get it to work again. I like the result so much better than the old goffice based charts that I have chosen to remove the goffice based ones. The old list thread also pointed at some issues with the jqplot charts. I think I have fixed most of them, except the labels running over one another if there are lots of data points. If any other issues pop up, please let me know. And a random list of things that should/could be done still: - remove the gog code (should) - labels running over one another if there are many data points - dynamic sizing as an alternative option to the fixed width/height we now have to specify - some more code optimizations, like * linking to minimized versions of the js files * drop some unused/invalid chart options (in js code that is) - add/improve interaction to the charts Most of these are minor tweaks. Even as they are now, the jquery based charts are ready for feature freeze, IMO. Geert [1] https://lists.gnucash.org/pipermail/gnucash-devel/2011-March/031322.html ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel Lovely charts Geert. Two of the features I added in the Net Worth line chart are obsoleted/broken. Optional grid and optional data markers no longer work as advertised so I'll have to look at them or remove them. Not really sure if either are necessary anyway. All the charts could possibly use an alternate black and white stylesheet for printing, is this easier to achieve using jqplot? This is not new because of jqplot though. Mike Evans A git|svn|brain issue follows. Having updated to the latest source using git-update script I can't change branches because some of the files have the wrong line endings, unless I commit the changes. I get this message: Please, commit your changes or stash them before you can switch branches. Git stash doesn't work and I get similar output to that shown below. A git diff gives the following output. warning: CRLF will be replaced by LF in src/report/jqplot/excanvas.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/jquery.jqplot.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.BezierCurveRenderer.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.barRenderer.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.blockRenderer.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.bubbleRenderer.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.canvasAxisLabelRenderer.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.canvasOverlay.min.js.
Re: Gnucash 2.5/6 - jqplot
Op 21-02-13 12:47, Geert Janssens schreef: Well, it turns out I was too curious myself already, so I checked a bit further. ... And a random list of things that should/could be done still: - remove the gog code (should) I have removed the goffice/gog dependencies in our html/webkit code. Unfortunately we're still stuck with goffice, because the CSV/Fixed-width indirectly depends on it (it uses code from lib/stf/ which is depending on goffice). Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
Op 21-02-13 16:54, Mike Evans schreef: A git|svn|brain issue follows. Having updated to the latest source using git-update script I can't change branches because some of the files have the wrong line endings, unless I commit the changes. I get this message: Please, commit your changes or stash them before you can switch branches. Git stash doesn't work and I get similar output to that shown below. A git diff gives the following output. warning: CRLF will be replaced by LF in src/report/jqplot/excanvas.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/jquery.jqplot.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.BezierCurveRenderer.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.barRenderer.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.blockRenderer.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.bubbleRenderer.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.canvasAxisLabelRenderer.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.canvasOverlay.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.canvasTextRenderer.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.categoryAxisRenderer.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.ciParser.min.js. The file will have its original line endings in your working directory. diff --git src/report/jqplot/excanvas.min.js src/report/jqplot/excanvas.min.js index 83373a5..e699a26 100644 --- src/report/jqplot/excanvas.min.js +++ src/report/jqplot/excanvas.min.js @@ -1,3 +1,3 @@ -/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com - jsDate | (c) 2010-2013 Chris Leonello +/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com + jsDate | (c) 2010-2013 Chris Leonello Um. Not sure what to do or why this situation occurred in the first place. I thought git took care of line ending translations. I can commmit locally then dcommit but is that going to screw it up for anyone else? Advice needed. My love/hate relationship with GIT continues. Mike Evans Mike, These happen because the git configuration didn't have a definition for the line ending style for javascript files (.js). While working on the charts I added this definition. Some files that were already in git before now are checked out with different line endings. Can you try to run git checkout src/report/jqplot/*.js git checkout src/report/jqplot/plugins/*.js Does that fix the issue ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
Op 21-02-13 15:18, Mike Evans schreef: Lovely charts Geert. Two of the features I added in the Net Worth line chart are obsoleted/broken. Optional grid and optional data markers no longer work as advertised so I'll have to look at them or remove them. Not really sure if either are necessary anyway. Thanks, most of the credit goes to Andy Clayton though, who did most of the work. I mostly tuned and updated it. About the options, that got dropped, I didn't notice them, sorry. It shouldn't be too hard to add them again. I'll fix it in a next round. All the charts could possibly use an alternate black and white stylesheet for printing, is this easier to achieve using jqplot? This is not new because of jqplot though. It depends, but I don't think I understand exactly what you would like to achieve here. Can you elaborate a bit ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
On Thu, 21 Feb 2013 18:04:37 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 16:54, Mike Evans schreef: A git|svn|brain issue follows. Having updated to the latest source using git-update script I can't change branches because some of the files have the wrong line endings, unless I commit the changes. I get this message: Please, commit your changes or stash them before you can switch branches. Git stash doesn't work and I get similar output to that shown below. A git diff gives the following output. warning: CRLF will be replaced by LF in src/report/jqplot/excanvas.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/jquery.jqplot.min.js. The file will have its original line endings in your working directory. SNIP src/report/jqplot/plugins/jqplot.ciParser.min.js. The file will have its original line endings in your working directory. diff --git src/report/jqplot/excanvas.min.js src/report/jqplot/excanvas.min.js index 83373a5..e699a26 100644 --- src/report/jqplot/excanvas.min.js +++ src/report/jqplot/excanvas.min.js @@ -1,3 +1,3 @@ -/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com - jsDate | (c) 2010-2013 Chris Leonello +/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com + jsDate | (c) 2010-2013 Chris Leonello Um. Not sure what to do or why this situation occurred in the first place. I thought git took care of line ending translations. I can commmit locally then dcommit but is that going to screw it up for anyone else? Advice needed. My love/hate relationship with GIT continues. Mike Evans Mike, These happen because the git configuration didn't have a definition for the line ending style for javascript files (.js). While working on the charts I added this definition. Some files that were already in git before now are checked out with different line endings. Can you try to run git checkout src/report/jqplot/*.js git checkout src/report/jqplot/plugins/*.js Does that fix the issue ? Geert Hi Geert Afraid not. Can I modify my config file manually? What do I add|change if so? Mike E -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
On Thu, 21 Feb 2013 18:16:53 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 15:18, Mike Evans schreef: Lovely charts Geert. Two of the features I added in the Net Worth line chart are obsoleted/broken. Optional grid and optional data markers no longer work as advertised so I'll have to look at them or remove them. Not really sure if either are necessary anyway. Thanks, most of the credit goes to Andy Clayton though, who did most of the work. I mostly tuned and updated it. About the options, that got dropped, I didn't notice them, sorry. It shouldn't be too hard to add them again. I'll fix it in a next round. All the charts could possibly use an alternate black and white stylesheet for printing, is this easier to achieve using jqplot? This is not new because of jqplot though. It depends, but I don't think I understand exactly what you would like to achieve here. Can you elaborate a bit ? Geert Charts don't print very well on a BW laser. They didn't before to be fair. For BW the lines, text, borders etc., need to be black (obviously) with a different line style (dash type) for each data line. Basically a user should be able to toggle between BW and colour in the chart preferences. Just curious as to how hard this would be to implement. I don't know how many people would need this, so it probably isn't a high priority anyway. Mike Evans -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
Op 21-02-13 18:19, Mike Evans schreef: On Thu, 21 Feb 2013 18:04:37 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 16:54, Mike Evans schreef: A git|svn|brain issue follows. Having updated to the latest source using git-update script I can't change branches because some of the files have the wrong line endings, unless I commit the changes. I get this message: Please, commit your changes or stash them before you can switch branches. Git stash doesn't work and I get similar output to that shown below. A git diff gives the following output. warning: CRLF will be replaced by LF in src/report/jqplot/excanvas.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/jquery.jqplot.min.js. The file will have its original line endings in your working directory. SNIP src/report/jqplot/plugins/jqplot.ciParser.min.js. The file will have its original line endings in your working directory. diff --git src/report/jqplot/excanvas.min.js src/report/jqplot/excanvas.min.js index 83373a5..e699a26 100644 --- src/report/jqplot/excanvas.min.js +++ src/report/jqplot/excanvas.min.js @@ -1,3 +1,3 @@ -/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com - jsDate | (c) 2010-2013 Chris Leonello +/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com + jsDate | (c) 2010-2013 Chris Leonello Um. Not sure what to do or why this situation occurred in the first place. I thought git took care of line ending translations. I can commmit locally then dcommit but is that going to screw it up for anyone else? Advice needed. My love/hate relationship with GIT continues. Mike Evans Mike, These happen because the git configuration didn't have a definition for the line ending style for javascript files (.js). While working on the charts I added this definition. Some files that were already in git before now are checked out with different line endings. Can you try to run git checkout src/report/jqplot/*.js git checkout src/report/jqplot/plugins/*.js Does that fix the issue ? Geert Hi Geert Afraid not. Can I modify my config file manually? What do I add|change if so? Mike E It looks like the solution needs slightly more work. Read the part Re-normalizing a repo on this page: https://help.github.com/articles/dealing-with-line-endings Be sure to commit or stash your real changes before following this procedure. If at the end there are still files complaining about CRLF vs LF, you commit those. That would mean I have messed up in my commit. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
Op 21-02-13 15:18, Mike Evans schreef: Lovely charts Geert. Two of the features I added in the Net Worth line chart are obsoleted/broken. Optional grid and optional data markers no longer work as advertised so I'll have to look at them or remove them. Not really sure if either are necessary anyway. I noticed your grid specification was vertical only Y Grid. I have made all grid optional. If checked, you will have horizontal and vertical grid. Personally I like it more that way, but you may have had good reasons for your configuration. If you don't like that, you are welcome to tweak the code a bit. You now have an example you can work from. It should be easy. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
Op 21-02-13 18:40, Mike Evans schreef: On Thu, 21 Feb 2013 18:16:53 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 15:18, Mike Evans schreef: Lovely charts Geert. Two of the features I added in the Net Worth line chart are obsoleted/broken. Optional grid and optional data markers no longer work as advertised so I'll have to look at them or remove them. Not really sure if either are necessary anyway. Thanks, most of the credit goes to Andy Clayton though, who did most of the work. I mostly tuned and updated it. About the options, that got dropped, I didn't notice them, sorry. It shouldn't be too hard to add them again. I'll fix it in a next round. All the charts could possibly use an alternate black and white stylesheet for printing, is this easier to achieve using jqplot? This is not new because of jqplot though. It depends, but I don't think I understand exactly what you would like to achieve here. Can you elaborate a bit ? Geert Charts don't print very well on a BW laser. They didn't before to be fair. For BW the lines, text, borders etc., need to be black (obviously) with a different line style (dash type) for each data line. Basically a user should be able to toggle between BW and colour in the chart preferences. Just curious as to how hard this would be to implement. I don't know how many people would need this, so it probably isn't a high priority anyway. Mike Evans I think is possible, but not straightforward. The base colours are in a css file. This could easily be overridden in a custom css file specifically for printing. But the line/bar/pie segment colors are chosen by the java script code. The jqplot code is flexible enough that you can even override these by setting options for the jqplot object, but it could be more difficult to only do that for printing. Overriding line styles is similar to overriding the data colors: you can do it by setting javascript options. Again, it may be more complicated to do this only for printing. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
Am Donnerstag, 21. Februar 2013, 17:57:30 schrieb Geert Janssens: Op 21-02-13 12:47, Geert Janssens schreef: Well, it turns out I was too curious myself already, so I checked a bit further. ... And a random list of things that should/could be done still: - remove the gog code (should) I have removed the goffice/gog dependencies in our html/webkit code. Great! Thanks for the jqplot and throwing out of the gog plot. Unfortunately we're still stuck with goffice, because the CSV/Fixed-width indirectly depends on it (it uses code from lib/stf/ which is depending on goffice). Well, the CSV importer might use a rewrite as well, but currently we have to live with that. However, I get a compile error after your r22799, ../../../src/gnome-utils/gnc-gnome-utils.c:31:26: fatal error: libxml/xmlIO.h: No such file or directory compilation terminated. make[4]: *** [gnc-gnome-utils.lo] Error 1 make[4]: Leaving directory `/home/cs/org/gnucash/git/trunk/build/src/gnome- utils' Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
Op 21-02-13 20:53, Christian Stimming schreef: Am Donnerstag, 21. Februar 2013, 17:57:30 schrieb Geert Janssens: Op 21-02-13 12:47, Geert Janssens schreef: Well, it turns out I was too curious myself already, so I checked a bit further. ... And a random list of things that should/could be done still: - remove the gog code (should) I have removed the goffice/gog dependencies in our html/webkit code. Great! Thanks for the jqplot and throwing out of the gog plot. Unfortunately we're still stuck with goffice, because the CSV/Fixed-width indirectly depends on it (it uses code from lib/stf/ which is depending on goffice). Well, the CSV importer might use a rewrite as well, but currently we have to live with that. However, I get a compile error after your r22799, ../../../src/gnome-utils/gnc-gnome-utils.c:31:26: fatal error: libxml/xmlIO.h: No such file or directory compilation terminated. make[4]: *** [gnc-gnome-utils.lo] Error 1 make[4]: Leaving directory `/home/cs/org/gnucash/git/trunk/build/src/gnome- utils' Regards, Christian I'll look into it tomorrow. I'm out of time this evening. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6
On Sun, 17 Feb 2013 13:55:40 -0800 (PST) Phil Longstaff phil.longst...@yahoo.ca wrote: I created https://bugzilla.gnome.org/show_bug.cgi?id=694047 and attached an initial patch to that. That should allow you to get it in. I'll need to learn more about git. Phil From: John Ralls jra...@ceridwen.us To: Robert Fewell 14ubo...@gmail.com; Geert Janssens janssens-ge...@telenet.be Cc: gnucash-devel@gnucash.org Devel gnucash-devel@gnucash.org Sent: Tuesday, February 12, 2013 2:22:39 PM Subject: Re: Gnucash 2.5/6 On Feb 9, 2013, at 1:45 PM, lsl 14ubo...@gmail.com wrote: I am still plodding on with this and it is progressing slowly, have uploaded another patch to the bug which also indicates roughly what is left to do. I am not sure of any time scales but the menu options can be disabled or the whole lot can be removed if it is holding other things up. Assuming it is still viable, I will continue and progress it as time permits. Is this mostly working? If so, let's get it into trunk and ditch the old register. That will at least let us get rid of the project Ridley deprecated libraries. It will also get more people banging on it, which will bring any problems to light. Pending that and Phil's budgeting, I'm thinking we can release 2.5.0 next week. Regards, John Ralls I just tested Robert Fewell's patch in Bug 673193 and I realised it makes my reverse sort (Bug 683881, commit 679d59e44) work obsolete as sorting order can be changed by simply clicking in the column header. If the TreeView is going to become the standard then think I should remove my commit and mark the bug as obsolete. Thoughts? Mike Evans -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6
On Feb 18, 2013, at 6:50 AM, Mike Evans mi...@saxicola.idps.co.uk wrote: On Sun, 17 Feb 2013 13:55:40 -0800 (PST) Phil Longstaff phil.longst...@yahoo.ca wrote: I created https://bugzilla.gnome.org/show_bug.cgi?id=694047 and attached an initial patch to that. That should allow you to get it in. I'll need to learn more about git. Phil From: John Ralls jra...@ceridwen.us To: Robert Fewell 14ubo...@gmail.com; Geert Janssens janssens-ge...@telenet.be Cc: gnucash-devel@gnucash.org Devel gnucash-devel@gnucash.org Sent: Tuesday, February 12, 2013 2:22:39 PM Subject: Re: Gnucash 2.5/6 On Feb 9, 2013, at 1:45 PM, lsl 14ubo...@gmail.com wrote: I am still plodding on with this and it is progressing slowly, have uploaded another patch to the bug which also indicates roughly what is left to do. I am not sure of any time scales but the menu options can be disabled or the whole lot can be removed if it is holding other things up. Assuming it is still viable, I will continue and progress it as time permits. Is this mostly working? If so, let's get it into trunk and ditch the old register. That will at least let us get rid of the project Ridley deprecated libraries. It will also get more people banging on it, which will bring any problems to light. Pending that and Phil's budgeting, I'm thinking we can release 2.5.0 next week. Regards, John Ralls I just tested Robert Fewell's patch in Bug 673193 and I realised it makes my reverse sort (Bug 683881, commit 679d59e44) work obsolete as sorting order can be changed by simply clicking in the column header. If the TreeView is going to become the standard then think I should remove my commit and mark the bug as obsolete. Thoughts? Aside from that, what do you think of the TreeView register? Do you think that it's ready to release in 2.5.0 this week? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6
I created https://bugzilla.gnome.org/show_bug.cgi?id=694047 and attached an initial patch to that. That should allow you to get it in. I'll need to learn more about git. Phil From: John Ralls jra...@ceridwen.us To: Robert Fewell 14ubo...@gmail.com; Geert Janssens janssens-ge...@telenet.be Cc: gnucash-devel@gnucash.org Devel gnucash-devel@gnucash.org Sent: Tuesday, February 12, 2013 2:22:39 PM Subject: Re: Gnucash 2.5/6 On Feb 9, 2013, at 1:45 PM, Robert Fewell 14ubo...@gmail.com wrote: I am still plodding on with this and it is progressing slowly, have uploaded another patch to the bug which also indicates roughly what is left to do. I am not sure of any time scales but the menu options can be disabled or the whole lot can be removed if it is holding other things up. Assuming it is still viable, I will continue and progress it as time permits. Is this mostly working? If so, let's get it into trunk and ditch the old register. That will at least let us get rid of the project Ridley deprecated libraries. It will also get more people banging on it, which will bring any problems to light. Pending that and Phil's budgeting, I'm thinking we can release 2.5.0 next week. Regards, John Ralls ___ 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: Gnucash 2.5/6
On Feb 17, 2013, at 1:55 PM, Phil Longstaff phil.longst...@yahoo.ca wrote: I created https://bugzilla.gnome.org/show_bug.cgi?id=694047 and attached an initial patch to that. That should allow you to get it in. I'll need to learn more about git. OK, but we're still committing to subversion. Unless you want a code review, just commit it the way you always have. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6
On 11-02-13 15:00, Phil Longstaff wrote: Yes. I have a first draft ready to go. Looks pretty rough but is usable, which is what I needed. What I've done: 1) structurally, split GncBudgetView out from GncPluginPageBudget. GncBudgetView provides a widget that GncPluginPageBudget can use and configure. 2) modified GncBudgetView so that if a budget cell belongs to an account which has children, but does not have a value of its own, it displays the sum of its children's budget values in gray. Provides a row of totals. 3) added a col called totals which sums the values for each row and provides a total for the year (assuming a 12-month budget) 4) added a section below the main budget with 4 lines: a) income - duplicates the values from the top level income account b) expenses - duplicates the values from the top level expense account c) transfers - top level assets values - top level liabilities values d) total = income - expenses - transfers. Red if negative Basically these changes provide some totals and summary values. Very good. I'd really like the columns in the lower display to line up with those in the upper display, but haven't figured that out yet. I'd like the account name and totals column to be fixed, and any scrolling to happen with the budget period figures, but haven't figured that out yet. I could make the totals column a separate tree view outside the main tree view, but would then need to make it expand and contract along with the main tree view. Basically, I'm trying to learn the gtk widgets and make a good display. If anyone is a gtk expert and wants to give me some pointers, that would be great. I've done many of the dialogue conversions from libglade to gtkbuilder, so I have touched a lot of gtk code. I don't consider myself an expert though. Particularly the treeview is a complex widget. I managed to do most of my work using the gtk reference manual (http://developer.gnome.org/gtk2/2.24/) and asking questions on the Gtk Application development mailing list (gtk-app-devel-l...@gnome.org). I was trying to set up git and locked myself out of svn, so I'm unable to commit anything at this point. I want to do a bit more cleanup, but should have something by next weekend. The svn access issue is something you best contact Derek for (either privately or via irc). I think next weekend is fine for inclusion in the upcoming 2.5/2.6 series. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
On Gtk3 (was:Re: Gnucash 2.5/6)
On 08-02-13 16:09, Derek Atkins wrote: Geert Janssens janssens-ge...@telenet.be writes: Forgot to mention: Gtk3 was indeed not on the agenda for 2.6. 2.6 is only meant to be *ready* to be migrated. This means getting rid of all the deprecated gtk symbols. Other than the register this is done. So the register rewrite is actually important for this goal, whether we use the GtkTreeView approach or the libgnome-cairo route. Personnaly I'd rather see us move to Qt instead of Gtk3 when that decision has to be made. My reasoning is that I think the Gtk developers have lost sight of their target audience, and as a result keep removing features that are vital. It's too much of a loose firehose, and IMHO shouldn't be supported anymore. Indeed, for my next desktop re-install I plan to move away from a Gnome desktop and over to XFCE.. With Gtk3 the Gnome project has chosen a very different course which turns out to be very controversial as well. I have both seen people who absolutely love it and people who totally can't stand it. My point of view? I'm pretty neutral as I don't use it ;) I only used Gnome 2 for a while a long time ago, switched to kde then and never returned (this is not meant as a kde promo!). It doesn't look to me they have lost sight of their target audience though. I rather think they have deliberately redefined their target audience. Inevitable that means some people that used to be targeted no longer are and hence don't like the new experience. I think many long-time knowledgeable computer users fall into that category. Less experienced users seem to like it a lot more. I'm not here to defend the Gnome project's decisions though. I'm just saying whether gtk3 is a good thing or not is rather subjective. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: On Gtk3 (was:Re: Gnucash 2.5/6)
On Feb 12, 2013, at 2:41 AM, Geert Janssens janssens-ge...@telenet.be wrote: On 08-02-13 16:09, Derek Atkins wrote: Geert Janssens janssens-ge...@telenet.be writes: Forgot to mention: Gtk3 was indeed not on the agenda for 2.6. 2.6 is only meant to be *ready* to be migrated. This means getting rid of all the deprecated gtk symbols. Other than the register this is done. So the register rewrite is actually important for this goal, whether we use the GtkTreeView approach or the libgnome-cairo route. Personnaly I'd rather see us move to Qt instead of Gtk3 when that decision has to be made. My reasoning is that I think the Gtk developers have lost sight of their target audience, and as a result keep removing features that are vital. It's too much of a loose firehose, and IMHO shouldn't be supported anymore. Indeed, for my next desktop re-install I plan to move away from a Gnome desktop and over to XFCE.. With Gtk3 the Gnome project has chosen a very different course which turns out to be very controversial as well. I have both seen people who absolutely love it and people who totally can't stand it. My point of view? I'm pretty neutral as I don't use it ;) I only used Gnome 2 for a while a long time ago, switched to kde then and never returned (this is not meant as a kde promo!). It doesn't look to me they have lost sight of their target audience though. I rather think they have deliberately redefined their target audience. Inevitable that means some people that used to be targeted no longer are and hence don't like the new experience. I think many long-time knowledgeable computer users fall into that category. Less experienced users seem to like it a lot more. I'm not here to defend the Gnome project's decisions though. I'm just saying whether gtk3 is a good thing or not is rather subjective. Don't confuse the toolkit with the Gnome Shell. Gtk+ itself hasn't changed that much, and many of the changes are about not wrapping services provided by other libraries -- like exposing a cairo surface to draw on rather than wrapping it with GtkCanvas, or moving behaviors down to Gio (e.g. menus), I think so that the code can be shared with Clutter. Theming is now built in and accomplished with CSS, which should be a substantial stability improvement. A much bigger problem is that since Tor Liliquist dropped out a couple of years ago, Win32 support hasn't kept up. There's no pre-built Gtk3 stack available on ftp.gnome.org, and there was a recent thread on gtk-devel-list from some Win32 users complaining that there were patches on bugzilla, widely adopted in the wild, that hadn't been applied. But unless we can recruit some developers to take over where Christian left off, we're pretty much stuck with Gtk+. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
On 07-02-13 19:32, John Ralls wrote: Geert mentioned in the Notification Emails thread that he'd like to get 2.6 released in less than a year, and Christian was pushing to do so this time *last* year. On the principle that Release is a misnomer. Software is never released, it escapes. [1], it's probably time to release 2.5.0 so that we can at least start down that road. Shall we say feature freeze now, string freeze in July, 2.6 release 1 November? Or is anyone actively working on features that should go in? What became of the rewrite of the register to GtkTreeView? Failing that, has anyone taken a shot at rewriting it with Cairo instead of libgnome? Note that I'm not proposing a Gtk3 migration for 2.6: We're doing that at Gramps, and MSWin is proving to be troublesome. In fact, it appears that no one is supporting Gtk3-MSWin at the moment. Regards, John Ralls [1] I don't know where that originated. My wife brought it with her from DEC, where it was apparently a truism. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel There was another feature that briefly appeared on the trunk branch: dynamic graphical reports with jqplot. I wonder whatever happened with it. The base for jqplot is in the code repo, and I also remember having seen some example reports using it. I can't find those anymore though. I wonder if the original author was unsure to invest further in it because his jqplot work triggered a long discussion on where to go with the current report system. Lots of possibilities were offered, but in the end we're still using the report system basically unchanged. Since there's still no clear plan for the report system on the horizon, I would love to see jqplot being used for our graphical reports. If the original author is still around, I'd love to hear from him (her?). Other than that, anyone interested in looking into what's needed to convert a report to jqplot ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6
On Feb 9, 2013, at 1:45 PM, Robert Fewell 14ubo...@gmail.com wrote: I am still plodding on with this and it is progressing slowly, have uploaded another patch to the bug which also indicates roughly what is left to do. I am not sure of any time scales but the menu options can be disabled or the whole lot can be removed if it is holding other things up. Assuming it is still viable, I will continue and progress it as time permits. Is this mostly working? If so, let's get it into trunk and ditch the old register. That will at least let us get rid of the project Ridley deprecated libraries. It will also get more people banging on it, which will bring any problems to light. Pending that and Phil's budgeting, I'm thinking we can release 2.5.0 next week. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6
Yes. I have a first draft ready to go. Looks pretty rough but is usable, which is what I needed. What I've done: 1) structurally, split GncBudgetView out from GncPluginPageBudget. GncBudgetView provides a widget that GncPluginPageBudget can use and configure. 2) modified GncBudgetView so that if a budget cell belongs to an account which has children, but does not have a value of its own, it displays the sum of its children's budget values in gray. Provides a row of totals. 3) added a col called totals which sums the values for each row and provides a total for the year (assuming a 12-month budget) 4) added a section below the main budget with 4 lines: a) income - duplicates the values from the top level income account b) expenses - duplicates the values from the top level expense account c) transfers - top level assets values - top level liabilities values d) total = income - expenses - transfers. Red if negative Basically these changes provide some totals and summary values. I'd really like the columns in the lower display to line up with those in the upper display, but haven't figured that out yet. I'd like the account name and totals column to be fixed, and any scrolling to happen with the budget period figures, but haven't figured that out yet. I could make the totals column a separate tree view outside the main tree view, but would then need to make it expand and contract along with the main tree view. Basically, I'm trying to learn the gtk widgets and make a good display. If anyone is a gtk expert and wants to give me some pointers, that would be great. I was trying to set up git and locked myself out of svn, so I'm unable to commit anything at this point. I want to do a bit more cleanup, but should have something by next weekend. Phil From: Geert Janssens janssens-ge...@telenet.be To: gnucash-devel@gnucash.org Sent: Saturday, February 9, 2013 12:03:44 PM Subject: Re: Gnucash 2.5/6 On 09-02-13 00:59, Phil Longstaff wrote: At this point, there's an itch which is bothering me more and it's in the budgeting area. I'm separating the budget plugin page into the page and the budget display widget so I can enhance the widget by adding more info. I want a fixed total column, and fixed income, expense and transfers rows (transfers = transfers to assets or liabilities). GSettings is taking second place to that. Phil Thanks for clearing that out. Of course you are free work on what you feel like to be more important to you. Do you want the improvements in the budgetting area included in 2.6 ? I mean do you want us to postpone the feature freeze until you get a first draft of the improvements in trunk ? Geert ___ 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 2.5/6
Phil, I may of misunderstood, the csv transaction importer use two tree-views one above each other and keeps the columns in sync. Have a look in assistant-csv-trans-import.c Regards, Robert. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6
Thanks From: Robert Fewell 14ubo...@gmail.com To: gnucash-devel@gnucash.org Sent: Monday, February 11, 2013 10:40:27 AM Subject: Gnucash 2.5/6 Phil, I may of misunderstood, the csv transaction importer use two tree-views one above each other and keeps the columns in sync. Have a look in assistant-csv-trans-import.c Regards, Robert. ___ 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: Beyond 2.6 (was:Re: Gnucash 2.5/6)
John Ralls jra...@ceridwen.us writes: As for Gtkmm, it's just a C++ interface wrapped around Gtk+. If we're dumping Gtk+ because we don't like the direction they're going, Gtkmm doesn't get us anywhere. Having argued that C++ in the backend in not such a big deal, I'm going to turn around and point out that dropping Gtk+ in favor of wx, Qt, or some other GUI framework isn't a easy job: That *is* a complete rewrite, and there's a lot of it. Who would do it? I was just pointing out that if we had to spend a lot of time migrating to Gtk3 we might be better off spending the time migrating to something else. I still wish I had written QOF in C++ instead of C a decade ago. :-( Regards, John Ralls -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 warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.6 (was:Re: Gnucash 2.5/6)
On Feb 11, 2013, at 10:23 AM, Derek Atkins warl...@mit.edu wrote: John Ralls jra...@ceridwen.us writes: As for Gtkmm, it's just a C++ interface wrapped around Gtk+. If we're dumping Gtk+ because we don't like the direction they're going, Gtkmm doesn't get us anywhere. Having argued that C++ in the backend in not such a big deal, I'm going to turn around and point out that dropping Gtk+ in favor of wx, Qt, or some other GUI framework isn't a easy job: That *is* a complete rewrite, and there's a lot of it. Who would do it? I was just pointing out that if we had to spend a lot of time migrating to Gtk3 we might be better off spending the time migrating to something else. OK. In fact we've (meaning Geert's) already done 90% of the job. All that's left is fixing the register to draw with Cairo surfaces instead of the ancient libgnome stuff. Not an easy job, but much easier than porting everything to Qt. I still wish I had written QOF in C++ instead of C a decade ago. :-( Me too. But that's not too hard to fix, once I figure out how to get GObject to inherit from a C++ object. The answer is no doubt somewhere in glibmm. But it's not quite time for that yet. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.6 (was:Re: Gnucash 2.5/6)
John, what's your view of the best way forward? I'm confused by what you want to wrap C++ inside GObject. What's your end vision and what are the steps along the way. Phil From: John Ralls jra...@ceridwen.us To: Derek Atkins warl...@mit.edu Cc: gnucash-devel@gnucash.org Devel gnucash-devel@gnucash.org Sent: Monday, February 11, 2013 1:36:31 PM Subject: Re: Beyond 2.6 (was:Re: Gnucash 2.5/6) On Feb 11, 2013, at 10:23 AM, Derek Atkins warl...@mit.edu wrote: John Ralls jra...@ceridwen.us writes: As for Gtkmm, it's just a C++ interface wrapped around Gtk+. If we're dumping Gtk+ because we don't like the direction they're going, Gtkmm doesn't get us anywhere. Having argued that C++ in the backend in not such a big deal, I'm going to turn around and point out that dropping Gtk+ in favor of wx, Qt, or some other GUI framework isn't a easy job: That *is* a complete rewrite, and there's a lot of it. Who would do it? I was just pointing out that if we had to spend a lot of time migrating to Gtk3 we might be better off spending the time migrating to something else. OK. In fact we've (meaning Geert's) already done 90% of the job. All that's left is fixing the register to draw with Cairo surfaces instead of the ancient libgnome stuff. Not an easy job, but much easier than porting everything to Qt. I still wish I had written QOF in C++ instead of C a decade ago. :-( Me too. But that's not too hard to fix, once I figure out how to get GObject to inherit from a C++ object. The answer is no doubt somewhere in glibmm. But it's not quite time for that yet. Regards, John Ralls ___ 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: Beyond 2.6 (was:Re: Gnucash 2.5/6)
Am Montag, 11. Februar 2013, 10:36:31 schrieb John Ralls: I was just pointing out that if we had to spend a lot of time migrating to Gtk3 we might be better off spending the time migrating to something else. OK. In fact we've (meaning Geert's) already done 90% of the job. All that's left is fixing the register to draw with Cairo surfaces instead of the ancient libgnome stuff. Not an easy job, but much easier than porting everything to Qt. Very good. I still wish I had written QOF in C++ instead of C a decade ago. :-( Me too. But that's not too hard to fix, once I figure out how to get GObject to inherit from a C++ object. The answer is no doubt somewhere in glibmm. But it's not quite time for that yet. Have a look at the existing cutecash code: In src/optional/gtkmm/gncmm/Account.hpp there's an gnc::Account, and as you see there, the module has a gnc::GncInstance base class that wraps the QofInstance object that manages the qof parts. This in turn is derived from Glib::Object which is the C++ version of a GObject. In my opinion, this wrapping of GObject and also (while it still exists) QofInstance in the end looks very well possible and the resulting C++ classes look well enough like a real C++ class. Disclaimer for all other readers: The C++ part of this discussion is currently only an academic one. It has not yet anything to do with the real work that is done in the coming months. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.6 (was:Re: Gnucash 2.5/6)
* would recommend writing C++ header files as a starting point tedc * On Mon, Feb 11, 2013 at 1:21 PM, Christian Stimming christ...@cstimming.dewrote: Am Montag, 11. Februar 2013, 10:36:31 schrieb John Ralls: I was just pointing out that if we had to spend a lot of time migrating to Gtk3 we might be better off spending the time migrating to something else. OK. In fact we've (meaning Geert's) already done 90% of the job. All that's left is fixing the register to draw with Cairo surfaces instead of the ancient libgnome stuff. Not an easy job, but much easier than porting everything to Qt. Very good. I still wish I had written QOF in C++ instead of C a decade ago. :-( Me too. But that's not too hard to fix, once I figure out how to get GObject to inherit from a C++ object. The answer is no doubt somewhere in glibmm. But it's not quite time for that yet. Have a look at the existing cutecash code: In src/optional/gtkmm/gncmm/Account.hpp there's an gnc::Account, and as you see there, the module has a gnc::GncInstance base class that wraps the QofInstance object that manages the qof parts. This in turn is derived from Glib::Object which is the C++ version of a GObject. In my opinion, this wrapping of GObject and also (while it still exists) QofInstance in the end looks very well possible and the resulting C++ classes look well enough like a real C++ class. Disclaimer for all other readers: The C++ part of this discussion is currently only an academic one. It has not yet anything to do with the real work that is done in the coming months. Regards, 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: Beyond 2.6 (was:Re: Gnucash 2.5/6)
On Feb 11, 2013, at 10:53 AM, Phil Longstaff phil.longst...@yahoo.ca wrote:
John,
what's your view of the best way forward? I'm confused by what you want to
wrap C++ inside GObject. What's your end vision and what are the steps along
the way.
The goal is, as ever, a clean, modern architecture with fewer dependencies.
Christian wrote at length last year about how our core library isn't portable
because it depends heavily upon Glib. Until that discussion, I'd thought of
that as a feature, because GLib provides so many services. But it does tie us
to the Gnome ecosystem -- and to MinGW for M$Windows. Plus, it's a lot of work
to write GObject code, and when you're done it's hard to understand compared to
a proper OO language. Derek's bringing up abandoning Gtk+ popped that out
I don't really want to wrap C++ in GObject, but I'd prefer to incrementally
change the engine and backends to C++, because writing GObject stuff is such a
PITA. The current design has a shallow class tree: Everything derives from
QofInstance. But it's also a bit tangled, with the different classes being
badly interdependent. It would be safer to convert one class at a time to C++,
starting with QofInstance, but doing so requires GObject classes to be able to
derive from a C++ class. The reverse has already been worked out, because
that's how the various OO language bindings for Gtk+ and friends work. That's
what the reference to glibmm is about.
On Feb 11, 2013, at 1:21 PM, Christian Stimming christ...@cstimming.de wrote:
Have a look at the existing cutecash code: In
src/optional/gtkmm/gncmm/Account.hpp there's an gnc::Account, and as you see
there, the module has a gnc::GncInstance base class that wraps the
QofInstance
object that manages the qof parts. This in turn is derived from
Glib::Object
which is the C++ version of a GObject. In my opinion, this wrapping of
GObject and also (while it still exists) QofInstance in the end looks very
well possible and the resulting C++ classes look well enough like a real C++
class.
Thanks for the pointer. Having a concrete example will be helpful.
What I was thinking was that I'd want to rewrite QofInstance in C++ and then
derive Account and friends from it while leaving them as GObjects. As I started
to write about that I realized that we don't actually use the virtualization
features of GObject, we just manually chain up the superclass functions where
we need them, so it's not really a problem. A header full of inline functions
to translate those chaining-up functions will do the trick.
For example:
inline QofBook* qof_instance_get_book (gpointer inst)
{
return static_castQofInstance*(inst)-get_book();
}
Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.6 (was:Re: Gnucash 2.5/6)
On Feb 8, 2013, at 8:01 PM, John Ralls jra...@ceridwen.us wrote: On Feb 8, 2013, at 1:03 PM, Christian Stimming christ...@cstimming.de wrote: Am Freitag, 8. Februar 2013, 09:51:57 schrieb John Ralls: Personnaly I'd rather see us move to Qt instead of Gtk3 when that decision has to be made. I did express my interest in Qt before in mails to the list. But when you also want to switch to C++ and Boost, to me that sounds more or less like a complete rewrite of GnuCash. We've had this conversation before, and more or less came to the conclusion we don't have enough man power to do that. Unless such rewrite can be done in baby steps, spread over several releases, say like one module at the time ? Is such a segmentation possible/practical ? No, switching from C/gtk to C++/whatever in minor steps is in general not possible. When talking about gnucash in C++: Please, don't only make your guesses, but also compile the cutecash part once. There were already some conclusions as for the possibility of going to C++: The choice of C++ is not sufficient; additionally, the GUI toolkit must be chosen as well. Qt was mentioned, but gtkmm is possible as well and maybe even wxWidgets. The toolkit choice sets the requirement for the event signaling that is needed. Qt has its own signals; gtkmm has GObject signals wrapped in some C++ magic (IIRC). Gnucash/qof has the weird gnucash signals that we hope to get rid of sometime in the future. Trying to mix'n'match the toolkit and signalling frameworks does not work rather well. The cutecash code is Qt but needs to have the signal/slot adapters for our gnucash signals, but they suck. Trying to get Qt widgets receive GObject signals in general should probably be possible, but I haven't found a good implementation last time I checked. C is mostly a subset of C++, so a lot of the work is just renaming and fixing headers. As I said: The language itself is not a sufficient choice. Only stating we want C++ but not choosing a C++ toolkit and signalling framework buys us nothing, because in that case the signals must be written as C function and macro thingies which do not look nice anymore if we're using C++. On the other hand, the code in src/optional/gtkmm/gncmm is already a usable C++ wrapper for the first few business-code classes, using gtkmm and sticking to the gnucash signals, and it works correctly in the cutecash application. This can be used as a basis to do more C++ evaluation. Having said all this, I also have to admit I most probably won't do any work in this direction or in any other direction, as my time budget for gnucash has now gone to zero due to real life work... but the ideas are still there. I thought that you'd found more gainful employ. ;-) Hope it's working out well for you. Agreed, we will at some point have to deal with signals, but there's plenty of engine and backend stuff that can be reimplemented before that. There are also a Boost signals/slots libraries. My main near-term interest is in replacing the rather arcane and verbose GObject typing, construction, destruction, and reference counting with the easier to write and more readable C++ equivalents. As for Gtkmm, it's just a C++ interface wrapped around Gtk+. If we're dumping Gtk+ because we don't like the direction they're going, Gtkmm doesn't get us anywhere. Having argued that C++ in the backend in not such a big deal, I'm going to turn around and point out that dropping Gtk+ in favor of wx, Qt, or some other GUI framework isn't a easy job: That *is* a complete rewrite, and there's a lot of it. Who would do it? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6
On 08-02-13 11:48, Mike Evans wrote: On Fri, 08 Feb 2013 10:13:01 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Last item is on our Feature Schedule [1]: Reversed sort order by date for transaction, a feature Mike Evans has been working on. As far as I can see it's mostly done. I reviewed his patch and gave my feedback. I don't know what kept Mike from completing it. Even as is, the patch is usable and useful already. Re ^: This currently doesn't save the reverse sort setting between runs, and I really didn't like the empty_split being at the bottom when reverse sorting. It is functional for people wanting to compare their on-screen, reverse-sorted bank accounts though. I just ran out of time, enthusiasm, money... I'll commit it as is but subsequent commits mean that the patch is obsolete and I'll have to revisit the code again. I also marked Bug 682732 as a blocker because it simply doesn't work for me. I think we either revert to the old CSV importer or fix the new version. Perhaps others could test it and update the bug. Mike Evans Hi Mike, Thanks for the feedback. I notice you have committed your revisited code in the meantime already. Good ! Though not fully finished, I don't feel the state of the reverse sort is now blocking for feature freeze. The bug you refer to isn't either (for feature freeze). It probably is for release and we will have to look into it before that time. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Gnucash 2.5/6
I am still plodding on with this and it is progressing slowly, have uploaded another patch to the bug which also indicates roughly what is left to do. I am not sure of any time scales but the menu options can be disabled or the whole lot can be removed if it is holding other things up. Assuming it is still viable, I will continue and progress it as time permits. Robert. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6
On 2/9/2013 3:45 PM, Robert Fewell wrote: I am still plodding on with this and it is progressing slowly, have uploaded another patch to the bug which also indicates roughly what is left to do. I am not sure of any time scales but the menu options can be disabled or the whole lot can be removed if it is holding other things up. Assuming it is still viable, I will continue and progress it as time permits. Robert. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel Are you referring to bug 673193? 0xDC7C8BF3.asc Description: application/pgp-keys ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6
On 07-02-13 19:32, John Ralls wrote: Geert mentioned in the Notification Emails thread that he'd like to get 2.6 released in less than a year, and Christian was pushing to do so this time *last* year. On the principle that Release is a misnomer. Software is never released, it escapes. [1], it's probably time to release 2.5.0 so that we can at least start down that road. Shall we say feature freeze now, string freeze in July, 2.6 release 1 November? Or is anyone actively working on features that should go in? What became of the rewrite of the register to GtkTreeView? Failing that, has anyone taken a shot at rewriting it with Cairo instead of libgnome? Note that I'm not proposing a Gtk3 migration for 2.6: We're doing that at Gramps, and MSWin is proving to be troublesome. In fact, it appears that no one is supporting Gtk3-MSWin at the moment. Regards, John Ralls [1] I don't know where that originated. My wife brought it with her from DEC, where it was apparently a truism. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel I like to see a 2.5.0 fairly soon as well. All features I had planned are basically done. They still need a bit of polishing, but are fully functional. The GtkTreeView based register currently has basic functionality, but I haven't seen additional improvements in a while. To be honest, I haven't gotten around to test it more thoroughly. Perhaps Robert Fewell can chime in here. I also recently pinged Phil on switching to GSettings. He said he was going to take that up. I have no additional details, though it would make a nice addition for 2.6 as it would allow us to drop gconf on Windows and OS X. If we want this for 2.6, it will probably need to be a minor first implementation, of the replace-the-current-gconf-code-as-is kind. Not a complete overhaul of our preferences system. I have no idea what plans Phil has exactly, so I'll leave it up to him to give more details of what he's up to and if he considers it realistic to have something for 2.5/2.6. Last item is on our Feature Schedule [1]: Reversed sort order by date for transaction, a feature Mike Evans has been working on. As far as I can see it's mostly done. I reviewed his patch and gave my feedback. I don't know what kept Mike from completing it. Even as is, the patch is usable and useful already. Let's hear what the others have to say. Geert [1] http://wiki.gnucash.org/wiki/Release_Schedule#Feature_Checklist_for_2.6.0 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6
On 07-02-13 19:32, John Ralls wrote: Geert mentioned in the Notification Emails thread that he'd like to get 2.6 released in less than a year, and Christian was pushing to do so this time *last* year. On the principle that Release is a misnomer. Software is never released, it escapes. [1], it's probably time to release 2.5.0 so that we can at least start down that road. Shall we say feature freeze now, string freeze in July, 2.6 release 1 November? Or is anyone actively working on features that should go in? What became of the rewrite of the register to GtkTreeView? Failing that, has anyone taken a shot at rewriting it with Cairo instead of libgnome? Note that I'm not proposing a Gtk3 migration for 2.6: We're doing that at Gramps, and MSWin is proving to be troublesome. In fact, it appears that no one is supporting Gtk3-MSWin at the moment. Regards, John Ralls [1] I don't know where that originated. My wife brought it with her from DEC, where it was apparently a truism. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel Forgot to mention: Gtk3 was indeed not on the agenda for 2.6. 2.6 is only meant to be *ready* to be migrated. This means getting rid of all the deprecated gtk symbols. Other than the register this is done. So the register rewrite is actually important for this goal, whether we use the GtkTreeView approach or the libgnome-cairo route. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6
On Fri, 08 Feb 2013 10:13:01 +0100 Geert Janssens janssens-ge...@telenet.be wrote: On 07-02-13 19:32, John Ralls wrote: Geert mentioned in the Notification Emails thread that he'd like to get 2.6 released in less than a year, and Christian was pushing to do so this time *last* year. On the principle that Release is a misnomer. Software is never released, it escapes. [1], it's probably time to release 2.5.0 so that we can at least start down that road. Shall we say feature freeze now, string freeze in July, 2.6 release 1 November? Or is anyone actively working on features that should go in? What became of the rewrite of the register to GtkTreeView? Failing that, has anyone taken a shot at rewriting it with Cairo instead of libgnome? Note that I'm not proposing a Gtk3 migration for 2.6: We're doing that at Gramps, and MSWin is proving to be troublesome. In fact, it appears that no one is supporting Gtk3-MSWin at the moment. Regards, John Ralls [1] I don't know where that originated. My wife brought it with her from DEC, where it was apparently a truism. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel I like to see a 2.5.0 fairly soon as well. All features I had planned are basically done. They still need a bit of polishing, but are fully functional. The GtkTreeView based register currently has basic functionality, but I haven't seen additional improvements in a while. To be honest, I haven't gotten around to test it more thoroughly. Perhaps Robert Fewell can chime in here. I also recently pinged Phil on switching to GSettings. He said he was going to take that up. I have no additional details, though it would make a nice addition for 2.6 as it would allow us to drop gconf on Windows and OS X. If we want this for 2.6, it will probably need to be a minor first implementation, of the replace-the-current-gconf-code-as-is kind. Not a complete overhaul of our preferences system. I have no idea what plans Phil has exactly, so I'll leave it up to him to give more details of what he's up to and if he considers it realistic to have something for 2.5/2.6. Last item is on our Feature Schedule [1]: Reversed sort order by date for transaction, a feature Mike Evans has been working on. As far as I can see it's mostly done. I reviewed his patch and gave my feedback. I don't know what kept Mike from completing it. Even as is, the patch is usable and useful already. Re ^: This currently doesn't save the reverse sort setting between runs, and I really didn't like the empty_split being at the bottom when reverse sorting. It is functional for people wanting to compare their on-screen, reverse-sorted bank accounts though. I just ran out of time, enthusiasm, money... I'll commit it as is but subsequent commits mean that the patch is obsolete and I'll have to revisit the code again. I also marked Bug 682732 as a blocker because it simply doesn't work for me. I think we either revert to the old CSV importer or fix the new version. Perhaps others could test it and update the bug. Mike Evans Let's hear what the others have to say. Geert [1] http://wiki.gnucash.org/wiki/Release_Schedule#Feature_Checklist_for_2.6.0 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6
Geert Janssens janssens-ge...@telenet.be writes: Forgot to mention: Gtk3 was indeed not on the agenda for 2.6. 2.6 is only meant to be *ready* to be migrated. This means getting rid of all the deprecated gtk symbols. Other than the register this is done. So the register rewrite is actually important for this goal, whether we use the GtkTreeView approach or the libgnome-cairo route. Personnaly I'd rather see us move to Qt instead of Gtk3 when that decision has to be made. My reasoning is that I think the Gtk developers have lost sight of their target audience, and as a result keep removing features that are vital. It's too much of a loose firehose, and IMHO shouldn't be supported anymore. Indeed, for my next desktop re-install I plan to move away from a Gnome desktop and over to XFCE.. Note that this has nothing to do with the 2.6 release, but it's something we should think about when contemplating a move to gtk3. Geert -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 warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6
On Feb 8, 2013, at 7:09 AM, Derek Atkins warl...@mit.edu wrote: Geert Janssens janssens-ge...@telenet.be writes: Forgot to mention: Gtk3 was indeed not on the agenda for 2.6. 2.6 is only meant to be *ready* to be migrated. This means getting rid of all the deprecated gtk symbols. Other than the register this is done. So the register rewrite is actually important for this goal, whether we use the GtkTreeView approach or the libgnome-cairo route. Personnaly I'd rather see us move to Qt instead of Gtk3 when that decision has to be made. My reasoning is that I think the Gtk developers have lost sight of their target audience, and as a result keep removing features that are vital. It's too much of a loose firehose, and IMHO shouldn't be supported anymore. Indeed, for my next desktop re-install I plan to move away from a Gnome desktop and over to XFCE.. Note that this has nothing to do with the 2.6 release, but it's something we should think about when contemplating a move to gtk3. I agree completely, with the additional comment that we should consider wxWidgets as well. However, we should make that decision sooner rather than later: If we're going to drop Gtk, then we should be using C++ and Boost rather than GObject and GLib for backend work. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Beyond 2.6 (was:Re: Gnucash 2.5/6)
On 08-02-13 16:20, John Ralls wrote: On Feb 8, 2013, at 7:09 AM, Derek Atkins warl...@mit.edu wrote: Geert Janssens janssens-ge...@telenet.be writes: Forgot to mention: Gtk3 was indeed not on the agenda for 2.6. 2.6 is only meant to be *ready* to be migrated. This means getting rid of all the deprecated gtk symbols. Other than the register this is done. So the register rewrite is actually important for this goal, whether we use the GtkTreeView approach or the libgnome-cairo route. Personnaly I'd rather see us move to Qt instead of Gtk3 when that decision has to be made. My reasoning is that I think the Gtk developers have lost sight of their target audience, and as a result keep removing features that are vital. It's too much of a loose firehose, and IMHO shouldn't be supported anymore. Indeed, for my next desktop re-install I plan to move away from a Gnome desktop and over to XFCE.. Note that this has nothing to do with the 2.6 release, but it's something we should think about when contemplating a move to gtk3. I agree completely, with the additional comment that we should consider wxWidgets as well. However, we should make that decision sooner rather than later: If we're going to drop Gtk, then we should be using C++ and Boost rather than GObject and GLib for backend work. Regards, John Ralls I did express my interest in Qt before in mails to the list. But when you also want to switch to C++ and Boost, to me that sounds more or less like a complete rewrite of GnuCash. We've had this conversation before, and more or less came to the conclusion we don't have enough man power to do that. Unless such rewrite can be done in baby steps, spread over several releases, say like one module at the time ? Is such a segmentation possible/practical ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.6 (was:Re: Gnucash 2.5/6)
On Feb 8, 2013, at 8:08 AM, Geert Janssens janssens-ge...@telenet.be wrote: On 08-02-13 16:20, John Ralls wrote: On Feb 8, 2013, at 7:09 AM, Derek Atkins warl...@mit.edu wrote: Geert Janssens janssens-ge...@telenet.be writes: Forgot to mention: Gtk3 was indeed not on the agenda for 2.6. 2.6 is only meant to be *ready* to be migrated. This means getting rid of all the deprecated gtk symbols. Other than the register this is done. So the register rewrite is actually important for this goal, whether we use the GtkTreeView approach or the libgnome-cairo route. Personnaly I'd rather see us move to Qt instead of Gtk3 when that decision has to be made. My reasoning is that I think the Gtk developers have lost sight of their target audience, and as a result keep removing features that are vital. It's too much of a loose firehose, and IMHO shouldn't be supported anymore. Indeed, for my next desktop re-install I plan to move away from a Gnome desktop and over to XFCE.. Note that this has nothing to do with the 2.6 release, but it's something we should think about when contemplating a move to gtk3. I agree completely, with the additional comment that we should consider wxWidgets as well. However, we should make that decision sooner rather than later: If we're going to drop Gtk, then we should be using C++ and Boost rather than GObject and GLib for backend work. Regards, John Ralls I did express my interest in Qt before in mails to the list. But when you also want to switch to C++ and Boost, to me that sounds more or less like a complete rewrite of GnuCash. We've had this conversation before, and more or less came to the conclusion we don't have enough man power to do that. Unless such rewrite can be done in baby steps, spread over several releases, say like one module at the time ? Is such a segmentation possible/practical ? C is mostly a subset of C++, so a lot of the work is just renaming and fixing headers. The result will be vastly more readable than what we have now. It will work better with SWIG and Doxygen as well: Both are intended for C++, not C. Yes, it's a long term project -- basically a course change on the existing test and refactor -- to be done in stages. It's not hard to make C and C++ interoperate. There are two running sores in Gnucash's backend, qof/engine and sql/dbi. The former is a memory-management nightmare and the latter is almost-GObject using the heinous tricks without the memory management framework and clarifying macros (did I really say that? ;-) ). There are two ways to clean them up: GObject or C++ (OK, Objective-C would work, too, but it doesn't have the cross-platform advantages of C++). The rationale behind GObject was that a) Qof and Engine are a large part of the way there, though it was applied a bit haphazardly to an existing non-OO code base, and b) Gtk+ compatibility. If Gtk+ is replaced with a C++ GUI, that argues for a C++ backend instead of GObject simply because C++ is *much* easier to write than GObject code, never mind that it produces much better OO code. I'm about halfway through the Transaction testing; Account and Split are done. The only other major class in engine is Lots, and it's not that major, so I think I can write its tests fairly quickly. I plan to start on the cleanup immediately after that's done, so I hope sometime this year. I need to know which way to go. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.6 (was:Re: Gnucash 2.5/6)
Am Freitag, 8. Februar 2013, 09:51:57 schrieb John Ralls: Personnaly I'd rather see us move to Qt instead of Gtk3 when that decision has to be made. I did express my interest in Qt before in mails to the list. But when you also want to switch to C++ and Boost, to me that sounds more or less like a complete rewrite of GnuCash. We've had this conversation before, and more or less came to the conclusion we don't have enough man power to do that. Unless such rewrite can be done in baby steps, spread over several releases, say like one module at the time ? Is such a segmentation possible/practical ? No, switching from C/gtk to C++/whatever in minor steps is in general not possible. When talking about gnucash in C++: Please, don't only make your guesses, but also compile the cutecash part once. There were already some conclusions as for the possibility of going to C++: The choice of C++ is not sufficient; additionally, the GUI toolkit must be chosen as well. Qt was mentioned, but gtkmm is possible as well and maybe even wxWidgets. The toolkit choice sets the requirement for the event signaling that is needed. Qt has its own signals; gtkmm has GObject signals wrapped in some C++ magic (IIRC). Gnucash/qof has the weird gnucash signals that we hope to get rid of sometime in the future. Trying to mix'n'match the toolkit and signalling frameworks does not work rather well. The cutecash code is Qt but needs to have the signal/slot adapters for our gnucash signals, but they suck. Trying to get Qt widgets receive GObject signals in general should probably be possible, but I haven't found a good implementation last time I checked. C is mostly a subset of C++, so a lot of the work is just renaming and fixing headers. As I said: The language itself is not a sufficient choice. Only stating we want C++ but not choosing a C++ toolkit and signalling framework buys us nothing, because in that case the signals must be written as C function and macro thingies which do not look nice anymore if we're using C++. On the other hand, the code in src/optional/gtkmm/gncmm is already a usable C++ wrapper for the first few business-code classes, using gtkmm and sticking to the gnucash signals, and it works correctly in the cutecash application. This can be used as a basis to do more C++ evaluation. Having said all this, I also have to admit I most probably won't do any work in this direction or in any other direction, as my time budget for gnucash has now gone to zero due to real life work... but the ideas are still there. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6
At this point, there's an itch which is bothering me more and it's in the budgeting area. I'm separating the budget plugin page into the page and the budget display widget so I can enhance the widget by adding more info. I want a fixed total column, and fixed income, expense and transfers rows (transfers = transfers to assets or liabilities). GSettings is taking second place to that. Phil From: Geert Janssens janssens-ge...@telenet.be To: gnucash-devel@gnucash.org Sent: Friday, February 8, 2013 4:13:01 AM Subject: Re: Gnucash 2.5/6 On 07-02-13 19:32, John Ralls wrote: Geert mentioned in the Notification Emails thread that he'd like to get 2.6 released in less than a year, and Christian was pushing to do so this time *last* year. On the principle that Release is a misnomer. Software is never released, it escapes. [1], it's probably time to release 2.5.0 so that we can at least start down that road. Shall we say feature freeze now, string freeze in July, 2.6 release 1 November? Or is anyone actively working on features that should go in? What became of the rewrite of the register to GtkTreeView? Failing that, has anyone taken a shot at rewriting it with Cairo instead of libgnome? Note that I'm not proposing a Gtk3 migration for 2.6: We're doing that at Gramps, and MSWin is proving to be troublesome. In fact, it appears that no one is supporting Gtk3-MSWin at the moment. Regards, John Ralls [1] I don't know where that originated. My wife brought it with her from DEC, where it was apparently a truism. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel I like to see a 2.5.0 fairly soon as well. All features I had planned are basically done. They still need a bit of polishing, but are fully functional. The GtkTreeView based register currently has basic functionality, but I haven't seen additional improvements in a while. To be honest, I haven't gotten around to test it more thoroughly. Perhaps Robert Fewell can chime in here. I also recently pinged Phil on switching to GSettings. He said he was going to take that up. I have no additional details, though it would make a nice addition for 2.6 as it would allow us to drop gconf on Windows and OS X. If we want this for 2.6, it will probably need to be a minor first implementation, of the replace-the-current-gconf-code-as-is kind. Not a complete overhaul of our preferences system. I have no idea what plans Phil has exactly, so I'll leave it up to him to give more details of what he's up to and if he considers it realistic to have something for 2.5/2.6. Last item is on our Feature Schedule [1]: Reversed sort order by date for transaction, a feature Mike Evans has been working on. As far as I can see it's mostly done. I reviewed his patch and gave my feedback. I don't know what kept Mike from completing it. Even as is, the patch is usable and useful already. Let's hear what the others have to say. Geert [1] http://wiki.gnucash.org/wiki/Release_Schedule#Feature_Checklist_for_2.6.0 ___ 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: Beyond 2.6 (was:Re: Gnucash 2.5/6)
On Feb 8, 2013, at 1:03 PM, Christian Stimming christ...@cstimming.de wrote: Am Freitag, 8. Februar 2013, 09:51:57 schrieb John Ralls: Personnaly I'd rather see us move to Qt instead of Gtk3 when that decision has to be made. I did express my interest in Qt before in mails to the list. But when you also want to switch to C++ and Boost, to me that sounds more or less like a complete rewrite of GnuCash. We've had this conversation before, and more or less came to the conclusion we don't have enough man power to do that. Unless such rewrite can be done in baby steps, spread over several releases, say like one module at the time ? Is such a segmentation possible/practical ? No, switching from C/gtk to C++/whatever in minor steps is in general not possible. When talking about gnucash in C++: Please, don't only make your guesses, but also compile the cutecash part once. There were already some conclusions as for the possibility of going to C++: The choice of C++ is not sufficient; additionally, the GUI toolkit must be chosen as well. Qt was mentioned, but gtkmm is possible as well and maybe even wxWidgets. The toolkit choice sets the requirement for the event signaling that is needed. Qt has its own signals; gtkmm has GObject signals wrapped in some C++ magic (IIRC). Gnucash/qof has the weird gnucash signals that we hope to get rid of sometime in the future. Trying to mix'n'match the toolkit and signalling frameworks does not work rather well. The cutecash code is Qt but needs to have the signal/slot adapters for our gnucash signals, but they suck. Trying to get Qt widgets receive GObject signals in general should probably be possible, but I haven't found a good implementation last time I checked. C is mostly a subset of C++, so a lot of the work is just renaming and fixing headers. As I said: The language itself is not a sufficient choice. Only stating we want C++ but not choosing a C++ toolkit and signalling framework buys us nothing, because in that case the signals must be written as C function and macro thingies which do not look nice anymore if we're using C++. On the other hand, the code in src/optional/gtkmm/gncmm is already a usable C++ wrapper for the first few business-code classes, using gtkmm and sticking to the gnucash signals, and it works correctly in the cutecash application. This can be used as a basis to do more C++ evaluation. Having said all this, I also have to admit I most probably won't do any work in this direction or in any other direction, as my time budget for gnucash has now gone to zero due to real life work... but the ideas are still there. I thought that you'd found more gainful employ. ;-) Hope it's working out well for you. Agreed, we will at some point have to deal with signals, but there's plenty of engine and backend stuff that can be reimplemented before that. There are also a Boost signals/slots libraries. My main near-term interest is in replacing the rather arcane and verbose GObject typing, construction, destruction, and reference counting with the easier to write and more readable C++ equivalents. As for Gtkmm, it's just a C++ interface wrapped around Gtk+. If we're dumping Gtk+ because we don't like the direction they're going, Gtkmm doesn't get us anywhere. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Gnucash 2.5/6
Geert mentioned in the Notification Emails thread that he'd like to get 2.6 released in less than a year, and Christian was pushing to do so this time *last* year. On the principle that Release is a misnomer. Software is never released, it escapes. [1], it's probably time to release 2.5.0 so that we can at least start down that road. Shall we say feature freeze now, string freeze in July, 2.6 release 1 November? Or is anyone actively working on features that should go in? What became of the rewrite of the register to GtkTreeView? Failing that, has anyone taken a shot at rewriting it with Cairo instead of libgnome? Note that I'm not proposing a Gtk3 migration for 2.6: We're doing that at Gramps, and MSWin is proving to be troublesome. In fact, it appears that no one is supporting Gtk3-MSWin at the moment. Regards, John Ralls [1] I don't know where that originated. My wife brought it with her from DEC, where it was apparently a truism. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
