2019-10-03 GnuCash IRC logs
01:11:38 *** jervin has joined #gnucash
01:14:13 *** Mechtilde has joined #gnucash
01:28:01 *** chris has joined #gnucash
01:28:02 *** ChanServ sets mode: +v chris
01:28:12 <chris> a few obscure budget crashers fixed
01:28:33 <chris> pricealist caching is difficult to fix.
01:55:46 <chris> ninja distcheck currently fails in maint I think
01:56:03 <chris> ^ something about GTEST
02:03:00 *** chris has quit IRC
02:27:20 *** gjanssens has joined #gnucash
02:27:21 *** ChanServ sets mode: +o gjanssens
02:54:23 *** CDB-Man_ has quit IRC
02:57:44 *** CDB-Man has joined #gnucash
02:57:45 *** ChanServ sets mode: +v CDB-Man
03:28:45 *** fell_laptop has joined #gnucash
03:28:45 *** ChanServ sets mode: +o fell_laptop
03:47:12 *** CDB-Man has quit IRC
03:48:56 *** fabior has joined #gnucash
03:56:39 *** CDB-Man has joined #gnucash
03:56:39 *** ChanServ sets mode: +v CDB-Man
04:10:35 *** fell_laptop has quit IRC
04:10:36 *** fell has joined #gnucash
04:10:36 *** ChanServ sets mode: +o fell
04:10:46 *** fabior has quit IRC
04:23:06 *** CDB-Man has quit IRC
04:27:20 *** CDB-Man has joined #gnucash
04:27:20 *** ChanServ sets mode: +v CDB-Man
04:52:16 *** Aussie_matt has quit IRC
04:53:05 *** storyjesse has joined #gnucash
05:25:03 *** Aussie_matt has joined #gnucash
05:31:34 *** storyjesse has quit IRC
05:56:35 *** chris has joined #gnucash
05:56:35 *** ChanServ sets mode: +v chris
05:58:50 *** fabior has joined #gnucash
06:04:41 *** pohly has joined #gnucash
06:10:49 *** fabior has quit IRC
06:21:05 *** oozer has joined #gnucash
06:21:44 *** Jimraehl1 has joined #gnucash
06:23:14 *** Jimraehl1 has quit IRC
06:25:13 <chris> with 1-core ninja-check=80s; 2-core=47s; 3-core=39s. >3=no benefit.
06:26:12 <chris> becuase there's only 2 long tests - test-stress-options and test-lots.
06:39:04 *** warlord has joined #gnucash
06:42:36 *** fabior has joined #gnucash
06:46:00 *** pohly has quit IRC
06:48:35 *** fabior has quit IRC
06:49:46 *** sbluhm has joined #gnucash
06:49:46 *** ChanServ sets mode: +v sbluhm
06:51:29 *** Aussie_matt has quit IRC
07:09:26 *** pohly1 has joined #gnucash
07:23:47 *** sbluhm has quit IRC
07:29:01 *** pohly1 has quit IRC
07:39:11 *** pohly1 has joined #gnucash
07:40:50 *** pohly1 has quit IRC
07:43:47 *** sbluhm has joined #gnucash
08:08:56 *** jervin has quit IRC
08:16:47 *** sbluhm has quit IRC
08:18:14 *** pohly1 has joined #gnucash
08:21:43 *** pohly1 has quit IRC
08:41:20 *** Mechtilde has quit IRC
08:57:38 *** fabior has joined #gnucash
08:59:02 *** JayC has quit IRC
09:01:21 *** sbluhm has joined #gnucash
09:01:21 *** ChanServ sets mode: +v sbluhm
09:01:24 *** ChanServ sets mode: +qo warlord warlord
09:01:27 *** warlord sets mode: +o gncbot
09:01:31 <warlord> .
09:05:59 *** maney has joined #gnucash
09:08:05 <maney> is it possible to change the colors used for bar charts? after a system upgrade that brought gc 3.4, I find the new colors garish and wish to spare my eyes.
09:11:29 *** Mechtilde has joined #gnucash
09:13:21 *** sbluhm has quit IRC
09:30:44 *** jervin has joined #gnucash
09:51:26 <warlord> maney, I'm sure it is, but I don't know how. My guess would be a CSS file of some sort.
09:51:37 <warlord> Try asking on gnucash-user mailing list?
10:11:03 *** mohave has joined #gnucash
10:22:40 *** sbluhm has joined #gnucash
10:23:31 *** jervin has quit IRC
10:25:15 *** fabior has quit IRC
10:26:04 *** omnireq has quit IRC
10:33:19 *** oozer has quit IRC
10:40:58 *** fabior has joined #gnucash
10:45:41 *** Mechtilde has quit IRC
10:47:00 *** fabior has quit IRC
10:56:10 *** mohave has quit IRC
10:57:41 *** omnireq has joined #gnucash
10:57:41 *** ChanServ sets mode: +v omnireq
11:03:19 *** fabior has joined #gnucash
11:19:33 *** fabior has quit IRC
11:20:20 *** guak has joined #gnucash
11:21:13 *** ArtGravity has joined #gnucash
11:21:13 *** ChanServ sets mode: +v ArtGravity
11:36:41 *** mohave has joined #gnucash
11:39:58 *** fabior has joined #gnucash
11:49:11 *** sbluhm has quit IRC
11:51:40 *** chris has quit IRC
11:54:06 *** mohave has quit IRC
12:10:57 *** fabior has quit IRC
12:13:34 *** jervin has joined #gnucash
12:13:43 *** fabior has joined #gnucash
12:13:59 *** kael has joined #gnucash
12:13:59 *** ChanServ sets mode: +v kael
12:15:28 *** warlord has quit IRC
12:16:31 *** JayC has joined #gnucash
12:16:31 *** ChanServ sets mode: +v JayC
12:16:43 <jralls> .
12:16:43 <gncbot> jralls: Sent 1 day, 5 hours, and 37 minutes ago: <gjanssens> it looks like adding quotes in the right locations fixes the problem already of the OSX_EXTRA_LIBRARIES as well.
12:16:44 <gncbot> jralls: Sent 21 hours and 22 minutes ago: <gjanssens> turns out the Windows build is as picky as MacOS. So I'll use that to test which libraries can be made private and which ones should be public.
12:18:50 <jralls> gjansssens OK, where did you put the quotes? The change in pickiness makes me wonder if there's a cmake change that didn't get covered by a policy. What version of cmake do you have?
12:20:37 *** sbluhm has joined #gnucash
12:23:24 *** oozer has joined #gnucash
12:28:06 *** sbluhm has quit IRC
12:29:51 *** warlord has joined #gnucash
12:29:51 *** gncbot sets mode: +o warlord
12:32:20 *** fabior has quit IRC
12:35:39 *** kael has quit IRC
12:45:46 *** Mechtilde has joined #gnucash
12:48:29 *** jervin has quit IRC
12:49:12 *** fabior has joined #gnucash
12:55:25 *** fabior has quit IRC
12:57:55 <jralls> gjanssens, back to our discussion about where options code belongs: I'm not so sure that putting them in libgnuash does make sense: With very few exceptions the options are about presentation of reports and another implementation might have a different approach requiring different options.
13:03:10 <jralls> That has implications about persistence as well: If our goal is to have a file/database format/schema that can be exchanged between implementations then we should think some more about how we persist what.
13:10:39 <jralls> For example, we currently persist per-book window layouts including the options used on reports left open when the session is closed in per-book .gcm files. We've decided that saved report configurations should also be per-book and leaned toward storing them in the book itself so that they can be shared amongst multiple users of the book... but if a different program using libgnucash but with different reports were to attempt to open that book it
13:10:39 <jralls> would have to recognize those options and ignore them.
13:14:41 <jralls> A database backend could finesse that by having two sets of tables, one with the libgnucash accounting data and another with GnuCash-specific data like saved report configurations. A different libgnucash-using application would be able to ignore those GnuCash-specific tables and interact safely with the book.
13:14:49 <warlord> jralls, I think there are different kind of 'options". There are User Preferences, there are Book Properties, and there are probably Per-Book-Per-User preference/properties as well. libgnucash MIGHT need access to some of these (e.g. a rounding-type preference).
13:16:03 <jralls> warlord: Right. That's exactly my point.
13:17:11 <jralls> IMO counters and uses trading accounts are better e.g.s than rounding.
13:17:33 <warlord> Um, unless I'm misreading, that's not entirely what you said above. You said "I'm not so sure that putting them in libgnuash does make sense" -- i.e., you do not think it makes sense to put it in libgnucash
13:17:58 <warlord> But if libgnucash needs them, then that means libgnucash needs access to the options somehow, so either it's a part of libgnucash or it's a dependency.
13:18:00 <jralls> No, I don't think that putting most of the report options in GnuCash makes sense.
13:18:34 <warlord> Sure, the report options belong with the reports.
13:18:51 <jralls> gjanssens opined on Tuesday that report options in particular belong in libgnucash.
13:19:07 *** jervin has joined #gnucash
13:19:49 <warlord> Ah, your first statement did not sound restrictive to report options. I feel report options belong in the reports.. I do think that libgnucash should provide a way to store report options with the data (per book).
13:21:02 <jralls> Yes, I think we all agree about saved reports being per-book.
13:21:46 <warlord> I think libgnucash should provide a generic option structure load/save mechanism, which then gets used by the multiple types of options as appropriate.
13:23:13 <jralls> I don't think that will work if some options need to be saved in the book and other options need to be saved in the .gcm and yet more options need to be saved somewhere else so that they can be shared easily.
13:24:30 <jralls> So we can have a generic option creation/set/UI structure but it would have to delegate load/save to allow for those different locations.
13:25:53 <warlord> I think we can probably enumerate the different save-types and have backends for each type.
13:26:56 <jralls> It could conceivably have a single serialization/deserialization mechanism that each of the load/save delegates could use.
13:28:21 *** sbluhm has joined #gnucash
13:29:02 <warlord> right
13:29:02 <jralls> Yes, I think we need to do that; we need to figure out and add to the API documentation what's libgnucash and what's GnuCash.
13:29:46 <warlord> yes. And probably enumerate each (known) option and what kind of option it is. Then you'll also be able to know which ones libgnucash might depend on.
13:31:50 <jralls> That's another issue that gjanssens raised on a PR from BobIT a few weeks ago: BobIT proposed to redo the book options window as a normal GtkBuilder one instead of being defined at runtime, but that put the enumeration of the options in a .glade file. gjanssens didn't like that.
13:32:22 <warlord> I agree with gjanssens
13:32:26 <warlord> It should be dynamic
13:32:49 <warlord> That way we can use the same UI interface for all the different kinds of options/preferences/etc.
13:33:21 <jralls> Raising the larger issue: Where is the right place to enumerate the options? And for what value of dynamic? Even though it's currently created at runtime the options are hard-coded.
13:35:24 <jralls> Having them in a glade file is arguably more dynamic than coding them in C. Changing glade files can change the behavior of the program without necessarily recompiling.
13:36:26 <warlord> the code that uses the options need to know what the options are. So you need to change the code too when you change/add/remove options
13:37:19 <jralls> That's not true. If it was the Scheme side wouldn't work.
13:38:40 <warlord> What do you mean? The scheme code knows how to leverage the options because it's programmed to do so. If I add a new option, let's say the "font color option", sure, if it's glade the option would get displayed, and possibly stored and re-loaded, but it wouldn't be used without making a change somewhere in the code.
13:39:24 <warlord> Even in the reports, I can (dynamically) add new options to a report. But then the report has to additionally be programmed to *use* that option.
13:41:32 <jralls> But Scheme code can also be changed without recompiling GnuCash, and there's enough automatic stuff built in that if a Glade file generates an option it will be saved in the book's KVP. One could then use that new option in a Scheme report, all without recompiling GnuCash.
13:41:38 *** jervin has quit IRC
13:41:53 *** jervin has joined #gnucash
13:46:01 <jralls> Suppose you want to add a new option to display on the invoice report. With BobIT's change you'd just add a control to the book options glade file and patch invoice.scm to read the option and place it on the report.
13:46:10 <warlord> Can reports access the global and per-book preference/properties databases?
13:46:19 <warlord> (I honestly don't recall).
13:46:41 <jralls> Of course. That's how the invoice report gets the business name and address.
13:47:09 <warlord> So okay, yes, I can see how if you want to add a global or per-book option that reports would use, doing it in glade would make it somewhat easier.
13:47:49 <warlord> Right.. Of course. On the other hand those properties were defined in SCM code (at least originally -- maybe they've been redefined in C since then)
13:48:24 <jralls> They are indeed defined in libgnucash/app-utils/business-options.scm.
13:48:53 <warlord> So ... gnucash doesn't need to be recompiled to add new ones :)
13:51:54 <jralls> Currently correct. But having scheme in libgnucash is a major stumbling block to anyone else using it, especially on mobile platforms, so I'm working on converting it to C++. It will still be possible to create options from Scheme, of course, but it won't really make sense for options like counters or use-trading-accounts that aren't ever accessed from Scheme.
13:52:20 <warlord> Fair.
13:52:43 *** ArtGravity has quit IRC
13:53:03 <jralls> Of course those are also options that would require C access to use them, so the argument that they can be usefully defined in a glade file breaks down there as well.
13:53:08 <warlord> Perhaps... options required by libgnucash can be defined by libgnucash. options required by reports can be defined by reports. options required by "GnuCash" can be defined by GnuCash?
13:55:24 <jralls> Right. But where? Reports is easy, every report has an options block setting up the options it needs. Should there be a libgnucash/engine/options.hpp and a register/register-core/options.h enumerating the options each uses?
13:56:09 <warlord> i dont know
13:56:13 <warlord> maybe?
13:58:18 <jralls> Maybe indeed. That's what we need to decide and document so that we have a target to work towards.
13:58:27 * warlord nods
14:04:19 <gjanssens> So here I am, popping up near the end of the discussion :)
14:05:20 <gjanssens> Most seems to have been said, so I'll just add in a few ACK's and comments
14:06:01 <gjanssens> I think it may be worth separating the option functionality from where to store it.
14:06:10 <gjanssens> I mean in the discussion.
14:07:08 <gjanssens> As for the functionality, I agree it may be useful to have a generic options api that's available to all who need it
14:07:24 <gjanssens> For me it makes most sense for libgnucash to expose this
14:07:43 *** jervin has quit IRC
14:07:44 <gjanssens> Then each other block indeed can implement and register its own backend
14:08:37 <gjanssens> Looks like three major providers of such a backend have already been mentioned: reports, libgnucash and gnucash
14:08:57 *** jervin has joined #gnucash
14:09:15 <gjanssens> I'm not sure what advantage we would get from going more fine-grained, like individual libgnucash/engine/options.hpp and a register/register-core/options.h
14:10:50 <gjanssens> Coming back to the .glade approach.
14:11:29 <gjanssens> While I think defining options in a data language rather than in code is a good idea.
14:12:09 <gjanssens> Glade is not the right language though IMO as it's mostly UI oriented and only makes sense if you have a gui to interface with
14:12:43 <gjanssens> Options related to libgnucash may be used in contexts that don't have a gui (like python bindings)
14:13:11 <gjanssens> There are plenty of other alternatives though: xml, json, yaml,...
14:14:13 *** jervin has quit IRC
14:14:13 <gjanssens> Now having said that, we do of course also have to provide gui's to interface with options from within gnucash-the-gui-app
14:14:44 <jralls> Does it really make sense to define an option in an external data file if that option requires code to implement the optional behavior?
14:14:45 <gjanssens> But I think it would be good to separate structure from presentation
14:15:59 <gjanssens> I'm not sure, but I think it's worth considering
14:16:57 <gjanssens> Of course you need to have code to implement the optional behaviour, but I am thinking of extra possibilities outside of the application
14:17:39 <gjanssens> Like automated documentation generation, or other code interfacing with libgnucash could use it to introspect or whatever
14:18:37 <gjanssens> Or even simple things like fixing a typo in an option description can be done without having to recompile the application
14:18:50 <gjanssens> You could argue the same for glade files actually
14:19:28 <gjanssens> There's no need for a glade file as you can implement the complete interface in code. And even with a glade file you need to write code to make that ui do something useful
14:19:52 <gjanssens> Still it's a very handy these two aren't mixed:
14:20:27 <gjanssens> when designing the ui, you only focus on that and when writing the code there's a lot less boilerplate code getting in your way and you can really
14:20:32 <gjanssens> focus on functionality
14:20:40 <gjanssens> I think the same can apply to options
14:21:12 *** mohave has joined #gnucash
14:21:13 <gjanssens> It may well be at least partly because options are currently coded it have become such a complex mess over the years
14:21:51 <gjanssens> Oh and jumping back to the option backends, we really have defined two dimensions:
14:22:17 <gjanssens> 1 which part of the code defines and consumes the options (libgnucash, gnucash, reports)
14:22:55 <gjanssens> 2 there scope from a user point of view (user, book-only, per book/per user)
14:23:55 <gjanssens> Both were mentioned, but I'm putting them together as it probably influences how to conceive the backends
14:25:17 <gjanssens> jralls: concerning the generator expression and quotes: https://github.com/gjanssens/gnucash/blob/gnc-module-load-begone/libgnucash/core-utils/CMakeLists.txt#L59
14:25:31 <gjanssens> I had to quote the complete generator expression for it to work
14:25:47 <gjanssens> You can retry my branch to verify.
14:26:01 <jralls> A bit of an aside, but you mentioned misspellings in descriptions. There's another way to deal with that that handles all misspellings in source code: Use internal symbols for msgids and provide a po file for English.
14:26:06 <gjanssens> I'm using cmake 3.14.5 by the way
14:26:59 <gjanssens> That's a clever idea
14:27:10 <jralls> OK, same cmake as I have on Mac. Windows is on 3.15.something.
14:27:53 <gjanssens> misspellings was just one of the top of my head. I'm mainly arguing that having the options defined outside of code will open them up for consumption in ways we currently couldn't imagine
14:28:08 <gjanssens> Whether that *will* happen is of course to be seen
14:28:12 <jralls> That's how the Joomla! CMS works. I've encountered other programs that work that way as well over the years.
14:29:19 <warlord> It does mean providing a "C locale" po file, tho..
14:30:03 *** warlord has quit IRC
14:30:13 <jralls> I'd say that having a good options API creates that opportunity without us needing to implement it. Another libgnucash client would be able to write such a backend for its own use.
14:32:32 *** calvinct has joined #gnucash
14:34:00 *** pohly1 has joined #gnucash
14:34:52 *** warlord has joined #gnucash
14:34:52 *** gncbot sets mode: +o warlord
14:37:38 <jralls> warlord, I said that, though with "English" instead of "C". A perl script could do most of the dirty work. The hard part when using gettext tools would be providing the strings to be translated to the other translators.
14:38:12 <gjanssens> Sure, though I was mostly thinking of opportunities with the options *we* provide. But I agree a good options API also offers plenty of opportunities.
14:39:04 <warlord> fair
14:39:05 <gjanssens> Then again if options are defined in data rather than code I imagine it would also be easier for ourselves to swap out options backends
14:39:41 <gjanssens> Suppose we start with a relatively basic options backend which covers the needs we have identified now
14:40:21 <gjanssens> But in the future we come up with something totally different due to new requirements
14:40:47 <gjanssens> I again would feel more comfortable if I didn't have to rewrite each and every option definition in code.
14:41:19 <gjanssens> Sure it could be the data file would require updates as well, but there are good tools to do say xml transformations
14:41:34 <gjanssens> It may be more difficult doing the same in a semi automated way in C++ code.
14:42:42 <jralls> C++ compared to Scheme or to C?
14:43:31 <gjanssens> I meant option definition transformations, so compared to xml transforms
14:45:59 <jralls> So at root an option is defined as section, name, sort order, and data type (e.g. int, QofInstance*, etc.). It also has a default value and a docstring. GUI adds a widget type and callbacks for getting and setting the widget's values.
14:47:22 <jralls> I started to try to separate the UI stuff but decided that was too big a change to start with, and especially to get done for GC4.
14:48:30 *** Mechtilde has quit IRC
14:48:51 <jralls> Section and sort order is also mostly for UI purposes, it defines the tab on the dialog box and the order that the option widgets are listed in the dialog.
14:48:52 *** calvinct has quit IRC
14:50:04 <gjanssens> Yes, separating it all would be too big a change I'd think
14:50:53 <gjanssens> If in this step we can get to something that's C++ based rather than scheme, that would already a major step
14:52:13 <gjanssens> Even if for the rest it currently behaves exactly as it did in the scheme code.
14:52:19 <jralls> I've got what I think is a working design for that.
14:52:53 *** Mechtilde has joined #gnucash
14:53:56 <jralls> It's currently self-contained with implementation and some unit tests. Next is fleshing it out to cover all of the flavors of SCM options that we have now.
14:54:13 <gjanssens> Nice.
14:54:18 <jralls> And then mocking the ui generation.
14:54:45 <gjanssens> I was just going to ask about the ui stuff.
14:54:59 <gjanssens> How do you handle this in your design ?
14:55:12 <gjanssens> Does your option just define a type of widget it requires ?
14:55:26 <gjanssens> Without actually storing a widget ?
14:56:57 <jralls> I'm going to store a void* for the widget and a two std::functions for option-to-ui and ui-to-option, all handled by gnucash/gnome-utils/dialog-options.c as now.
14:57:40 <jralls> dialog-options.c will have to become dialog-options.cpp so that it knows what a std::function is.
14:59:53 <jralls> Once it's all C++ without the bouncing back-and-forth it will be easier to figure out how to split apart the M, V, and C parts. Right now there are just too many pieces to keep in my head at once.
15:02:16 <gjanssens> Fully agreed. Looks like a good roadmap
15:04:02 <warlord> Why void* and not some GncOptionsWidget* superclass?
15:04:20 *** mohave has quit IRC
15:04:20 <jralls> Incidentally, I realized in light of your scheme-separation scheme Tuesday that the CRTP part of the design is wrong, it's doing something that's SWIG's job.
15:04:45 <jralls> warlord: Because Gtk doesn't know about GtkOptionsWidget*.
15:05:37 <jralls> And I don't want anything in libgnucash to know anything about Gtk.
15:09:19 <warlord> jralls, note that I did not say "Gtk..." I said "Gnc...". It can be an abstract or even opaque class as far as libgnucash is concerned. But at least you'll get slightly better compiler type verification than void*
15:10:11 <gjanssens> jralls: that CRTP is still hurting my head. Haven't come across it enough yet :(
15:10:55 <gjanssens> Can you add a small comment explaining why you chose for the CRTP ? At least if it will remain after your newly found insights
15:11:04 *** mohave has joined #gnucash
15:11:31 <jralls> gjanssens: It won't remain.
15:12:39 <gjanssens> Good
15:12:59 <jralls> warlord: Because if I have an opaque GncOptionsWidget* I still have to either pass it a void* or C-style cast whatever I pass in to (GncOptionsWidget*) so there's no real type safety anyway.
15:15:09 <warlord> Why would you need to specially cast?
15:16:26 <warlord> My C++ is very rusty. Is class Foo : struct Bar { }; legal?
15:17:01 <jralls> Because the compiler won't compile passing a GtkWidget* to a GncOptionsWidget* without a C-style cast. It won't even accept a reinterpret_cast.
15:17:27 <warlord> If so, the if you pass a Foo* into an API expecting struct Bar * then it should be automatic.
15:18:00 <warlord> Don't make it a GtkWidget*. I suppose you could define: struct Bar { struct GtkWidget w; } ...
15:18:09 <warlord> Which should still hide it.
15:18:28 <warlord> And still auto-cast, and be more type-safe than void*
15:20:43 <jralls> I can't do struct GtkWidget : public GncOptionsWidget because struct GtkWidget is already defined. And I can't do class GncOptionsWidget : public GtkWidget because that means I have to include gtk.h so that the compiler knows how to construct a GtkWidget.
15:20:56 *** jervin has joined #gnucash
15:21:05 <jralls> And that introduces Gtk into libgnucash.
15:24:04 <warlord> I think you're misunderstanding me. In libgnucash:
15:24:13 <warlord> struct GncOptionsWidget;
15:24:20 <warlord> then in the UI code:
15:24:31 *** mohave has quit IRC
15:24:42 <warlord> struct GncOptionsWidget ( GtkWidget w; }
15:25:03 <warlord> class FooOption : public GncOptionsWidget ...
15:25:32 <warlord> This should let you pass a FooOption * into the libgnucash API that's asking for a GncOptionsWidget*
15:28:02 <jralls> Ah, got it. The FooOption indirection isn't necessary, the GncOptionWidget* will do.
15:28:52 *** jervin has quit IRC
15:29:16 <warlord> Well, I was thinking about FooOption only so that you could define the different types of Option Widgets directly and just be able to pass "this"
15:29:21 <jralls> And of course the GncOptionsWidget would hold a GtkWidget*.
15:30:09 <warlord> Right.
15:32:04 <warlord> And then you're not using void* ;)
15:32:12 <jralls> The FooOption variant wouldn't work because the compiler can't tell that a GtkEntry is a subclass of GtkWidget.
15:34:53 <jralls> So one would have something like template <typename Widget> GncOptionWidget { Widget* w; }; class FooOption : GncOptionWidget<GtkEntry> {...};
15:35:36 <warlord> Hmm.
15:36:26 <jralls> But GncOptionWidget<GtkEntry> is a different type than GncOptionWidget<GtkTextBuffer> so the whole thing blows up again.
15:37:18 <jralls> But that doesn't matter as long as the only thing that uses GncOptionWidget are the two std::functions passed in from the UI code.
15:38:34 <jralls> And we use the untemplated form of GncOptionWidget.
15:41:30 *** Mechtilde has quit IRC
15:41:52 *** Mechtilde has joined #gnucash
15:52:47 <jralls> gjanssens: Just checked your quoted generator expression. It works correctly on MacOS.
15:53:58 <gjanssens> \o/
15:59:16 *** calvinct has joined #gnucash
16:04:02 *** pohly1 has quit IRC
16:05:22 *** mohave has joined #gnucash
16:06:31 *** jervin has joined #gnucash
16:08:55 <warlord> jralls, cool
16:09:28 <jralls> warlord, now coding up your suggestion...
16:21:11 *** mohave has quit IRC
16:26:13 *** calvinct has quit IRC
16:27:52 *** sbluhm has quit IRC
16:31:12 <jralls> warlord, works and gets rid of some static_casts. Much prettier, thanks.
16:32:10 *** mohave has joined #gnucash
16:42:53 *** mohave has quit IRC
16:56:19 <warlord> jralls, YAY! :)
16:57:30 *** Mechtilde has quit IRC
17:07:04 *** gjanssens has quit IRC
17:12:40 *** puck has quit IRC
17:16:30 *** MarkFirewhal has quit IRC
17:18:32 *** jervin has quit IRC
17:19:49 *** puck has joined #gnucash
17:29:19 *** MarkFirewhal has joined #gnucash
17:47:08 *** mohave has joined #gnucash
17:50:52 *** ArtGravity has joined #gnucash
17:50:52 *** ChanServ sets mode: +v ArtGravity
17:56:54 *** fell has quit IRC
17:56:59 *** fell_laptop has joined #gnucash
17:56:59 *** ChanServ sets mode: +o fell_laptop
18:02:42 *** monkeyjuice has joined #gnucash
18:06:52 *** monkeyjuice has quit IRC
18:21:23 *** monkeyjuice has joined #gnucash
18:45:48 *** Aussie_matt has joined #gnucash
19:07:09 *** omnireq has quit IRC
19:12:21 *** maney has left #gnucash
19:39:27 *** omnireq has joined #gnucash
19:59:01 *** fell_laptop has quit IRC
20:21:28 *** mohave has quit IRC
20:31:06 *** jervin has joined #gnucash
20:31:56 *** jervin has quit IRC
21:10:33 *** gimpnet-irc[m] has quit IRC
21:10:34 *** ElonSatoshi[m] has quit IRC
21:30:52 *** guak has quit IRC
21:31:55 *** gimpnet-irc[m] has joined #gnucash
21:47:24 *** oozer has quit IRC
21:50:34 *** ElonSatoshi[m] has joined #gnucash
21:51:35 *** ArtGravity has quit IRC
23:30:36 *** bertbob has quit IRC
23:32:57 *** bertbob has joined #gnucash
23:32:57 *** ChanServ sets mode: +v bertbob