Re: [GNC-dev] GnuCash 3 on Linux
Wm, I admit freely I do not have a clear understanding of how the reports (and much else inside GnuCash) do work in detail and I doubt if I am alone in that apart from maybe the core development team. GnuCash for whatever historical reasons is only sparsely documented which increases the difficulty of those of us with some development experience, but not long term on GnuCash, to contribute effectively. There is a big learning curve anytime you dig into the code. Having worked in development teams which had very limited resources in the past (I once worked for a boss who thought 3 years of coding to implement a software system to be used by non-physicists for an accelerator based analytical system could be done over the weekend by two people. He still insisted this, after the three year coding effort was completed and both of us had RSI as a result.) GnuCash doesn't have the luxury of a systems analysis team and management structure with oversight either. There is just a minimal team of unpaid developers, often wearing multiple hats, doing their best. Despite that it is far more flexible and adaptable than many programs which do have extensive development teams - hence the escapees from MYOB and Quicken where cost becomes a very significant factor. >Does gnc know where it took stuff from and placed it when 3.x was run >for the first time? Looking at the code which did this, should answer this question. Not easily though, as the code generates scripts which perform the gconf->gsettings ,dconf migration (forced by the deprecation of g conf) as well as the changes in the settings location. My brief excursion into it indicates that it is as described on the wiki Configuration Locations page. What was migrated is defined in /usr/local/share/gnucash/migratable-prefs.xml and processed by /usr/local/share/gnucash/make-prefs-migration-script.xsl to produce the gsettings from the original gconf settings. My experience with the transition from 2.6.19 in my case to v3.0 was that I lost all of the training for the import matcher - no great problem, a couple of imports and it was largely back and that solved some historical import problems which were throwing up accounts which were no longer appropriate. There is some value in occasionally retraining the import matcher in any case. I get by with the basic reports when i need them so i personally had no problems with reports, but I do appreciate that others may/did/do. I kept the 2.6 .gnucash preferences folder from 2.6.19 for some time after i migrated to 3.0in case I went back but unfortunately I decided around 3.3. that for my purposes things had become stable enough that i no longer needed to keep it. If I remember correctly from looking at it at the time I had problems with the importer, what was in /home//.gnucash was moved to /home//.local/share/gnucash on Linux systems as described in the Wiki page on configuration locations. I am presuming this is also he case for Windows systems but I don't really use Windows so can't be sure. >It is a lot more complicated than you think. Wm, 2.6 didn't store the saved reports with the book file either, it just stored them in a different location, so that is clearly not the problem. What are the other changes that were introduced going from 2.6 to 3.x which are causing you problems now in backing up your files that didn't exist with 2.6? You are going to have to be specific if anyone is to diagnose and fix it. I also agree completely that if a report configuration is tied to a specific book/set of accounts, i.e. it has been customised or otherwise been modified to be specific to that book, then its storage location should be with the data file. What defines this level of customisation for you and for me and any other user? Could GnuCash this on the basis of the configuration file contents perhaps decide where a particular report configuartion file should be located? Just saving a custom version of a standard report does not appear to introduce any ties to a specific book, i.e. if I save the standard Balance Sheet as MyBalanceSheet without introducing any references to the account structure of that set of books, the guids in it only reference the guid of the new report and its parent. The other sections in the report configuration General/Accounts/Dsiplay and Commodities, if populated, may obviously change this situation. It may be possible to determine at least a default choice between storage at the book/user/application level based on content, but giving the user the option to override. There is perennial balance between simplicity for a new user through sensible defaults and flexibility for a more experienced or demanding user. Some users may also want to customise reports to be very specific to their personal individual needs and perhaps apply them to any books they maintain. I.e. they would want to store them with what are other user specific preferences. Are ther changes in the saved-reports
Re: [GNC-dev] Building 3.4 on Mint 18.3
Ok, good luck! Geert Op zondag 24 februari 2019 23:55:01 CET schreef Jacob Larsen: > Hi Geert > > I'm starting a backup now to prepare for upgrade, I don't think I will > do more in this direction. I tried this in both Ubuntu Mate 18.04 and > Mint 19.1 in VMs, and both looked fine. So just backing up and running a > long overdue upgrade instead. > > I'm pretty sure Mate runs on X11 though. > > /Jacob > > On 24/02/2019 22.49, Geert Janssens wrote: > > Hi Jacob, > > > > I don't think the missing gwengui-gtk3 package is related. We anticipated > > it would not be available on several distros by the time gnucash 3 would > > be released. So if that package is not found, gnucash will be built with > > an internal copy of this package. So regardless of whether your distro > > ships it, gnucash will have access to a copy. > > In addition, gwengui-gtk3 is only used for online banking stuff. It should > > have no influence whatsoever on the summary bar on that Account hierarchy > > tab. > > > > I have not really much advice to give here as I'm not using Mint. If you > > wish to experiment a bit further, you may try to run gnucash from a > > different desktop and/or figure out whether Linux Mint/Mate is running on > > a Wayland compositor or an X11 one. > > > > Regards, > > > > Geert > > > > Op zondag 24 februari 2019 22:14:44 CET schreef Jacob Larsen: > >> Hi Geert > >> > >> This is Mint on the Mate desktop. I found this from the configure log > >> that seems related: "No package 'gwengui-gtk3' found" > >> > >> This package is not available in the Ubuntu 16.04 base, but was > >> introduced in 18.04. If this package is critical to GnuCash then it > >> seems the configure script has a bug here. I can see that I have the > >> gtk2 version of the package installed, perhaps that causes the confusion? > >> > >> I'm not sure I will get closer to this. I have been putting off an > >> upgrade for far too long and it is probably easier to do the upgrade and > >> try again. > >> > >> /Jacob > >> > >> On 24/02/2019 00.39, Geert Janssens wrote: > >>> The summary bar is using stock gtk widgets. So if there's a library > >>> dependency issue it would be gtk or one of its dependencies. > >>> > >>> Note gnucash switched from gtk2 to gtk3 between gnucash 2.6 and 3. This > >>> has > >>> lots of visual side effects because gtk3's default styling is quite > >>> different from gtk2's. > >>> > >>> This shows in lots of ways. Increased padding in various places (like in > >>> the register as you mention) is one example. > >>> > >>> I don't see the summary bar inflation on Fedora 29, though the summary > >>> bar > >>> pop-up is not really consistent in where it pops up. It's usually way > >>> too > >>> high. > >>> > >>> What desktop environment are you using on Mint 18.3 ? And is it using > >>> Wayland or X11 ? If it is Wayland, can you try an X11 session ? > >>> > >>> Geert > >>> > >>> Op zaterdag 23 februari 2019 23:41:12 CET schreef Jacob Larsen: > Hi > > Not sure if this is a dev or user question, but I suspect the people > who > can answer are devs. > > I am trying to get 3.4 to run on Mint 18.3 (Ubuntu 16.04 base). I have > gotten it to build, but the summary bar on the accounts tab is screwed > up. If I click it, it looks somewhat fine, but if I close it, it is > about three times as high as it should be, and there are no numbers on > it. Also, all the fields seem to clutter together on the left side. > > Not much of an issue, but it might be relevant. It seems like the font > used for transactions in the ledger has slightly bigger spacing around > the text compared to my previous version (2.6) > > I'm guessing this is probably a dependency thing, but can somebody help > narrow down which one? Which lib is used for this summary bar. > > /Jacob > > ___ > 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] Building 3.4 on Mint 18.3
Hi Geert I'm starting a backup now to prepare for upgrade, I don't think I will do more in this direction. I tried this in both Ubuntu Mate 18.04 and Mint 19.1 in VMs, and both looked fine. So just backing up and running a long overdue upgrade instead. I'm pretty sure Mate runs on X11 though. /Jacob On 24/02/2019 22.49, Geert Janssens wrote: Hi Jacob, I don't think the missing gwengui-gtk3 package is related. We anticipated it would not be available on several distros by the time gnucash 3 would be released. So if that package is not found, gnucash will be built with an internal copy of this package. So regardless of whether your distro ships it, gnucash will have access to a copy. In addition, gwengui-gtk3 is only used for online banking stuff. It should have no influence whatsoever on the summary bar on that Account hierarchy tab. I have not really much advice to give here as I'm not using Mint. If you wish to experiment a bit further, you may try to run gnucash from a different desktop and/or figure out whether Linux Mint/Mate is running on a Wayland compositor or an X11 one. Regards, Geert Op zondag 24 februari 2019 22:14:44 CET schreef Jacob Larsen: Hi Geert This is Mint on the Mate desktop. I found this from the configure log that seems related: "No package 'gwengui-gtk3' found" This package is not available in the Ubuntu 16.04 base, but was introduced in 18.04. If this package is critical to GnuCash then it seems the configure script has a bug here. I can see that I have the gtk2 version of the package installed, perhaps that causes the confusion? I'm not sure I will get closer to this. I have been putting off an upgrade for far too long and it is probably easier to do the upgrade and try again. /Jacob On 24/02/2019 00.39, Geert Janssens wrote: The summary bar is using stock gtk widgets. So if there's a library dependency issue it would be gtk or one of its dependencies. Note gnucash switched from gtk2 to gtk3 between gnucash 2.6 and 3. This has lots of visual side effects because gtk3's default styling is quite different from gtk2's. This shows in lots of ways. Increased padding in various places (like in the register as you mention) is one example. I don't see the summary bar inflation on Fedora 29, though the summary bar pop-up is not really consistent in where it pops up. It's usually way too high. What desktop environment are you using on Mint 18.3 ? And is it using Wayland or X11 ? If it is Wayland, can you try an X11 session ? Geert Op zaterdag 23 februari 2019 23:41:12 CET schreef Jacob Larsen: Hi Not sure if this is a dev or user question, but I suspect the people who can answer are devs. I am trying to get 3.4 to run on Mint 18.3 (Ubuntu 16.04 base). I have gotten it to build, but the summary bar on the accounts tab is screwed up. If I click it, it looks somewhat fine, but if I close it, it is about three times as high as it should be, and there are no numbers on it. Also, all the fields seem to clutter together on the left side. Not much of an issue, but it might be relevant. It seems like the font used for transactions in the ledger has slightly bigger spacing around the text compared to my previous version (2.6) I'm guessing this is probably a dependency thing, but can somebody help narrow down which one? Which lib is used for this summary bar. /Jacob ___ 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] Building 3.4 on Mint 18.3
Hi Jacob, I don't think the missing gwengui-gtk3 package is related. We anticipated it would not be available on several distros by the time gnucash 3 would be released. So if that package is not found, gnucash will be built with an internal copy of this package. So regardless of whether your distro ships it, gnucash will have access to a copy. In addition, gwengui-gtk3 is only used for online banking stuff. It should have no influence whatsoever on the summary bar on that Account hierarchy tab. I have not really much advice to give here as I'm not using Mint. If you wish to experiment a bit further, you may try to run gnucash from a different desktop and/or figure out whether Linux Mint/Mate is running on a Wayland compositor or an X11 one. Regards, Geert Op zondag 24 februari 2019 22:14:44 CET schreef Jacob Larsen: > Hi Geert > > This is Mint on the Mate desktop. I found this from the configure log > that seems related: "No package 'gwengui-gtk3' found" > > This package is not available in the Ubuntu 16.04 base, but was > introduced in 18.04. If this package is critical to GnuCash then it > seems the configure script has a bug here. I can see that I have the > gtk2 version of the package installed, perhaps that causes the confusion? > > I'm not sure I will get closer to this. I have been putting off an > upgrade for far too long and it is probably easier to do the upgrade and > try again. > > /Jacob > > On 24/02/2019 00.39, Geert Janssens wrote: > > The summary bar is using stock gtk widgets. So if there's a library > > dependency issue it would be gtk or one of its dependencies. > > > > Note gnucash switched from gtk2 to gtk3 between gnucash 2.6 and 3. This > > has > > lots of visual side effects because gtk3's default styling is quite > > different from gtk2's. > > > > This shows in lots of ways. Increased padding in various places (like in > > the register as you mention) is one example. > > > > I don't see the summary bar inflation on Fedora 29, though the summary bar > > pop-up is not really consistent in where it pops up. It's usually way too > > high. > > > > What desktop environment are you using on Mint 18.3 ? And is it using > > Wayland or X11 ? If it is Wayland, can you try an X11 session ? > > > > Geert > > > > Op zaterdag 23 februari 2019 23:41:12 CET schreef Jacob Larsen: > >> Hi > >> > >> Not sure if this is a dev or user question, but I suspect the people who > >> can answer are devs. > >> > >> I am trying to get 3.4 to run on Mint 18.3 (Ubuntu 16.04 base). I have > >> gotten it to build, but the summary bar on the accounts tab is screwed > >> up. If I click it, it looks somewhat fine, but if I close it, it is > >> about three times as high as it should be, and there are no numbers on > >> it. Also, all the fields seem to clutter together on the left side. > >> > >> Not much of an issue, but it might be relevant. It seems like the font > >> used for transactions in the ledger has slightly bigger spacing around > >> the text compared to my previous version (2.6) > >> > >> I'm guessing this is probably a dependency thing, but can somebody help > >> narrow down which one? Which lib is used for this summary bar. > >> > >> /Jacob > >> > >> ___ > >> 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] Building 3.4 on Mint 18.3
Hi Geert This is Mint on the Mate desktop. I found this from the configure log that seems related: "No package 'gwengui-gtk3' found" This package is not available in the Ubuntu 16.04 base, but was introduced in 18.04. If this package is critical to GnuCash then it seems the configure script has a bug here. I can see that I have the gtk2 version of the package installed, perhaps that causes the confusion? I'm not sure I will get closer to this. I have been putting off an upgrade for far too long and it is probably easier to do the upgrade and try again. /Jacob On 24/02/2019 00.39, Geert Janssens wrote: The summary bar is using stock gtk widgets. So if there's a library dependency issue it would be gtk or one of its dependencies. Note gnucash switched from gtk2 to gtk3 between gnucash 2.6 and 3. This has lots of visual side effects because gtk3's default styling is quite different from gtk2's. This shows in lots of ways. Increased padding in various places (like in the register as you mention) is one example. I don't see the summary bar inflation on Fedora 29, though the summary bar pop-up is not really consistent in where it pops up. It's usually way too high. What desktop environment are you using on Mint 18.3 ? And is it using Wayland or X11 ? If it is Wayland, can you try an X11 session ? Geert Op zaterdag 23 februari 2019 23:41:12 CET schreef Jacob Larsen: Hi Not sure if this is a dev or user question, but I suspect the people who can answer are devs. I am trying to get 3.4 to run on Mint 18.3 (Ubuntu 16.04 base). I have gotten it to build, but the summary bar on the accounts tab is screwed up. If I click it, it looks somewhat fine, but if I close it, it is about three times as high as it should be, and there are no numbers on it. Also, all the fields seem to clutter together on the left side. Not much of an issue, but it might be relevant. It seems like the font used for transactions in the ledger has slightly bigger spacing around the text compared to my previous version (2.6) I'm guessing this is probably a dependency thing, but can somebody help narrow down which one? Which lib is used for this summary bar. /Jacob ___ 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 3 on Linux
On 24/02/2019 16:51, Geert Janssens wrote: Op zondag 24 februari 2019 12:54:35 CET schreef Wm via gnucash-devel: On 24/02/2019 02:25, David Cousens wrote: Wm, David, I appreciate your efforts as peacemaker, don't give up on all of us yet, most of us are trying to be good, promise :) If you draw a diagram from the information in the wiki page https://wiki.gnucash.org/wiki/Configuration_Locations where the meta data and report data is stored becomes fairly obvious and is fairly simple. I disagree, the user doesn't always know where their stuff is and therefore can't make a sensible backup. We (gnc) have a theory about where stuff should be but in practice it could be just about anywhere. My argument is that we should put important stuff near or approximate to the data it relates to rather than further away from it. There was considerable discussion in the forums at the time the changes were being made from 2.6 to 3.0. Not all views were heard. Taking a poll and not listening to the views that disagree with you is ordinary. This has ended up with me saying Geert (a person I respect enormously) may be a liar :( Sigh... Let it be clear the current thread is mixing up several discussions. 1. I agree (and always have) that certain data (like saved reports) is stored in the wrong place, namely in the metadata directory instead of in the gnucash data file. Near the data file is fine, it doesn't have to be inside it. the stored reports mechanism is imperfect but OK so long as we can keep a close association with the data the reports are reporting on. I'm not the only person that has noticed that stored reports are essentially useless when not associated with the data to which they belong. Are you unusually stupid in this regard? This has been historically so and hasn't changed between gnucash 2.6 and 3. Not true, there was a structural change between 2.x and 3.x The same data is still stored in locations reserved for application internal housekeeping (metadata). I'm listening to you trying to work out what you did wrong. 2. In the preparations to line up to gnucash 3 I decided to do some lower level housekeeping, namely to move everything that was *already stored* in the historical metadata/config directory ($HOME/.gnucash on linux) into present day recommended locations per platform ($HOME/.config/gnucash and $HOME/.local/share/gnucash on linux). I think that was unwise, let's continue. On MacOS this was already the case so nothing changed there. On windows the move was from $HOME/.gnucash to %APPDATA%\GnuCash, the default location on Windows *and* a request by several users that didn't like the .gnucash in their $HOME. Hmmmn, OK, you can make it my fault for not being strong enough in objecting. Is that what you want me to say? I honestly didn't believe gnc would do such a stupid thing. It was never my aim at that point to do the bigger cleanup of sorting out which stuff that was in separate metadata files should really be moved into the gnucash data file. But that is what happened and, I think, can't be undone now. https://bugs.gnucash.org/show_bug.cgi?id=797117 That's a completely different work that should still happen somewhere further down in the current big refactoring. I think it is too late. In further discussions, let's try to be clear please about what aspect is being discussed. I'd like you to address the bug, remember this all started with someone asking what to back up and no senior person from gnc having an answer. *you* put the metadata somewhere and *you* don't know where it is. shame on you. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
Op zondag 24 februari 2019 19:36:37 CET schreef Wm via gnucash-devel: > On 24/02/2019 17:08, Geert Janssens wrote: > > You do like misinterpreting other peoples words to your benefit... > > Only if necessary. I have never seen you like this before. > > > I never said it was a requirement to get gnc implemented on Windows. I > > said > > gnucash chose to better integrate with each platform. > > mixed words, no argument from me. The 2.x to 3.x changes affected all > platforms I am aware of, see the start of the thread. > > > And please re-read my other message. We're talking in different contexts. > > You continue to discuss on the level of what should be considered > > metadata and what should be part of the gnucash data itself. > > Are you saying my understanding of metadata is wrong? If so we can > certainly discuss that in another thread. > > > I'm only talking default > > metadata locations itself > > I've seen this before, you are narrowing the available space you might > be responsible for. > > Doesn't work for me, Geert. > > >as that's the only aspect in this context that has > > > > changed in gnucash 3.x. That some data should not be considered metadata > > is > > not under debate. We agree on that. > > Oh...kay > > help me to understand what you think is and isn't gnc's responsibility. > > You don't give a donder about reports, right? They're just occasional drek. > > It doesn't matter to you that someone took months getting a budget > together and producing a report on that budget to satisfy their > Trustees. You thought it was a good idea to just move a whole bunch of > stuff to someone else's computer leaving no trace of the work behind. > > The thing that pisses me off is that you appear to be defending this > harmful decision rather than apologizing. > > I have never in all my years of work with gnc seen you behave like this > before, Geert, it seems to me you are running backwards faster than your > legs will work. Huh? What you're writing here just doesn't make sense to me. If you want me to work with you you'll have to provide me with the exact problem you are facing instead of vague generalisms and suggestions. You may have done so before but given the low signal to noise ratio of much of the conversation about this I may have missed it. Then I can work out what's wrong if anything and look for a solution. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 17:08, Geert Janssens wrote: You do like misinterpreting other peoples words to your benefit... Only if necessary. I have never seen you like this before. I never said it was a requirement to get gnc implemented on Windows. I said gnucash chose to better integrate with each platform. mixed words, no argument from me. The 2.x to 3.x changes affected all platforms I am aware of, see the start of the thread. And please re-read my other message. We're talking in different contexts. You continue to discuss on the level of what should be considered metadata and what should be part of the gnucash data itself. Are you saying my understanding of metadata is wrong? If so we can certainly discuss that in another thread. I'm only talking default metadata locations itself I've seen this before, you are narrowing the available space you might be responsible for. Doesn't work for me, Geert. as that's the only aspect in this context that has changed in gnucash 3.x. That some data should not be considered metadata is not under debate. We agree on that. Oh...kay help me to understand what you think is and isn't gnc's responsibility. You don't give a donder about reports, right? They're just occasional drek. It doesn't matter to you that someone took months getting a budget together and producing a report on that budget to satisfy their Trustees. You thought it was a good idea to just move a whole bunch of stuff to someone else's computer leaving no trace of the work behind. The thing that pisses me off is that you appear to be defending this harmful decision rather than apologizing. I have never in all my years of work with gnc seen you behave like this before, Geert, it seems to me you are running backwards faster than your legs will work. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
Op zondag 24 februari 2019 16:23:24 CET schreef Wm via gnucash-devel: > On 24/02/2019 01:06, David Carlson wrote: > > No, it is the name calling and digression from real subject matter. > > I had to do the name calling because no-one was paying attention. The more name calling you do the less I'm inclined to read though. I think I have read at most half of what you have written the last few days because I found the signal to noise ratio too low. Just so you know the effectiveness of your strategy... Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
Op zondag 24 februari 2019 17:19:09 CET schreef Wm via gnucash-devel: > On 24/02/2019 03:12, David Cousens wrote: > > Wm > > > > You could have a startup script which copied a common user config file for > > GnuCash from a backup or other central location to each users home > > directory and then copied it back on exit. > > > > On Linux the files would be those in the directories: > > > > /home//.local/share/gnucash (all user data) > > /home//.config/gnucash (gnucash config data) > > /home//.local/share/gtk-3.0(gtk data) > > /home//.config/gtk-3.0 (gtk config) > > > > On Windows they should be in > > > > c:\Users\\AppData\Local\GnuCash or > > c:\Users\\AppData\Local\gtk-3.0 > > > > OR > > > > c:\Users\\AppData\Roaming\GnuCash > > c:\Users\\AppData\Roaming\gtk-3.0 > > > > Don't know enough about Windoze anymore to know which set is most likely > > to > > be used but this link has an explanation > > https://www.makeuseof.com/tag/appdata-roaming-vs-local/ > > > > If you only wanted to back up the reports not just all user data, you > > could > > just backup the > > saved-reports-. from the requisite directories and just restore that > > file from a backup or other central copy stored with the main book file. > > It is a lot more complicated than you think. > > Let me open this part of the discussion by saying: > > Does gnc know where it took stuff from and placed it when 3.x was run > for the first time? > > We know this was a one way change but were the from and to locations > known about and recorded? > > I think they weren't all known about and recorded and gnc has > contributed to actual data loss. <-- not something I ever wanted to say > as this was warned about and avoidable. The warnings were ignored. Looks like you are now lying in public... (using your own conversation style here). Nothing gets deleted by the migration so there can't be data loss. If the migration was actually triggered all files from DOT_GNUCASH_DIR have been *copied* to either GNC_DATA_HOME or GNC_CONFIG_HOME. You can look up the exact locations per platform on https://wiki.gnucash.org/wiki/ Configuration_Locations. The original files are still in DOT_GNUCASH_DIR. Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
Op zondag 24 februari 2019 14:50:27 CET schreef Wm via gnucash-devel: > On 24/02/2019 08:44, Geert Janssens wrote: > > Completely agree in today's context. There have been reasons in the past > > it > > was done as it is. If someone has spare time and epxerience I gladly > > accept > > patches to fix this technical debt. > > There was nothing to fix in this regard in gnc 2.x > > gnc 3.x changed things, do *not* try and escape this, Geert! > > gnc 3.x made things worse not better in this regard. Understand? > You are entitled to your opinion of course. But I disagree. > >> The fact that we even need a wiki page dedicated to file and > >> configuration > >> locations-- let alone one as long and convoluted as the one we have (and > >> which needs additional diagramming)-- only underscores this problem. > > > > No, it underscores the dev team's willingness to be as open as possible > > about the complexities of a mature cross-platform application. Many > > applications store (meta)data is locations defined by the context. > > I know what you are saying, Geert, you are also wrong. The > implementation of those concepts in gnc 3.x is a disaster for some, e.g > I have charities that cannot use gnc 3.x > > I must ask again, because I do not want to shoot the messenger, who > thought this change from 2.x to 3.x was a good idea? Who proposed it? What changes exactly are you referring to ? What changes prevent charities from using gnc 3.x ? > Did the person that proposed it understand what they were suggesting > meant for all people or just for themselves? > > This change is fundamentally wrong to what I understand the gnc ethos to > be. People should have access to their own data, people should control > their own data, people's data should be where they expect it to be. > > Geert, the way you are talking it sounds like you voted for Facebook. > If you want me to continue this conversation with you, I'd suggest you stick to the topic. > > Go search for > > libreoffice's metadata for example, or firefox'. If you would want to > > document their metadata structures, you'd see something similar or even > > more complex. > I know both those programs and know where they store stuff. You may > recall I mentioned portableapps.com a while ago so don't be surprised > /someone else knows about where other apps put stuff. > > In short, documenting metdata structures about gnc is mainly done. So > shut up and do something useful, please. > > > Part of the complexity comes from the multi-platform nature of gnucash. > > Each platform defines their own default locations for various kinds of > > data. And gnucash tries to apply these per platform. > > Geert: I think you just made another lie in pubic. > > The question is: should it? It is a lie that where to put files was an > issue in getting gnc implemented on Windows. > You do like misinterpreting other peoples words to your benefit... I never said it was a requirement to get gnc implemented on Windows. I said gnucash chose to better integrate with each platform. And please re-read my other message. We're talking in different contexts. You continue to discuss on the level of what should be considered metadata and what should be part of the gnucash data itself. I'm only talking default metadata locations itself as that's the only aspect in this context that has changed in gnucash 3.x. That some data should not be considered metadata is not under debate. We agree on that. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
Op zondag 24 februari 2019 12:54:35 CET schreef Wm via gnucash-devel: > On 24/02/2019 02:25, David Cousens wrote: > > Wm, > > David, I appreciate your efforts as peacemaker, don't give up on all of > us yet, most of us are trying to be good, promise :) > > > If you draw a diagram from the information in the wiki page > > https://wiki.gnucash.org/wiki/Configuration_Locations > > where the meta data and report data is stored becomes fairly obvious and > > is fairly simple. > > I disagree, the user doesn't always know where their stuff is and > therefore can't make a sensible backup. We (gnc) have a theory about > where stuff should be but in practice it could be just about anywhere. > > My argument is that we should put important stuff near or approximate to > the data it relates to rather than further away from it. > > > There was considerable discussion in the forums at the time the changes > > were being made from 2.6 to 3.0. > > Not all views were heard. Taking a poll and not listening to the views > that disagree with you is ordinary. > > This has ended up with me saying Geert (a person I respect enormously) > may be a liar :( > Sigh... Let it be clear the current thread is mixing up several discussions. 1. I agree (and always have) that certain data (like saved reports) is stored in the wrong place, namely in the metadata directory instead of in the gnucash data file. This has been historically so and hasn't changed between gnucash 2.6 and 3. The same data is still stored in locations reserved for application internal housekeeping (metadata). 2. In the preparations to line up to gnucash 3 I decided to do some lower level housekeeping, namely to move everything that was *already stored* in the historical metadata/config directory ($HOME/.gnucash on linux) into present day recommended locations per platform ($HOME/.config/gnucash and $HOME/.local/share/gnucash on linux). On MacOS this was already the case so nothing changed there. On windows the move was from $HOME/.gnucash to %APPDATA%\GnuCash, the default location on Windows *and* a request by several users that didn't like the .gnucash in their $HOME. It was never my aim at that point to do the bigger cleanup of sorting out which stuff that was in separate metadata files should really be moved into the gnucash data file. That's a completely different work that should still happen somewhere further down in the current big refactoring. In further discussions, let's try to be clear please about what aspect is being discussed. Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 03:12, David Cousens wrote: Wm You could have a startup script which copied a common user config file for GnuCash from a backup or other central location to each users home directory and then copied it back on exit. On Linux the files would be those in the directories: /home//.local/share/gnucash (all user data) /home//.config/gnucash (gnucash config data) /home//.local/share/gtk-3.0(gtk data) /home//.config/gtk-3.0 (gtk config) On Windows they should be in c:\Users\\AppData\Local\GnuCash or c:\Users\\AppData\Local\gtk-3.0 OR c:\Users\\AppData\Roaming\GnuCash c:\Users\\AppData\Roaming\gtk-3.0 Don't know enough about Windoze anymore to know which set is most likely to be used but this link has an explanation https://www.makeuseof.com/tag/appdata-roaming-vs-local/ If you only wanted to back up the reports not just all user data, you could just backup the saved-reports-. from the requisite directories and just restore that file from a backup or other central copy stored with the main book file. It is a lot more complicated than you think. Let me open this part of the discussion by saying: Does gnc know where it took stuff from and placed it when 3.x was run for the first time? We know this was a one way change but were the from and to locations known about and recorded? I think they weren't all known about and recorded and gnc has contributed to actual data loss. <-- not something I ever wanted to say as this was warned about and avoidable. The warnings were ignored. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On Sun, 24 Feb 2019 at 15:21, Wm via gnucash-devel wrote: > > That is the point, dear, you may not have said a swearword but what you > are supporting is shameful. Please don't call me dear. That is almost as bad as labelling me a Trump supporter. I don't understand what it is you think I am supporting, all I am supporting here is gnucash and civility. Colin ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 01:06, David Carlson wrote: No, it is the name calling and digression from real subject matter. I had to do the name calling because no-one was paying attention. I'd prefer it if I was listened to the first time, promise. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 09:19, Colin Law wrote: On Sat, 23 Feb 2019 at 23:28, Wm via gnucash-devel wrote: ... You, Colin Law, seem to be the sort of person that votes for Trump because you aren't bothered if a black women gets shot. I fail to see what I have done to be so vilely abused as to be accused of being a Trump supporter or being a racist. If you are neither you have nothing to be afraid of. Also I fail to see what I said that so angered you. I merely expressed surprise that you use Gnucash when you have such a low opinion of the developers. How you can trust their work to look after your financial data when you consider them so incompetent I don't know. I have a good understanding of the tx gnc works on top of. As for my desire not to post words that may offend others then that is why I do it, so as not to offend. I have grandchildren and if they should happen to google my name and come up with my posts I would not want to be ashamed of what I have written. Some obviously are not worried about offending others. That is the point, dear, you may not have said a swearword but what you are supporting is shameful. I, unlike you, will have the pride of going to my grave honest and expressive. There aren't that many people like you out there, Colin Law, and you should let this community know which side you are on. Which side of what? Good accounting for people. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 08:44, Geert Janssens wrote: Yes, unfortunately this isn't very user friendly. I'm sure it can be improved. Again it requires someone with time available and coding experience to implement it. Not really, 2. was better than 3. in this regard; let's just go back is my suggestion. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 08:44, Geert Janssens wrote: Completely agree in today's context. There have been reasons in the past it was done as it is. If someone has spare time and epxerience I gladly accept patches to fix this technical debt. There was nothing to fix in this regard in gnc 2.x gnc 3.x changed things, do *not* try and escape this, Geert! gnc 3.x made things worse not better in this regard. Understand? The fact that we even need a wiki page dedicated to file and configuration locations-- let alone one as long and convoluted as the one we have (and which needs additional diagramming)-- only underscores this problem. No, it underscores the dev team's willingness to be as open as possible about the complexities of a mature cross-platform application. Many applications store (meta)data is locations defined by the context. I know what you are saying, Geert, you are also wrong. The implementation of those concepts in gnc 3.x is a disaster for some, e.g I have charities that cannot use gnc 3.x I must ask again, because I do not want to shoot the messenger, who thought this change from 2.x to 3.x was a good idea? Who proposed it? Did the person that proposed it understand what they were suggesting meant for all people or just for themselves? This change is fundamentally wrong to what I understand the gnc ethos to be. People should have access to their own data, people should control their own data, people's data should be where they expect it to be. Geert, the way you are talking it sounds like you voted for Facebook. Go search for libreoffice's metadata for example, or firefox'. If you would want to document their metadata structures, you'd see something similar or even more complex. I know both those programs and know where they store stuff. You may recall I mentioned portableapps.com a while ago so don't be surprised /someone else knows about where other apps put stuff. In short, documenting metdata structures about gnc is mainly done. So shut up and do something useful, please. Part of the complexity comes from the multi-platform nature of gnucash. Each platform defines their own default locations for various kinds of data. And gnucash tries to apply these per platform. Geert: I think you just made another lie in pubic. The question is: should it? It is a lie that where to put files was an issue in getting gnc implemented on Windows. gnucash should be thinking for itself. if you go for the "each platform says where things should go" I will have access to your file and you will have access to mine in one years time. Try using your fucking brain for independent thought once! I want to be clear that I am truly grateful that Chris has decided to work on reports, and I have great respect for his ability to work with Scheme. I've yet to succeed in either editing an existing report or getting a third party report installed on my Mac. 13 years of futility on that front! Yes, unfortunately this isn't very user friendly. I'm sure it can be improved. Again it requires someone with time available and coding experience to implement it. There is no person with coding experience available, get used to it. Move on. I also notice that I am being told to move on, who do you think is right or wrong, Geert? -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 10:45, David T. via gnucash-devel wrote: Adrien, Using configuration files as a mechanism for working around the significant shortcomings of the reports ecosystem in Gnucash is tortured logic, at best. To be clear, I understand the challenges facing the team-- as well as accept that I am unable to effect change in these areas. Nevertheless, I am disinclined to paper over these shortcomings by accepting such workarounds. Furthermore, as I understand it, saved reports use the GUID of an account to refer to them, so any attempts at using a saved report from one file in another is likely doomed to fail. Yup. The transference is a specious argument. Whoever thought it was a good idea was, quite simply wrong, or, at the very least, doesn't or didn't understand how gnc's reports work. Or perhaps you're talking about settings associated with the standard reports? I profess I do not know how settings for these are stored-- although the fact that they are not stored with the actual saved reports (like the saved reports themselves) simply underscores the piecemeal mechanisms used for the reports. I've no clue about this future mechanism, I want the existing one to work. Your points about multiple user access are a red herring. Since Gnucash doesn't support multiple users, there's no point in speculating on how we might circumvent this limitation. Yay, David.T gets my vote! I have a lot of ideas about gnc being multiuser but I'm not suggesting they break what we have. Gnucash does, however, support one user having multiple data files, and in this case, a user opening file B will see all the (useless) saved reports for file A. Waves! Finally, the points originally raised regarding the scattershot storage of data that are integral to a set of books (whether reports, settings, or other data) remain. Get elected, David! :) -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 09:11, Geert Janssens wrote: Op zondag 24 februari 2019 05:05:21 CET schreef David Cousens: Adrien, You beat me to it. I was about to also suggest making it a user preference to be able to store the report configurations either with the book or as a user location. Then the user could choose what suits their circumstances and configuration. David Cousens Well, for me each reference to "a new user preference" triggers the question "can't we solve it in another way". I don't think we can solve this easily, Geert. is there a way? Yes. Is there another way? Always. Is there a good or right way? Yes. For starters the user preference is an all or nothing thing, either all reports are in a book or in a common location. This simply is not true, Geert, I don't understand why you, who I respect so much, would say this when it is not true. That's not very fine-grained. Perhaps you consider some reports common and some reports book-specific. This could be solved by making it a per report option of course. Yes. It also doesn't solve the issue of sharing those common reports with other users (like your accountant). My accountant is me, I am also other people's accountant. I don't lie about money. To some extent Geert is making a jurisdictional argument, major commercial accounting applications are failing to provide what governments want. I think Reports / Tax Schedule etc should be removed for incompetence and trial balance reporting improved. And yet another issue: reports are only suitable for multiple books if these books have the exact same base as required per report. Yup, therefore it makes no sense for the reports to be stored per user. Do we know who came up with this stupid idea yet? take the transaction report. The user selects a set of transactions to display. Now suppose you select some accounts that are exclusively to this particular book. If you save this preset, and use it in another book that doesn't have these accounts there will be an issue. Geert, the saved report will most likely be useless with another book. Who was the fucking idiot that decided to use one set of saved reports? Tell us that, please! Be a man, Geert. I haven't tested, though at best the account is ignored, at worst the report throws errors. That's the best scenario. The other way around is worse: suppose you saved the report configuration with all asset accounts selected in one book. You then try to use this report on a book that has an additional asset account. As this account is not part of the initial selection it won't appear in the transaction report in the second book. Of course for a transaction report it's fairly easy to spot. There are other reports where this is much more subtle though. And this is not limited to account selections though I suspect that's the most important one. I'm seeing support for my concept, I like someone that thinks things through, eventually. So my conclusion is that report configurations are essentially book specific and should be treated as such to avoid unexpected accounting mistakes. Yes. On the other hand I understand it takes time to carefully configure reports to your preference and there's a wish to reuse this effort across books. That is easy, you just copy and paste a file. I have no time for cheap and lazy accountants that want to charge people lots of money for little work. I have done this thought exercise in the past. At that time the best I could come up with was to provide gui functions to manage report presets. In particular some form of import/export functionality. The configurations would remain per book. But one could explicitly export a configuration from one book and import it in another. My problem, Geert, is why you allowed what we have now to happen. Surely you, a respected person, a monitor, should have noticed it was wrong when the 2.x to 3.x code was settling in? I *did* talk about this! You (pural) ignored me at the time. It's not ideal as it doesn't solve the subtle errors issue. The user will still have to verify the imported configuration works for the book it's imported in. Improving on that will require smarter report options (like ways to specify "select all asset accounts" or "select all children from account xyz" instead of a dumb list of account ids). I'm pretty sure that would increase internal option complexity a lot and I'm not convinced the benefit in this case is worth the trouble. Geert, I don't get the complexity you're describing. If something ordinary that involves money happens in my life I add an account for that, this is how accounting is meant to work. You seem to think adding an account is something to be thought about by a panel of wise men and women, that isn't how modern accounting works. All brainstorming of course. No implementation in sight... Why no implementation change? The retrograde step happened in 2.x to 3.x -- Wm
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 04:05, David Cousens wrote: Adrien, You beat me to it. I was about to also suggest making it a user preference to be able to store the report configurations either with the book or as a user location. Then the user could choose what suits their circumstances and configuration. If the default was near or with the book I'd run with that. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 03:44, Adrien Monteleone wrote: One might want the same configuration in many respects and the same options on various reports to be ’saved’ (since there is no other way to accomplish this task) as user configured defaults to be useful across various books. Some people have separate files for many entities and they shouldn’t have to re-create all of that work for each one. You might always want to roll up child totals to the parent or not show zero balance accounts for example, regardless of the entity you are running reports for. Your accountant might always want to see reports following a certain format, different from the GnuCash defaults, regardless of the entity. But I also see the case where multiple users might access the same data file and you’d want them all to have the same configuration for the book options and a standard set of reports to be able to run. Certainly, there is room for improvement for a multi-user environment. (which GnuCash does not officially support at present from my understanding) Perhaps the user environment itself should be an option which would determine where the various configurations are stored. (or more likely, how they are stored, as they should probably all be located *with* the data file, though not necessarily a part of it.) Another option, specific to reports would be the ability to create a ‘custom default’ set of options. This would allow the creation of new books without having to 'remake the wheel’. (I understand ‘custom default’ may sound absurd to some, but think of this more like a ’template’.) I think I understand "custom default" and it is not absurd. You are (I think) saying that a book / file / set of transactions / whatever should be associated with the reports that are particular to it. I also accept what you say about duplicating a configuration. That should just be a process of finding the right files, copying them to a new place and ... begin! We can't do that at the moment because someone decided to hide the important bits relative to a file and put them in a place that will be different for *every* person on *every* computer. If I was a conspiracy theorist I'd say someone at gnc HQ was not acting in the interest of the people. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 02:53, David T. via gnucash-devel wrote: While I take exception to Wm's tone and language, I agree with his overall assessment of the reports and configuration management. I am happy to apologize to you if someone eventually takes notice. I will do this by paying for a meal if we ever meet in person. Storing configuration data separately from the financial data and on a user (as opposed to a book) basis is questionable. Yup. Storing saved reports separately from the financial data and on a user basis makes no sense at all. A saved report for one file will be meaningless in another. This issue has come up many times on the lists. Yup. The fact that we even need a wiki page dedicated to file and configuration locations-- let alone one as long and convoluted as the one we have (and which needs additional diagramming)-- only underscores this problem. I don't think the person that wrote the page understood what they were describing. I am sure they were doing their best. I want to be clear that I am truly grateful that Chris has decided to work on reports, and I have great respect for his ability to work with Scheme. I've yet to succeed in either editing an existing report or getting a third party report installed on my Mac. 13 years of futility on that front! David T. I second that, the fact that a diminishing handful of people can read Scheme is interesting, it isn't a progressive language, the fact that gnc is dependent on it is regressive. I have made some small changes to a gnc Scheme report for my own purposes but when I put them forward for inclusion they were refused. Presumably because the person that needed to approve them didn't understand them. The thing I worked out was how to do "end of next month" and similar for reports. Sigh David, I am always unhappy if I upset someone, I often find myself in the situation of not knowing what else to do as no one listened the first time. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 02:25, David Cousens wrote: Wm, David, I appreciate your efforts as peacemaker, don't give up on all of us yet, most of us are trying to be good, promise :) If you draw a diagram from the information in the wiki page https://wiki.gnucash.org/wiki/Configuration_Locations where the meta data and report data is stored becomes fairly obvious and is fairly simple. I disagree, the user doesn't always know where their stuff is and therefore can't make a sensible backup. We (gnc) have a theory about where stuff should be but in practice it could be just about anywhere. My argument is that we should put important stuff near or approximate to the data it relates to rather than further away from it. There was considerable discussion in the forums at the time the changes were being made from 2.6 to 3.0. Not all views were heard. Taking a poll and not listening to the views that disagree with you is ordinary. This has ended up with me saying Geert (a person I respect enormously) may be a liar :( Not all users had the same report startegy you were thinking of. Some users used the same report configurations with different books. That breaks if you have more than one book and those books have more than one set of customers (we're all customers of gnc now, right?). I think what you are saying is a tiny minority of self interested people overrode the real interest regarding where reports should be stored because it was convenient to them. If you (or anyone reading this) actually understands how gnc stores reports, how it saves them and where it saves them it makes no sense to put them in the weird general space that MS and other OS expect them to be in. Yah boo. Someone further up the chain than you or I believed something they were told and forgot about accounting. Going with the OS's recommendations has the advantage that your backup strategy may be more general than that for a single app. That means (yes, I am pushing buttons) you agree with the MS view that all your data is ours? Note it is the report configuration which is saved in the configuration locations not the report instance itself - that is in the book/main data file wrong, the report is not in the book/main data file. I am stating a fact, DavidC, you may believe it is there but it isn't and/or reconstructed from the data there when it is displayed. Nominally, yes. You are avoiding two important issues: 1. the report configuration file belongs to an account file; do you understand this? you can't apply my Balance Sheet report against your file and expect it to work, vice versa your Balance Sheet, we have different accounts! surely this is obvious? 2. the file / book / whatever doesn't know where the reports are, i have very good understanding of the formats involved and I'm telling you for free, your accounting data, as stored by gnc at present, has no fucking clue where anything else that you consider significant about it is stored. i.e. it is a fucking mess because one of the options available was for the file / book to know where it's meta data was. It is fairly simple to store a copy of user and configuarion locations contents with each data file if you really require the user and config data to be backed up along with the data file. It should be fairly simple but isn't. gnc has made a presumption about a user. if you are that user it will be OK, if you aren't you're fucked. David, keep going, please, if you think I'm bad read what I am actually saying. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
Adrien, Using configuration files as a mechanism for working around the significant shortcomings of the reports ecosystem in Gnucash is tortured logic, at best. To be clear, I understand the challenges facing the team-- as well as accept that I am unable to effect change in these areas. Nevertheless, I am disinclined to paper over these shortcomings by accepting such workarounds. Furthermore, as I understand it, saved reports use the GUID of an account to refer to them, so any attempts at using a saved report from one file in another is likely doomed to fail. Or perhaps you're talking about settings associated with the standard reports? I profess I do not know how settings for these are stored-- although the fact that they are not stored with the actual saved reports (like the saved reports themselves) simply underscores the piecemeal mechanisms used for the reports. Your points about multiple user access are a red herring. Since Gnucash doesn't support multiple users, there's no point in speculating on how we might circumvent this limitation. Gnucash does, however, support one user having multiple data files, and in this case, a user opening file B will see all the (useless) saved reports for file A. Finally, the points originally raised regarding the scattershot storage of data that are integral to a set of books (whether reports, settings, or other data) remain. David T. On Sun, Feb 24, 2019 at 9:14, Adrien Monteleone wrote: One might want the same configuration in many respects and the same options on various reports to be ’saved’ (since there is no other way to accomplish this task) as user configured defaults to be useful across various books. Some people have separate files for many entities and they shouldn’t have to re-create all of that work for each one. You might always want to roll up child totals to the parent or not show zero balance accounts for example, regardless of the entity you are running reports for. Your accountant might always want to see reports following a certain format, different from the GnuCash defaults, regardless of the entity. But I also see the case where multiple users might access the same data file and you’d want them all to have the same configuration for the book options and a standard set of reports to be able to run. Certainly, there is room for improvement for a multi-user environment. (which GnuCash does not officially support at present from my understanding) Perhaps the user environment itself should be an option which would determine where the various configurations are stored. (or more likely, how they are stored, as they should probably all be located *with* the data file, though not necessarily a part of it.) Another option, specific to reports would be the ability to create a ‘custom default’ set of options. This would allow the creation of new books without having to 'remake the wheel’. (I understand ‘custom default’ may sound absurd to some, but think of this more like a ’template’.) Regards, Adrien > On Feb 23, 2019, at 8:53 PM, David T. via gnucash-devel > wrote: > > Storing configuration data separately from the financial data and on a user > (as opposed to a book) basis is questionable. > > Storing saved reports separately from the financial data and on a user basis > makes no sense at all. A saved report for one file will be meaningless in > another. This issue has come up many times on the lists. > > The fact that we even need a wiki page dedicated to file and configuration > locations-- let alone one as long and convoluted as the one we have (and > which needs additional diagramming)-- only underscores this problem. > > I want to be clear that I am truly grateful that Chris has decided to work on > reports, and I have great respect for his ability to work with Scheme. I've > yet to succeed in either editing an existing report or getting a third party > report installed on my Mac. 13 years of futility on that front! > > David T. > ___ 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 3 on Linux
On Sat, 23 Feb 2019 at 23:28, Wm via gnucash-devel wrote: > ... > You, Colin Law, seem to be the sort of person that votes for Trump > because you aren't bothered if a black women gets shot. I fail to see what I have done to be so vilely abused as to be accused of being a Trump supporter or being a racist. Also I fail to see what I said that so angered you. I merely expressed surprise that you use Gnucash when you have such a low opinion of the developers. How you can trust their work to look after your financial data when you consider them so incompetent I don't know. As for my desire not to post words that may offend others then that is why I do it, so as not to offend. I have grandchildren and if they should happen to google my name and come up with my posts I would not want to be ashamed of what I have written. Some obviously are not worried about offending others. > > There aren't that many people like you out there, Colin Law, and you > should let this community know which side you are on. Which side of what? Colin ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
Op zondag 24 februari 2019 05:05:21 CET schreef David Cousens: > Adrien, > > You beat me to it. I was about to also suggest making it a user preference > to be able to store the report configurations either with the book or as a > user location. Then the user could choose what suits their circumstances and > configuration. > > David Cousens Well, for me each reference to "a new user preference" triggers the question "can't we solve it in another way". For starters the user preference is an all or nothing thing, either all reports are in a book or in a common location. That's not very fine-grained. Perhaps you consider some reports common and some reports book-specific. This could be solved by making it a per report option of course. It also doesn't solve the issue of sharing those common reports with other users (like your accountant). And yet another issue: reports are only suitable for multiple books if these books have the exact same base as required per report. An example to clarify what I mean: take the transaction report. The user selects a set of transactions to display. Now suppose you select some accounts that are exclusively to this particular book. If you save this preset, and use it in another book that doesn't have these accounts there will be an issue. I haven't tested, though at best the account is ignored, at worst the report throws errors. That's the best scenario. The other way around is worse: suppose you saved the report configuration with all asset accounts selected in one book. You then try to use this report on a book that has an additional asset account. As this account is not part of the initial selection it won't appear in the transaction report in the second book. Of course for a transaction report it's fairly easy to spot. There are other reports where this is much more subtle though. And this is not limited to account selections though I suspect that's the most important one. So my conclusion is that report configurations are essentially book specific and should be treated as such to avoid unexpected accounting mistakes. On the other hand I understand it takes time to carefully configure reports to your preference and there's a wish to reuse this effort across books. I have done this thought exercise in the past. At that time the best I could come up with was to provide gui functions to manage report presets. In particular some form of import/export functionality. The configurations would remain per book. But one could explicitly export a configuration from one book and import it in another. It's not ideal as it doesn't solve the subtle errors issue. The user will still have to verify the imported configuration works for the book it's imported in. Improving on that will require smarter report options (like ways to specify "select all asset accounts" or "select all children from account xyz" instead of a dumb list of account ids). I'm pretty sure that would increase internal option complexity a lot and I'm not convinced the benefit in this case is worth the trouble. All brainstorming of course. No implementation in sight... Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
Op zondag 24 februari 2019 03:53:52 CET schreef David T. via gnucash-devel: > While I take exception to Wm's tone and language, I agree with his overall > assessment of the reports and configuration management. > > > Storing configuration data separately from the financial data and on a user > (as opposed to a book) basis is questionable. > > Storing saved reports separately from the financial data and on a user basis > makes no sense at all. A saved report for one file will be meaningless in > another. This issue has come up many times on the lists. > Completely agree in today's context. There have been reasons in the past it was done as it is. If someone has spare time and epxerience I gladly accept patches to fix this technical debt. > The fact that we even need a wiki page dedicated to file and configuration > locations-- let alone one as long and convoluted as the one we have (and > which needs additional diagramming)-- only underscores this problem. > No, it underscores the dev team's willingness to be as open as possible about the complexities of a mature cross-platform application. Many applications store (meta)data is locations defined by the context. Go search for libreoffice's metadata for example, or firefox'. If you would want to document their metadata structures, you'd see something similar or even more complex. Part of the complexity comes from the multi-platform nature of gnucash. Each platform defines their own default locations for various kinds of data. And gnucash tries to apply these per platform. > I want to be clear that I am truly grateful that Chris has decided to work > on reports, and I have great respect for his ability to work with Scheme. > I've yet to succeed in either editing an existing report or getting a third > party report installed on my Mac. 13 years of futility on that front! Yes, unfortunately this isn't very user friendly. I'm sure it can be improved. Again it requires someone with time available and coding experience to implement it. Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building 3.4 on Mint 18.3
Jacob, I build GC 3.4 on Linux Mint Tara (19) and don't see any problems with the summary bar or status bar if I open or close them. There were a few slight visible differences moving from gtk-2 to gtk-3 as Geert mentioned. It may also be worth looking at the dependencies for the gtk3 library and checking that 18.3 hasloaded the required library versions with apt. It's been over 6 months since I changed from 18.3 to 19. I vaguely remember just before I changed to 19 that I had to build and load some libraries from source when i was building the last v2.6 and v2.7 just before the release of 3.0. It may be some of the library versions required are not available in the 18.3 repository. You can list the package dependencies with apt-cache depends and apt-cache search where is the package name or a substring of it,. may help with identifying packages which are identified by a name and not the actual installed library name in the apt cache. E.g. the javafx package is actually named openjfx in the apt repository. dpkg -l |grep helps with identifying the installed versions of packages . David Cousens - David Cousens -- 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
