2022-07-06 GnuCash IRC logs
00:26:51 *** paul has quit IRC
00:37:22 <NoobAlice> drl: You click on the link and the new options window pops up. Along the top are tabs. The first tab is Accounts: here you can select the accounts in the TOP box. The bottom box of accounts is filtering. Once you've selected accounts, hit Apply and see if that works for you.
00:39:51 *** Linda has joined #gnucash
00:39:51 *** ChanServ sets mode: +v Linda
01:18:09 *** Linda has quit IRC
01:29:03 *** Gandalf has joined #gnucash
02:00:56 *** fell has quit IRC
02:02:16 *** fell has joined #gnucash
02:02:16 *** ChanServ sets mode: +o fell
02:27:29 *** NoobAlice has quit IRC
02:42:41 *** Gandalf has quit IRC
02:50:08 *** Gandalf has joined #gnucash
02:57:24 *** Aussie_matt has joined #gnucash
03:11:54 *** gjanssens has joined #gnucash
03:11:54 *** ChanServ sets mode: +o gjanssens
05:35:59 *** jmdaemon has quit IRC
07:16:03 *** Gandalf1 has joined #gnucash
07:16:30 *** Gandalf has quit IRC
07:16:30 *** Gandalf1 is now known as Gandalf
08:12:58 *** mydogsnameisrudy has joined #gnucash
08:14:15 *** mydogsnameisrudy has quit IRC
08:43:49 <chris> gjanssens: One idea that prevents my merging xaccTransGetTxnType is I believe the mechanism for these auto "scrubs" isn't satisfactory from end-user POV
08:44:27 <chris> IMHO the new xaccTransGetTxnType should compare the heuristic txn_type with the kvp txn_type, and highlight any discrepancy, including a link to the offending transaction
08:45:03 <chris> the dilemma is how to report it to the end-user: IMHO we should have a "What's New" type report tab which collates such auto-scrubs
08:45:25 <chris> and the restore-tabs mechanism can show this tab iff there are auto-scrubs
08:45:38 <chris> the budget-signs fix also could use it
08:46:45 <chris> and the main advantage of having a proper html report instead of a gnc_info_dialog is that we can harness the rich text and link to the transaction or budget
08:46:47 <chris> wdyt
08:47:32 <chris> TL;DR: it's not reasonable to ask the end-user to inspect the Tracefile when they're concerned, especially it's overwritten each session
09:07:42 <gjanssens> chris: in general I think it's a good idea to inform users if changes were made to the data automatically/programmatically.
09:07:53 <gjanssens> How to implement it may need some additional thought.
09:07:58 <gjanssens> Are the auto-scrubs triggered from gui code or from engine code ?
09:08:51 <gjanssens> If triggered from gui code, then yes, something that reuses the report code can leverage links and styling and so on.
09:10:06 <gjanssens> It would however also mean auto-scrubbing can't work when running gnucash-cli, nor when interfacing with gnucash via scripting languages - at least you won't have access to the report code to display the changes made by scrub.
09:10:30 <gjanssens> That may not really be what you want either.
09:11:55 <gjanssens> When pondering this messaging dilemma in the past, I had the thought to set up some kind of layered messaging system inside gnucash.
09:12:39 <gjanssens> A basic interface could be part of the engine, similar to our PWARN, DEBUG macros/functions.
09:13:10 <gjanssens> That would allow all parts of gnucash to queue user oriented messages regardless of where in the code we are.
09:14:43 <gjanssens> The display of these messages would be implemented differently, depending on the application: gui gnucash could use a gui (based on reporting or a dedicated dialog), gnucash-cli or scripting might make use of pure text output.
09:15:14 <gjanssens> This is only a rough idea (as unfortunately many of my ideas these days...)
09:16:40 <gjanssens> The simple text only interface could even be part of libgnucash so there's a default interface available for scripting and gnucash-cli. Only for gui gnucash a more refined display implementation would be needed.
09:22:44 *** paul has joined #gnucash
09:23:05 <chris> How about a qof_instance_log_warning (QOF_INSTANCE(trans), "This transaction txn_type scrubbed from I to P")
09:24:21 <chris> some are triggered via gui eg ScrubBusiness.c, others from engine eg xaccTransGetTxnType
09:25:05 <chris> I'm still not sure whether it should run heuristics upon first call (safest) or during file->load
09:30:17 <fell> gjanssens, why does in docs ninja install trigger html?
09:30:42 *** sbluhm has joined #gnucash
09:32:17 <fell> From my POV as default we don't want html under linux or windows
09:39:14 <gjanssens> chris: Where do these qof_instance_log_warnings go ? I never looked at those before. I only know the PWARN/PERROR/ENTER/LEAVE ... mechanisms.
09:41:00 <chris> gjanssens: there's no such function... yet :)
09:41:24 <gjanssens> fell: IIRC I set up the cmake build system such that the nightly build service would continue to work with minimal changes. Just replace the autogen.sh call with a cmake call and that's it.
09:41:45 <chris> they'd go into QofInstancePrivate until something queries them
09:42:14 <gjanssens> But I don't have a strong opinion on when to do the html build. So your argument is as good as mine.
09:42:21 <chris> or they'd go into a global std::vector<std::string> warnings in qofinstance.cpp
09:42:52 <fell> before we had targets html and inst-html or similar.
09:42:57 <gjanssens> If we stop building html by default on non-windows (it's already not built on Windows), you just have to coordinate with warlord to make a change to his cmake invocation on the build server
09:44:04 <gjanssens> The build server would have to invoke "cmake -DWITH_HTML ON ..." (that is explicitly enable html building)
09:44:20 <fell> Is there a way to disable the html-installation on linux?
09:44:48 <gjanssens> cmake -DWITH_HTML OFF ...
09:45:03 <fell> Currently it triples the installation size.
09:45:37 <gjanssens> Currently with cmake, what is enabled at configure time will be installed.
09:48:27 <fell> Bad design ;-)
09:49:29 <gjanssens> cmake limitation :(
09:50:06 <fell> From my POV the default shoould be the target of the OS. the build server is a secial case.
09:50:13 <fell> special
09:50:32 <gjanssens> The issue is more subtle than that.
09:51:02 <warlord> cmake sucks in so many ways.
09:51:04 <gjanssens> You can selectively choose which targets are built by default in cmake code by making them prerequisites of the "ALL" target?
09:51:10 <gjanssens> .
09:51:12 <warlord> but it wasn't my choice to move away from autotools
09:51:27 <gjanssens> But you can't do the same for installation.
09:52:02 <gjanssens> I don't think cmake sucks by the way. I prefer it a lot over autotools actually. But it does have a different set of advantages and drawbacks compared to autotools.
09:53:03 <gjanssens> Is there ever a reason to actually install the html format ? I mean in a distro sense, that it has to appear in a specific directory in order for it to get packaged properly.
09:53:22 <gjanssens> I personally don't see such a situation.
09:54:04 <gjanssens> So we may just drop the html install rule completely. The build rule and the install rule generate exactly the same output, only in a different directory.
09:54:38 <gjanssens> So where ever we currently use the install output to copy into place for our webserver, we can just as well use the build output.
09:55:27 <gjanssens> That saves time while updating the website as well as files only have to be copied once.
09:57:25 <gjanssens> chris: that could be a reasonable ad-hoc solution. How long do you want to keep these warnings around ? Until the book to which the warnings belong is closed ?
09:58:20 <gjanssens> Do we have to draw the user's attention to these warnings ? Do we want to keep track of whether the user actually has read them ? What to do if the user hasn't read them yet at the moment s/he closes the book ?
09:59:03 <gjanssens> I'm just throwing in questions to help define a scope for your proposal :)
10:07:01 <warlord> gjanssens, indeed, we already have a "separate" rule to copy the html build output to the "right place"
10:12:48 <gjanssens> Ok, so I propose to just drop the install rule for html. fell ?
10:37:44 <fell> I would preer that
10:38:12 <fell> prefer , gjanssens
10:43:08 <gjanssens> Ok, though it don't know for sure what happens on MacOS ?
10:43:28 <fell> warlord, i am just reviewing https://github.com/Gnucash/gnucash-docs/pull/276. It will drop "Help_" from filenames. Do you need to clean up the build server then?
10:45:16 <gjanssens> Hmm, looks like the MacOS build depends on the html install target :(
10:45:56 <gjanssens> So I'll have to make the html install target available either via an option or platform dependent.
10:46:35 <gjanssens> I think via option is better, but that requires a change in the gnucash-on-macos gnucash.modules set
10:53:08 <fell> jralls the docs on osx is using revision="master", why?
10:53:41 *** Gandalf1 has joined #gnucash
10:54:09 *** Gandalf has quit IRC
10:54:09 *** Gandalf1 is now known as Gandalf
10:55:08 <warlord> fell, probably not; I mean, it will keep the old names, but so long as 'index.html' is still correct it wont reference them.
10:58:32 <fell> Ah, that is a special target.
11:06:02 <gjanssens> Ok, so I have chosen to make html installation configurable via an option. The option is enabled by default on MacOS and disabled by default on the other platforms.
11:06:22 <warlord> So do I have to change code's build rules?
11:06:26 <gjanssens> So nothing has to be changed in any of the packaging repos or build server atm.
11:07:03 <gjanssens> warlord: no ^
11:16:02 <warlord> ok
11:21:46 *** sbluhm has quit IRC
11:25:58 *** sbluhm has joined #gnucash
11:39:54 <fell> Cool, gjanssens!
11:40:54 <fell> thanks!
11:57:48 *** ArtGravity has joined #gnucash
11:57:48 *** ChanServ sets mode: +v ArtGravity
12:07:31 <gjanssens> fell: you're welcome
12:46:30 *** lmat has quit IRC
13:07:01 *** lmat has joined #gnucash
13:07:52 *** lmat has quit IRC
13:07:55 *** lmat has joined #gnucash
13:09:30 *** Gandalf has quit IRC
13:09:34 *** Gandalf1 has joined #gnucash
13:11:56 *** Gandalf1 is now known as Gandalf
13:31:59 *** sbluhm has quit IRC
13:51:11 *** Gandalf1 has joined #gnucash
13:51:38 *** Gandalf has quit IRC
13:51:39 *** Gandalf1 is now known as Gandalf
14:07:52 *** sbluhm has joined #gnucash
14:16:35 *** bertbob has quit IRC
14:58:08 *** sbluhm has quit IRC
15:24:57 *** ArtGravity has quit IRC
16:13:43 *** warlord has quit IRC
16:28:07 *** rdo has quit IRC
16:29:00 *** rdo has joined #gnucash
16:36:38 *** jotrago has joined #gnucash
16:39:10 *** Gandalf has quit IRC
16:40:59 *** jotrago has quit IRC
16:47:39 *** gjanssens has quit IRC
16:54:14 *** jotrago has joined #gnucash
16:55:30 *** jotrago has quit IRC
17:03:07 *** NoobAlice has joined #gnucash
17:03:07 *** ChanServ sets mode: +v NoobAlice
17:12:47 *** jmdaemon has joined #gnucash
17:29:28 *** warlord has joined #gnucash
17:42:26 *** ChanServ sets mode: +qo warlord warlord
18:18:13 *** PowaBanga has quit IRC
18:18:41 *** PowaBanga has joined #gnucash
20:15:49 *** Aussie_matt has quit IRC
20:20:33 *** Aussie_matt has joined #gnucash
21:01:23 *** sbluhm has joined #gnucash
21:35:55 <chris> @tell gjanssens good points; this is why instead of trying heuristics every call, it may be safer to scrub txn_type once, set a flag, and show warnings only once.
21:35:55 <gncbot> chris: The operation succeeded.
21:41:08 *** sbluhm has quit IRC
21:53:00 *** storyjesse has joined #gnucash
22:03:58 *** jralls has quit IRC
22:04:24 *** jralls has joined #gnucash
22:04:24 *** ChanServ sets mode: +o jralls
22:25:44 *** gncbot has joined #gnucash
22:25:44 *** warlord has quit IRC
22:25:55 *** warlord has joined #gnucash
22:32:32 *** chris has quit IRC
22:32:47 *** chris has joined #gnucash
22:32:47 *** ChanServ sets mode: +v chris
23:42:50 *** paul has quit IRC
23:43:55 *** Aussie_matt has quit IRC