Re: [GNC-dev] Not getting signal, need a bit of help
Man you're saving my life! Thanks! J. On 4/28/20 8:54 PM, John Ralls wrote: On Apr 28, 2020, at 12:25 PM, jeanl wrote: Devs, As part of launching the reconcile dialog once the matching is done, I'm listening to the response signal from the gnc_ofx_importer_gui (in gnc-ofx-import.c). So right before I launch the GNCImportMainMatcher gnc_ofx_importer_gui I connect to its reponse signal: g_signal_connect (G_OBJECT (gnc_ofx_importer_gui), "response", G_CALLBACK (gnc_ofx_match_done), &info); gnc_gen_trans_list_show_all (gnc_ofx_importer_gui); But it appears I'm not getting the response callback when I close the matcher with either OK or Cancel. Am I missing something obvious? Any help greatly appreciated. I've pushed what I have (temporarily) to add_reconcile_after_ofx_import_master (you can find it in the PRs) if you want to look at more code. Yeah, the GncImportMainMatcher isn't the dialog, its main_widget member is. Do g_signal_connect (G_OBJECT (gnc_gen_trans_list_widget (gnc_ofx_importer_gui), ... Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Not getting signal, need a bit of help
> On Apr 28, 2020, at 12:25 PM, jeanl wrote: > > Devs, > As part of launching the reconcile dialog once the matching is done, I'm > listening to the response signal from the gnc_ofx_importer_gui (in > gnc-ofx-import.c). So right before I launch the GNCImportMainMatcher > gnc_ofx_importer_gui I connect to its reponse signal: > > g_signal_connect (G_OBJECT (gnc_ofx_importer_gui), "response", G_CALLBACK > (gnc_ofx_match_done), &info); > gnc_gen_trans_list_show_all (gnc_ofx_importer_gui); > > But it appears I'm not getting the response callback when I close the > matcher with either OK or Cancel. Am I missing something obvious? > Any help greatly appreciated. I've pushed what I have (temporarily) to > add_reconcile_after_ofx_import_master (you can find it in the PRs) if you > want to look at more code. Yeah, the GncImportMainMatcher isn't the dialog, its main_widget member is. Do g_signal_connect (G_OBJECT (gnc_gen_trans_list_widget (gnc_ofx_importer_gui), ... Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Please keep in mind that budgets may also be used by people with no accounting training, like myself, who get overwhelmed by the terms debit and credit and where each is properly used. On Tue, Apr 28, 2020 at 1:23 PM Adrien Monteleone < adrien.montele...@lusfiber.net> wrote: > > > > On Apr 28, 2020 w18d119, at 9:27 AM, Geert Janssens < > geert.gnuc...@kobaltwit.be> wrote: > > > > What I take from all this is that as long as you display data in two > columns (a debit and a credit) you can follow the logic as you suggest. > > Most likely, that’s what I thought at first too, but I suppose a notation > like “Dr./Cr.” or “D/C” could be used instead, though it might be more > visual clutter than two columns. Two columns might also be much easier to > spot if balances are correct or contra for an account. (such as, "is the > balance in the proper column?”) > > Two columns might also be easier on translators than > abbreviations/notations. > > > > > However numbers are not just meant for displaying, one needs to do > calculations on them as well. And at that point signs will matter. Whether > a certain number increase or decrease your balance is a matter of sign. > > Not necessarily. > > If the equation is treated in code as: > > Assets = Liabilities + Equity > > then those values are all positive. You don’t test for zero, you test for > equality between left and right. (I don’t know if that is more > computationally expensive or not. I’m not as up to par as I should be on > modern processor instructions and what is available.) My conception is the > value of each side would be stored, you then do a <,>,=,!= test. (whichever > seems saner in code and is faster) > > The idea is also that each account would keep debit and credit balances. > (just like in the ’T’ accounts) The overall account balance is the absolute > value of the difference. (still no negative numbers, but a subtraction with > two positives, and the result being positive) > > Whether the balance is represented as Debit or Credit is done by an > additional check for which term was greater before the difference was taken. > > This would happen probably everywhere. (individual transactions, integrity > checks, reports, budgets) > > Again, I don’t know if such logic is more expensive computationally. But > it does model traditional accounting better and removes the need for signs > presentationally, and computationally. > > The only place I might think signs would be appropriate in this case would > be in reports that show variances. (an increase or decrease in absolute > value, without regard to debit or credit) For example, if a Balance Sheet > comparison report (doesn’t exist yet) showed liabilities increased, both > numbers would be positive, as would the variance. If liabilities decreased, > both would be positive with a negative variance. The same would hold for a > multi-period income statement with a variance column (doesn’t exist yet) or > the current budget report, or transaction comparison report. (still > not-official I think) > > Just a few thoughts... > > Regards, > Adrien > > So regardless of how you interpret the equations at some point it all > boils down to dry maths. The exact internal representation is less > important as long as it's consistent. > > > > How to display this internal representation to the user is mostly a > matter of taste. And clearly various opinions on that exist based on user's > background and experience. > > > > > I’m sure there was a reasonable basis for the decision decades ago to > employ > > > the equation in this form, I question whether the reasoning still > holds and > > > posit that it might have produced more work and effort than it has > saved, > > > or will. (not just for developers, but for the many users as well) I > don’t > > > know if this reasoning ever made it into any sort of documentation or > code > > > comments. (I admit, I haven’t looked –yet) > > > > > > I understand that saying such a change would be ‘major’ is a gross > > > understatement. > > > > > :) > > > > > I’ll keep testing the beta build(s) and reporting anything that appears > > > inconsistent with sign treatment, or incorrect with the basic math > results. > > > > Great, thanks for that! > > > > Geert > > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > -- David Carlson ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] iOS app
Hello Geert, After 2 frustrating and unsuccessful attempts to install
development on the Mac, I ended up reverting back to Linux. I have compiled and
ran successfully gnucash on Debian. Do you have a preferred IDE that you use on
Linux?, I haven't used EMACS for almost 15 years and would rather use a newer
IDE/editor. Let me know.
On Thursday, April 23, 2020, 10:09:52 AM PDT, Camille Rizko via
gnucash-devel wrote:
Thank you Geert, I can develop on Linux as well as MacOS. My Linux station
is a portable running Debian 9. My macOS is a workstation with a 26" screen,
obviously a better choice for me.
I did download the source on Linux and went as far as running the cmake but
encountered an error at line 59. Since I prefer the Mac station, I will
download the Mac development and see if I have better luck doing a complete
build.
Once I have a successful build, I will look into app-utils and see what I can
do with it. The objective I assume is to port it to 100% C/C++, for all
platforms, and eventually make it portable and usable by my iOS app.
MacOS and iOS are different OS builds, but they share a common compiler set,
namely Objective C (superset of C/C++) and now SWIFT. The OBJECTs sometimes
differ between MacOS and iOS, but are quite similar otherwise.
On Wednesday, April 22, 2020, 01:37:14 AM PDT, Geert Janssens
wrote:
#yiv1000945645 p, #yiv1000945645 li {white-space:pre-wrap;}
Hi Camille,
There is plenty of work on the gnucash project. However I'll focus on your
eventual goal of basing your iOS app on the gnucash core.
I think your first step would be to familiarize yourself with the gnucash build
system. We have wiki pages describing how to build gnucash on linux, MacOS and
Windows [1]. I assume you are developing on MacOS, so I suggest you follow the
instructions to setup a gnucash build environment on that platform and make
sure you can build gnucash.
When you get to that point, you can start tweaking the build scripts to make
them build only only what you need for the iOS app. I would think in the
gnucash repo itself that would be the contents of libgnucash.
The biggest caveat here is that libgnucash/app-utils still depends quite a bit
on guile, which is not what you'd want for iOS. So here's another opportunity
to help out: rework app-utils to no longer depend on guile. I'll be honest;
that's pretty involved so maybe not a good starting project.
The alternative approach would be to alter the build scripts such we can
specify to build without the gui (already possible by setting WITH_GNUCASH=OFF
to gnucash' cmake invocation) and without guile (which requires a new cmake
parameter, for example WITH_GUILE). If both are set the build should only
include libengine, but then without app-utils. That would probably give you
most of what you need for a first version of the iOS app on top of the gnucash
logic. As the guile separation goal progresses within the gnucash project, more
of app-utils can be included in the minimal build for iOS, giving you even more
features to work with.
Besides the gnucash repo there is the gnucash-on-osx repo which contains the
build system for all of gnucash' dependencies on that platform. As it currently
stands it will build more dependencies than you need for an iOS app. You're
most likely not interested in gtk stuff, though you will still need glib (as
libgnucash is still using it a lot).
gnucash-on-osx uses the jhbuild build system. To help you build only the parts
you need for an iOS app, you can add a new module in gnucash.modules that would
only trigger the build of dependencies for libgnucash instead of all of gnucash.
My experience with building on MacOS is limited and I have no experience at all
with building for iOS so there are certainly things I am missing or glossing
over. For example I have no idea how different the MacOS environment is from
the iOS environment (runtime wise), so I can't tell if there will be a porting
effort involved. I mean the source code of gnucash and its dependencies have
been tweaked to build an run on MacOS. I have no idea whatsoever if extra
tweaking will be required to build for and run on iOS. If so that would be
another task, though I would first try to get the build system to output only
the minimal set of dependencies and gnucash libraries.
I can probably help on the build system side within the gnucash project itself,
like adding the extra switch to disable building with guile. I have a
reasonable notion of how jhbuild works, but I don't have access to a MacOS
system any more. So I can give advice or suggestions on the jhbuild tweaks, but
can test any of those.
Skills you'll probably need or need to develop include: working with git [2],
understanding cmake, working with jhbuild and obviously C and C++.
All changes you make in gnucash-on-osx or gnucash repositories can be submitted
for inclusion via either pull req
[GNC-dev] Not getting signal, need a bit of help
Devs, As part of launching the reconcile dialog once the matching is done, I'm listening to the response signal from the gnc_ofx_importer_gui (in gnc-ofx-import.c). So right before I launch the GNCImportMainMatcher gnc_ofx_importer_gui I connect to its reponse signal: g_signal_connect (G_OBJECT (gnc_ofx_importer_gui), "response", G_CALLBACK (gnc_ofx_match_done), &info); gnc_gen_trans_list_show_all (gnc_ofx_importer_gui); But it appears I'm not getting the response callback when I close the matcher with either OK or Cancel. Am I missing something obvious? Any help greatly appreciated. I've pushed what I have (temporarily) to add_reconcile_after_ofx_import_master (you can find it in the PRs) if you want to look at more code. Jean -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
> On Apr 28, 2020 w18d119, at 9:27 AM, Geert Janssens > wrote: > > What I take from all this is that as long as you display data in two columns > (a debit and a credit) you can follow the logic as you suggest. Most likely, that’s what I thought at first too, but I suppose a notation like “Dr./Cr.” or “D/C” could be used instead, though it might be more visual clutter than two columns. Two columns might also be much easier to spot if balances are correct or contra for an account. (such as, "is the balance in the proper column?”) Two columns might also be easier on translators than abbreviations/notations. > > However numbers are not just meant for displaying, one needs to do > calculations on them as well. And at that point signs will matter. Whether a > certain number increase or decrease your balance is a matter of sign. Not necessarily. If the equation is treated in code as: Assets = Liabilities + Equity then those values are all positive. You don’t test for zero, you test for equality between left and right. (I don’t know if that is more computationally expensive or not. I’m not as up to par as I should be on modern processor instructions and what is available.) My conception is the value of each side would be stored, you then do a <,>,=,!= test. (whichever seems saner in code and is faster) The idea is also that each account would keep debit and credit balances. (just like in the ’T’ accounts) The overall account balance is the absolute value of the difference. (still no negative numbers, but a subtraction with two positives, and the result being positive) Whether the balance is represented as Debit or Credit is done by an additional check for which term was greater before the difference was taken. This would happen probably everywhere. (individual transactions, integrity checks, reports, budgets) Again, I don’t know if such logic is more expensive computationally. But it does model traditional accounting better and removes the need for signs presentationally, and computationally. The only place I might think signs would be appropriate in this case would be in reports that show variances. (an increase or decrease in absolute value, without regard to debit or credit) For example, if a Balance Sheet comparison report (doesn’t exist yet) showed liabilities increased, both numbers would be positive, as would the variance. If liabilities decreased, both would be positive with a negative variance. The same would hold for a multi-period income statement with a variance column (doesn’t exist yet) or the current budget report, or transaction comparison report. (still not-official I think) Just a few thoughts... Regards, Adrien > So regardless of how you interpret the equations at some point it all boils > down to dry maths. The exact internal representation is less important as > long as it's consistent. > > How to display this internal representation to the user is mostly a matter of > taste. And clearly various opinions on that exist based on user's background > and experience. > > > I’m sure there was a reasonable basis for the decision decades ago to employ > > the equation in this form, I question whether the reasoning still holds and > > posit that it might have produced more work and effort than it has saved, > > or will. (not just for developers, but for the many users as well) I don’t > > know if this reasoning ever made it into any sort of documentation or code > > comments. (I admit, I haven’t looked –yet) > > > > I understand that saying such a change would be ‘major’ is a gross > > understatement. > > > :) > > > I’ll keep testing the beta build(s) and reporting anything that appears > > inconsistent with sign treatment, or incorrect with the basic math results. > > Great, thanks for that! > > Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
> On Apr 28, 2020, at 7:27 AM, Geert Janssens > wrote: > > However numbers are not just meant for displaying, one needs to do > calculations on them as > well. And at that point signs will matter. Whether a certain number increase > or decrease your > balance is a matter of sign. Maybe we should change that: Instead of using operator+() and operator-() we could have a balance class with functions credit() and debit(). It would have subclasses AssetBalance, LiabilityBalance, and EquityBalance (or maybe follow the European model and just do ActiveBalance and PassiveBalance) whose overrides of credit() and debit() would do The Right Thing. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 4.0 move windows support to only Windows 10?
Sumit, That's something I've wanted to find time for as well. I haven't yet examined the MS STL code, but I expect that it's based on msvcrt rather than llvm's libc so you'd need to use clang-cl to build a project with it. You'll also need to compile the boost libraries we use (filesystem, system, regex, date_time, and locale) and because of boost::locale, ICU, with clang-cl. In theory you can continue to use the MinGW-w64 dependencies, but in practice that might explode because the C++ binaries will link against msvcrt140 while the MinGW-w64 provided binaries link against the MSYS2 msvcrt. If that's the case then you'll need to use vcpkg to generate as many of the dependencies as it supports and build the rest yourself. Note that boost libraries and GnuCash must be built to the same C++ standard and that GnuCash's CMakeLists.txt specifies C++17. The C++17-using code didn't get finished in time to make it into 4.0 so if necessary you can change it to C++14. Please keep us posted on your progress. Regards, John Ralls > On Apr 28, 2020, at 6:03 AM, Geert Janssens > wrote: > > Hi Sumit, > > We support Windows 8.1 because this version if Windows is still supported by > Microsoft as well albeit only for extended support. > https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet > > Feel free to experiment with clang and MSVC STL. If that can be made to work > in addition to MingW's clang and gcc that's a nice improvement. Whether that > build would run on Windows 8.1 I don't know, and for the moment not that > important. Our official builds can and will continue to use MingW's clang and > gcc for the time being. > > Regards, > > Geert > > Op dinsdag 28 april 2020 09:24:09 CEST schreef Sumit Bhardwaj: > > John et al, > > > > I looked through the release notes for 3.90x and noticed the support for > > Windows 8.1. Is there a specific reason to keep supporting Windows 8.1? Are > > there many users asking for support on Windows 8.1? For reference, Windows > > 10 was released on Jul 29, 2015. > > > > Selfishly, I want to see if I can use a clang with MSVC STL > > (https://github.com/microsoft/stl) to build gnucash on windows and I am not > > sure, what impact Windows 8.1 would have on that? > > > > Thanks, > > Sumit > > > > -Original Message- > > From: gnucash-devel > > On Behalf Of John > > Ralls Sent: Monday, April 27, 2020 21:10 > > To: gnucash-devel > > Subject: [GNC-dev] GnuCash 3.90x Beta Schedule > > > > I trust that everyone noticed that we released the first 3.90x test release > > this evening. We're aiming to release 4.0 on 28 June and there will be a > > final 3.11 release of the 3.x branch at the same time. We don't want to > > risk blowing anything up in that last release, so please commit to maint > > only bug fixes that are straightforward and fix serious bugs. Everything > > else should go to master. > > > > We'll have another test release at the end of May and impose feature freeze > > at that time, meaning that you have 5 weeks to finish up anything > > substantial and get it merged. June should be spent focussing on fixing any > > bugs reported against the new work and important fixes that don't involve > > major surgery. We'll do weekly releases through June to give testers plenty > > of opportunities to keep up with our progress. > > > > One other date of note is string freeze on 14 June. No changes to translated > > strings between 14 June and 28 June to give translators a chance to give us > > the best possible translations--but be nice to them and try really hard to > > keep a lid on new strings from now on. > > > > Any changes to the plan will go on the release schedule at > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.gnuc > > ash.org%2Fwiki%2FRelease_Schedule&data=02%7C01%7C%7C4e8672d90d9b4f570cfd > > 08d7eb2b7f6b%7C84df9e7fe9f640afb435%7C1%7C0%7C637236444364324324 > > &sdata=dKwHmPl0QHVyDC893QYkbBzrNsGE%2FMw6J5pRpnmeVTI%3D&reserved=0. > > > > Regards, > > John Ralls > > > > ___ > > gnucash-devel mailing list > > gnucash-devel@gnucash.org > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnuc > > ash.org%2Fmailman%2Flistinfo%2Fgnucash-devel&data=02%7C01%7C%7C4e8672d90 > > d9b4f570cfd08d7eb2b7f6b%7C84df9e7fe9f640afb435%7C1%7C0%7C6372364 > > 44364324324&sdata=Dc8YbuNMsFbOF85eZ22HLEBaZlMCGLtnx37JWBD4Qdk%3D&res > > erved=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: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Op dinsdag 28 april 2020 15:58:30 CEST schreef Adrien Monteleone: > Geert, > > I concur. > > As long as the internals treat the equation as set to equal zero, then > signage is necessary and it should be consistent. I appreciate the efforts > being made to achieve this. > > My (pie in the sky) request for consideration is the idea that such a > treatment of the equation is inconsistent with accounting texts and > practice (as best I can tell) and should one day be changed so that GnuCash > more closely follows how accountancy treats the equation. This would > eliminate issues with signage as there wouldn’t be any. All ‘normal’ values > (unless contra-balanced) would be positive. (and even then, signage would > still be a display consideration that is based on a choice to not present > the balance as either a debit or credit, but with a sign) > > The equation is: > > Assets = Liabilities + Equity > > It is *not*: > > Assets - Liabilities - Equity = 0 > What I take from all this is that as long as you display data in two columns (a debit and a credit) you can follow the logic as you suggest. However numbers are not just meant for displaying, one needs to do calculations on them as well. And at that point signs will matter. Whether a certain number increase or decrease your balance is a matter of sign. So regardless of how you interpret the equations at some point it all boils down to dry maths. The exact internal representation is less important as long as it's consistent. How to display this internal representation to the user is mostly a matter of taste. And clearly various opinions on that exist based on user's background and experience. > I’m sure there was a reasonable basis for the decision decades ago to employ > the equation in this form, I question whether the reasoning still holds and > posit that it might have produced more work and effort than it has saved, > or will. (not just for developers, but for the many users as well) I don’t > know if this reasoning ever made it into any sort of documentation or code > comments. (I admit, I haven’t looked –yet) > > I understand that saying such a change would be ‘major’ is a gross > understatement. > :) > I’ll keep testing the beta build(s) and reporting anything that appears > inconsistent with sign treatment, or incorrect with the basic math results. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Geert, I concur. As long as the internals treat the equation as set to equal zero, then signage is necessary and it should be consistent. I appreciate the efforts being made to achieve this. My (pie in the sky) request for consideration is the idea that such a treatment of the equation is inconsistent with accounting texts and practice (as best I can tell) and should one day be changed so that GnuCash more closely follows how accountancy treats the equation. This would eliminate issues with signage as there wouldn’t be any. All ‘normal’ values (unless contra-balanced) would be positive. (and even then, signage would still be a display consideration that is based on a choice to not present the balance as either a debit or credit, but with a sign) The equation is: Assets = Liabilities + Equity It is *not*: Assets - Liabilities - Equity = 0 I’m sure there was a reasonable basis for the decision decades ago to employ the equation in this form, I question whether the reasoning still holds and posit that it might have produced more work and effort than it has saved, or will. (not just for developers, but for the many users as well) I don’t know if this reasoning ever made it into any sort of documentation or code comments. (I admit, I haven’t looked –yet) I understand that saying such a change would be ‘major’ is a gross understatement. I’ll keep testing the beta build(s) and reporting anything that appears inconsistent with sign treatment, or incorrect with the basic math results. Regards, Adrien > On Apr 28, 2020 w18d119, at 8:18 AM, Geert Janssens > wrote: > > My simplistic view on this: if there is going to be confusion anyway, let's > at least make it consistent. > > We have the sign reversal strategies in there to alter gnucash number > presentation behavior. To me it would make sense this affects normal > transactions the same way as it would reports as it would budgetting. > > That's currently not the case, which means users have to keep two mental > models in their head: one for transactions (is liability interpreted such or > so, and so on) and another for budgets. I personally think that's a big > hurdle. > > Keep in mind that these reversal strategies (should) only be relevant for the > display of information. Internally numbers should always be stored according > to the signs in the accounting equation. Again budget values didn't follow > this rules. So besides being inconsistent to users it is also inconsistent > and confusing to developers. > > That's what prompted the work to bring this all in line. > > No doubt this may change the interpretation of certain numbers. We can't > avoid this completely. What we had was inconsistent and created > interpretations based on the inconsistent behavior. Change that and the > interpretation has to change with it. > > Regards, > > Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] [GNC] GnuCash 3.902 released
Op dinsdag 28 april 2020 14:55:07 CEST schreef Stan Brown: > On 2020-04-27 17:58, John Ralls wrote: > > The GnuCash development team announces GnuCash 3.902, the first testing > > release for what will soon be GnuCash 4.0. > > > > > > Baseline requirements > > > > Operating Systems: > > • Linux: Ubuntu 18.04LTS > > • MacOS: 10.13 > > • Windows: 8.1 > > Out of curiosity, John, what went into the decision that GC 4.0 would > not work in Windows 7 and Windows 8? > > Or is this just a case of "not supported", as in "it might work, but we > make no guarantees and we won't entertain bug reports"? The latter :) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
My simplistic view on this: if there is going to be confusion anyway, let's at least make it consistent. We have the sign reversal strategies in there to alter gnucash number presentation behavior. To me it would make sense this affects normal transactions the same way as it would reports as it would budgetting. That's currently not the case, which means users have to keep two mental models in their head: one for transactions (is liability interpreted such or so, and so on) and another for budgets. I personally think that's a big hurdle. Keep in mind that these reversal strategies (should) only be relevant for the display of information. Internally numbers should always be stored according to the signs in the accounting equation. Again budget values didn't follow this rules. So besides being inconsistent to users it is also inconsistent and confusing to developers. That's what prompted the work to bring this all in line. No doubt this may change the interpretation of certain numbers. We can't avoid this completely. What we had was inconsistent and created interpretations based on the inconsistent behavior. Change that and the interpretation has to change with it. Regards, Geert Op maandag 27 april 2020 18:59:41 CEST schreef Adrien Monteleone: > I noticed that odd as well. I also noticed it to be odd to choose ‘Inflow’ > for anything but income. > > However, I’m not sure the preface ‘Inflow from’ or ‘Outflow to’ should even > be there. It produces too much confusion with signs. > > Now I have to be concerned with interpreting the sign to be the opposite of > the prefacing term chosen. > > I might be an outlier, but when I budget outlays, I budget positive amounts. > It doesn’t matter if I’m paying a debt or buying something or saving some. > (liability vs. expense, or asset) > > It makes no sense to me to say I’m ‘budgeting negative $100’ on a liability > unless I was pulling money from a liability to make it available to budget. > (thus taking out a loan, similar to pulling money out of savings for > expenses or debt payments) I suppose I could use ‘Income/Expense’ instead > of ‘Credit Accounts’ as my sign reversal strategy but then that messes with > my use of signs for general accounting. > > I see budgeting as a different context and I don’t think it should follow > the same strict adherence to sign preferences. (maybe that is why it didn’t > honor the setting in the first place) > > The entire issue with signs has to do with someone who made the decision to > re-write the accounting equation with all terms on one side and zero on the > other. The real equation given in every text book I’ve seen is not > presented that way. This is partly why a reversal setting exists. > Traditional accounting doesn’t present credit accounts as negative amounts. > Debits and Credits are specifically and strictly not taught as being > ‘positive’ or ’negative’. I know that’s a bigger fish to fry and more > fundamental to the core code, but it seems to be a stumbling block when the > context of the amounts changes. > > I could get over it and manage because I’ve been with GnuCash long enough. > But a fresh new user might well run into an obstacle here. (and some > already do with the general sign issue in the rest of the app) > > Regards, > Adrien > > > On Apr 27, 2020 w18d118, at 9:13 AM, Frank H. Ellenberger > > wrote: > > > > Hi, > > > > Am 27.04.20 um 06:08 schrieb Christopher Lam: > >> [image: budget-view.png] > > > > as translator I have a problem with "Inflow to" in this context. I had > > only expected "Inflow from" and "Outflow to". > > > > Frank > > ___ > 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: [GNC-dev] GnuCash 4.0 move windows support to only Windows 10?
Hi Sumit, We support Windows 8.1 because this version if Windows is still supported by Microsoft as well albeit only for extended support. https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet Feel free to experiment with clang and MSVC STL. If that can be made to work in addition to MingW's clang and gcc that's a nice improvement. Whether that build would run on Windows 8.1 I don't know, and for the moment not that important. Our official builds can and will continue to use MingW's clang and gcc for the time being. Regards, Geert Op dinsdag 28 april 2020 09:24:09 CEST schreef Sumit Bhardwaj: > John et al, > > I looked through the release notes for 3.90x and noticed the support for > Windows 8.1. Is there a specific reason to keep supporting Windows 8.1? Are > there many users asking for support on Windows 8.1? For reference, Windows > 10 was released on Jul 29, 2015. > > Selfishly, I want to see if I can use a clang with MSVC STL > (https://github.com/microsoft/stl) to build gnucash on windows and I am not > sure, what impact Windows 8.1 would have on that? > > Thanks, > Sumit > > -Original Message- > From: gnucash-devel > On Behalf Of John > Ralls Sent: Monday, April 27, 2020 21:10 > To: gnucash-devel > Subject: [GNC-dev] GnuCash 3.90x Beta Schedule > > I trust that everyone noticed that we released the first 3.90x test release > this evening. We're aiming to release 4.0 on 28 June and there will be a > final 3.11 release of the 3.x branch at the same time. We don't want to > risk blowing anything up in that last release, so please commit to maint > only bug fixes that are straightforward and fix serious bugs. Everything > else should go to master. > > We'll have another test release at the end of May and impose feature freeze > at that time, meaning that you have 5 weeks to finish up anything > substantial and get it merged. June should be spent focussing on fixing any > bugs reported against the new work and important fixes that don't involve > major surgery. We'll do weekly releases through June to give testers plenty > of opportunities to keep up with our progress. > > One other date of note is string freeze on 14 June. No changes to translated > strings between 14 June and 28 June to give translators a chance to give us > the best possible translations--but be nice to them and try really hard to > keep a lid on new strings from now on. > > Any changes to the plan will go on the release schedule at > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.gnuc > ash.org%2Fwiki%2FRelease_Schedule&data=02%7C01%7C%7C4e8672d90d9b4f570cfd > 08d7eb2b7f6b%7C84df9e7fe9f640afb435%7C1%7C0%7C637236444364324324 > &sdata=dKwHmPl0QHVyDC893QYkbBzrNsGE%2FMw6J5pRpnmeVTI%3D&reserved=0. > > Regards, > John Ralls > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnuc > ash.org%2Fmailman%2Flistinfo%2Fgnucash-devel&data=02%7C01%7C%7C4e8672d90 > d9b4f570cfd08d7eb2b7f6b%7C84df9e7fe9f640afb435%7C1%7C0%7C6372364 > 44364324324&sdata=Dc8YbuNMsFbOF85eZ22HLEBaZlMCGLtnx37JWBD4Qdk%3D&re s > erved=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: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
No sorry, Windows builds are generated only for maint (3.1x) and master (3.9x eventually 4.x) builds. It would be very disruptive for these branches to receive beta commits and reversals. So, derek's script scans the beta branch on my github fork daily for any changes, and builds a flatpak if it has changed. This way we can be much more certain that a change is acceptable before considering merge onto the mainline builds. BTW thanks warlord. On Tue, 28 Apr 2020 at 11:33, Phil Longstaff wrote: > Is there a windows build? I have a linux vm so might be able to test the > flatpak, but windows would be easier > > On Mon, Apr 27, 2020 at 4:52 PM Christopher Lam > > wrote: > > > Labelling issues aside, is there anyone who would be willing to beta > test? > > > > On Tue, 28 Apr 2020, 2:59 am Adrien Monteleone, < > > adrien.montele...@lusfiber.net> wrote: > > > > > Thanks Phil, so I’m not completely insane then. > > > > > > I too try to remember to factor in signs because GnuCash works that > way. > > I > > > was just throwing in my 2¢ for taking a step back for perspective that > > > maybe can be considered in a future release. (5.0 maybe?) > > > > > > As for danger in generating confusion, the app already throws people at > > > least in the middle of the pool of accounting. Being consistent with > > > accounting text resources might reduce confusion. (in my humble > opinion) > > If > > > texts don’t refer to credit accounts as ’normally negative’, or don’t > > > address or present ’sign’ at all, then people learning on their own > would > > > come to GnuCash and see a similar approach. > > > > > > I presently have my reversed balance accounts setting to ‘Credit > > accounts’ > > > because that way, negative values tell me I have a contra-account > > balance. > > > Short of seeing the balance as Dr. or Cr., that’s the best I can get at > > the > > > moment. > > > > > > Christopher, > > > > > > I’ll add a big ’Thank You’ for tackling this. I understand you have > > > program constraints to work in and can’t re-build the house for the > > kitchen > > > sink. Even if it isn't the optimum, if it is at least consistent and > > works > > > properly, that is better than not. > > > > > > Regards, > > > Adrien > > > > > > > On Apr 27, 2020 w18d118, at 1:43 PM, Phil Longstaff < > > > phil.longst...@gmail.com> wrote: > > > > > > > > I agree with what you say about positive and negative with respect to > > > > budgeting assets and liabilities. However, if I have a transaction > > which > > > > pays down a loan, and then add that loan to the budget report, the > > actual > > > > value is displayed as negative. That is why I budget paying down a > loan > > > > with a negative value. > > > > > > > > I understand what you are saying about budget outlays always being > > > > positive. That also makes sense. However, it doesn't match what > gnucash > > > > currently does. > > > > > > > > Yes, it would be more straightforward to budget either a CR or a DB, > > and > > > > then "amount left to budget" would be sum(DB) - sum(CR). However, > that > > > > would make it more confusing for non-accountants. > > > > > > > > > ___ > > > gnucash-devel mailing list > > > gnucash-devel@gnucash.org > > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > > > > ___ > > gnucash-devel mailing list > > gnucash-devel@gnucash.org > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Is there a windows build? I have a linux vm so might be able to test the flatpak, but windows would be easier On Mon, Apr 27, 2020 at 4:52 PM Christopher Lam wrote: > Labelling issues aside, is there anyone who would be willing to beta test? > > On Tue, 28 Apr 2020, 2:59 am Adrien Monteleone, < > adrien.montele...@lusfiber.net> wrote: > > > Thanks Phil, so I’m not completely insane then. > > > > I too try to remember to factor in signs because GnuCash works that way. > I > > was just throwing in my 2¢ for taking a step back for perspective that > > maybe can be considered in a future release. (5.0 maybe?) > > > > As for danger in generating confusion, the app already throws people at > > least in the middle of the pool of accounting. Being consistent with > > accounting text resources might reduce confusion. (in my humble opinion) > If > > texts don’t refer to credit accounts as ’normally negative’, or don’t > > address or present ’sign’ at all, then people learning on their own would > > come to GnuCash and see a similar approach. > > > > I presently have my reversed balance accounts setting to ‘Credit > accounts’ > > because that way, negative values tell me I have a contra-account > balance. > > Short of seeing the balance as Dr. or Cr., that’s the best I can get at > the > > moment. > > > > Christopher, > > > > I’ll add a big ’Thank You’ for tackling this. I understand you have > > program constraints to work in and can’t re-build the house for the > kitchen > > sink. Even if it isn't the optimum, if it is at least consistent and > works > > properly, that is better than not. > > > > Regards, > > Adrien > > > > > On Apr 27, 2020 w18d118, at 1:43 PM, Phil Longstaff < > > phil.longst...@gmail.com> wrote: > > > > > > I agree with what you say about positive and negative with respect to > > > budgeting assets and liabilities. However, if I have a transaction > which > > > pays down a loan, and then add that loan to the budget report, the > actual > > > value is displayed as negative. That is why I budget paying down a loan > > > with a negative value. > > > > > > I understand what you are saying about budget outlays always being > > > positive. That also makes sense. However, it doesn't match what gnucash > > > currently does. > > > > > > Yes, it would be more straightforward to budget either a CR or a DB, > and > > > then "amount left to budget" would be sum(DB) - sum(CR). However, that > > > would make it more confusing for non-accountants. > > > > > > ___ > > gnucash-devel mailing list > > gnucash-devel@gnucash.org > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 4.0 move windows support to only Windows 10?
John et al, I looked through the release notes for 3.90x and noticed the support for Windows 8.1. Is there a specific reason to keep supporting Windows 8.1? Are there many users asking for support on Windows 8.1? For reference, Windows 10 was released on Jul 29, 2015. Selfishly, I want to see if I can use a clang with MSVC STL (https://github.com/microsoft/stl) to build gnucash on windows and I am not sure, what impact Windows 8.1 would have on that? Thanks, Sumit -Original Message- From: gnucash-devel On Behalf Of John Ralls Sent: Monday, April 27, 2020 21:10 To: gnucash-devel Subject: [GNC-dev] GnuCash 3.90x Beta Schedule I trust that everyone noticed that we released the first 3.90x test release this evening. We're aiming to release 4.0 on 28 June and there will be a final 3.11 release of the 3.x branch at the same time. We don't want to risk blowing anything up in that last release, so please commit to maint only bug fixes that are straightforward and fix serious bugs. Everything else should go to master. We'll have another test release at the end of May and impose feature freeze at that time, meaning that you have 5 weeks to finish up anything substantial and get it merged. June should be spent focussing on fixing any bugs reported against the new work and important fixes that don't involve major surgery. We'll do weekly releases through June to give testers plenty of opportunities to keep up with our progress. One other date of note is string freeze on 14 June. No changes to translated strings between 14 June and 28 June to give translators a chance to give us the best possible translations--but be nice to them and try really hard to keep a lid on new strings from now on. Any changes to the plan will go on the release schedule at https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.gnucash.org%2Fwiki%2FRelease_Schedule&data=02%7C01%7C%7C4e8672d90d9b4f570cfd08d7eb2b7f6b%7C84df9e7fe9f640afb435%7C1%7C0%7C637236444364324324&sdata=dKwHmPl0QHVyDC893QYkbBzrNsGE%2FMw6J5pRpnmeVTI%3D&reserved=0. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-devel&data=02%7C01%7C%7C4e8672d90d9b4f570cfd08d7eb2b7f6b%7C84df9e7fe9f640afb435%7C1%7C0%7C637236444364324324&sdata=Dc8YbuNMsFbOF85eZ22HLEBaZlMCGLtnx37JWBD4Qdk%3D&reserved=0 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
