2019-12-27 GnuCash IRC logs

00:16:22 *** manj-gnome has quit IRC
00:58:11 *** Mechtilde has joined #gnucash
01:05:40 *** fell has quit IRC
01:06:59 *** fell has joined #gnucash
01:07:00 *** ChanServ sets mode: +o fell
01:15:06 *** frakturfreak has quit IRC
01:29:33 *** frakturfreak has joined #gnucash
01:29:34 *** ChanServ sets mode: +v frakturfreak
01:53:48 *** Mechtilde has quit IRC
03:09:10 *** gjanssens has joined #gnucash
03:09:11 *** ChanServ sets mode: +o gjanssens
03:09:55 <gjanssens> .
03:09:55 <gncbot> gjanssens: Sent 22 hours and 31 minutes ago: <chris> to add another class spacer means amend all stylesheets. otherwise they won't render.
03:09:56 <gncbot> gjanssens: Sent 19 hours and 34 minutes ago: <chris> I guess your request for a spacer class comes from 797411... this would need an upgrade to html-fonts and all stylesheets
03:09:57 <gncbot> gjanssens: Sent 17 hours and 41 minutes ago: <chris> https://imgur.com/a/kYZyOUL can be done by repeating the <tr><th>...</tr> row but html-table doesn't support it (yet)
03:09:58 <gncbot> gjanssens: Sent 16 hours and 44 minutes ago: <chris> the way to do the multirow headers is to augment <html-table> -- it'll have old-school single-row col-headers (list of TH elements), and new multirow-headers (list of list of TH elements)
03:09:59 <gncbot> gjanssens: Sent 16 hours and 44 minutes ago: <chris> maybe thhis needs to wait till 3.8 out first
03:26:37 *** Mechtilde has joined #gnucash
04:03:54 *** fell has quit IRC
04:03:56 *** fell_laptop has joined #gnucash
04:03:56 *** ChanServ sets mode: +o fell_laptop
04:30:55 *** Yotson has quit IRC
04:32:00 *** Yotson has joined #gnucash
05:31:28 *** User_ has joined #gnucash
05:45:42 *** Mechtilde has quit IRC
06:08:35 *** User_ has quit IRC
06:32:14 *** Mechtilde has joined #gnucash
06:36:10 *** Jimraehl1 has joined #gnucash
06:37:27 *** Jimraehl1 has quit IRC
06:37:47 *** chris has joined #gnucash
06:37:47 *** ChanServ sets mode: +v chris
07:08:37 *** fell_laptop has quit IRC
07:30:16 *** monkeyjuice has joined #gnucash
07:31:24 *** monkeyjuice has quit IRC
07:45:47 *** omnireq_ has quit IRC
07:46:07 *** chris has quit IRC
07:47:37 *** chris has joined #gnucash
07:47:37 *** ChanServ sets mode: +v chris
07:48:07 *** omnireq_ has joined #gnucash
07:59:54 <gjanssens> chris: I didn't necessarily mean the spacer class to be available to *all* reports.
08:00:14 <gjanssens> That would indeed require amendments to the style sheets.
08:00:31 <gjanssens> For now this report is the only one with a use case for it
08:01:37 <gjanssens> The bug you refer to did not cross my mind.
08:02:15 <gjanssens> But in general I like to slowly move into the direction of css based styling, so I point out opportunities when they present themselves
08:03:06 <gjanssens> In this case I was thinking more of adding the necessary css rules at the top of the report yourself and add the class attribute where desired.
08:03:31 <gjanssens> I don't know if you have facilities to add hardcoded css in a report's header
08:05:35 <chris> gjanssens: yes actually. the problem is the html-document engine
08:05:38 <gjanssens> I'm thinking of a snippet similar to "<style>td.spacer { width : 5px };</style>" there
08:06:00 <gjanssens> how so ?
08:06:01 <chris> ahhh
08:06:31 <chris> I was initially thinking gnc:make-html-table-cell/markup "spacer" which by default does some weird <spacer>...</spacer> stuff
08:07:09 <gjanssens> No, I was thinking of <td class="spacer">...</td>
08:07:26 <chris> ^ this is a way to do it yes
08:07:48 <chris> but is a parallel way of creating css-based styles, different to benoitg's vision
08:08:31 <gjanssens> What's benoitg's vision ? The stylesheet mechanism we currently have ?
08:08:32 <chris> your suggestion is a fine one I agree
08:08:34 <chris> and perhaps the better way forward
08:08:35 <chris> yes
08:08:52 <chris> CSS styles are limited to "whatever the stylesheet.scm can handle"
08:09:00 <gjanssens> Ok.
08:09:02 <chris> "number-cell" "number-cell-neg" etc
08:09:29 <chris> btw I've done the double-row TH already myself, would need more testing hence after 3.8 I think
08:09:57 <chris> your suggestion for CSS class is fine, and I can imagine deprecating the older type
08:10:31 <chris> it'd need (gnc:html-table-cell-set-style! cell 'attribute '("class" "spacer")) I think
08:11:19 <gjanssens> Stylesheet.scm is about a simple interface to customizing report layout. It was written way before gnucash supported css.
08:11:42 <gjanssens> css in general is also about the presentation of html data.
08:12:18 <gjanssens> And I think with a few tweaks and a little bit of attention by a report designer, we can leverage much more of it than what's supported by stylesheet.scm
08:14:05 <gjanssens> It would require a few things:
08:15:04 <gjanssens> 1. sufficient semantic data in the report layouts (css classes and id's) that express the meaning of each html object rather than its desired presentation
08:16:00 <gjanssens> 2. a way to pass css definitions to the reports by the user. Some reports do this already by providing a custom css field.
08:16:53 <gjanssens> Ideally the semantic "language" we use should be shared as much as possible with all reports, like a header block is always "class header"
08:17:42 <gjanssens> 3. The default presentation of the reports should then use css styling based on this comman semantic language.
08:17:52 <gjanssens> And users can override by custom css
08:19:07 <gjanssens> If enough of the report structures gets exposed this way it will be worth redoing stylesheet.css and making a gui interface for a subset of the styling options based on these css attributes as well.
08:19:40 <gjanssens> It's a general vision I'm expressing here, not a concrete action plan (yet).
08:20:25 <chris> yeah I don't really know much of CSS to understand how to best expose customisability
08:20:38 <gjanssens> But I think it's something worth experimenting with in baby steps like this spacer proposal
08:20:52 <gjanssens> How to do it exactly can grow over time.
08:21:37 <gjanssens> The first step is certainly to make sure all info on the reports have sufficient semantic richness
08:22:00 <gjanssens> If a table cell is only "<td>", you can't infer much of its meaning
08:22:56 <gjanssens> On the other hand if it would be "<td class="warning-message>", that gives you much more of a clue of the contents and someone can base presentation definitions on that
08:25:57 <gjanssens> I think stylesheet.css does this for a very small and generic subset of html elements.
08:27:02 <gjanssens> I would even consider dismantling it's scheme code completely and replace it with a simple css file to include.
08:27:25 <gjanssens> As a first step to wider exposure of css to end users that is.
08:27:28 <chris> stylesheet.css you mean stylesheet-plain.scm ?
08:27:35 <gjanssens> Yes
08:27:55 <gjanssens> And perhaps the others also. I haven't looked into details yet.
08:28:29 <chris> I was considering simplifying this part to the extreme but the problem is the concept of "custom saved stylesheets"... maybe we can get rid of it?
08:29:17 <gjanssens> The challenge would be to convert the Stylesheet editor to be able to parse and modify css based stylesheets.
08:29:39 <gjanssens> Which is the same as what you ask I guess.
08:29:48 <chris> ooh I think this is Hard(TM)
08:30:07 * chris not a fan of writing a parsing engine
08:30:59 <gjanssens> Personally, if we as gnucash project can come up with a few clear and clean example css stylesheets, we may not need the gui editor for custom stylesheets.
08:31:55 <gjanssens> Another approach would be to design a nice css stylesheet and then templetize it in a way it can easily be parsed (mustache ?)
08:32:41 <gjanssens> Then a custom saved stylesheet would actually be just a collection of values to put into the stylesheet template.
08:33:12 <gjanssens> And if the value types are known, a generic option parser can be used for it, just like we do currently for report options.
08:33:47 <chris> I'd prefer expose CSS editor only... too difficult to parse/store these things
08:34:15 <gjanssens> We don't necessarily have to be able to parse full css in case of a template based stylesheet generator.
08:35:07 <gjanssens> Sure, both are possible. But both require our reports first to be sufficiently semantically expressive.
08:36:18 <gjanssens> And a minimal fix to expose all css to end users would be to add one more option to stylesheet-plain.css: a free text field to enter custom css data.
08:36:38 <gjanssens> Eh I mean to stylesheet-plain.scm
08:37:15 <gjanssens> But perhaps it's better to call it stylesheet-css.scm and let it only have one single option: a large text field to enter css data.
08:37:15 <chris> easy...
08:37:33 *** FH_thecat has joined #gnucash
08:37:40 <gjanssens> That can be a basis for custom, purely css based stylesheets.
08:37:46 <chris> maybe stylesheet-next.scm similar to guile-next :)
08:37:53 *** FH_thecat has quit IRC
08:37:55 <chris> or stylesheet-4.0.scm
08:38:17 <gjanssens> What's guile-next ?
08:38:27 <chris> upcoming guile-3.0...
08:38:49 <gjanssens> Oh, And would you expose it as such to the user ?
08:38:50 <chris> I think this single-text-box approach is reasonably straightforward and a good transition to future
08:39:16 <chris> yes, why not... the default value would be reasonably pretty
08:39:28 <gjanssens> Ah right.
08:39:45 <gjanssens> But I was acutally referring to the name of the file
08:40:09 <gjanssens> I'd think stylesheet-css.scm makes the intent very clear
08:40:22 <chris> ok
08:40:44 <gjanssens> But indeed, exposing a clean css default that way is kind of neat
08:42:09 <gjanssens> It could start with translating the stylesheet-plain.scm options into a single css text string
08:42:14 <chris> I'd think much better expose the whole CSS rather than write a parser+generator pair
08:42:37 <gjanssens> Not everybody is developer enough to write or tweak css.
08:42:54 <gjanssens> That's the main reason to offer a parser/generator
08:43:25 <gjanssens> Compare to writing in a word processor.
08:43:52 <gjanssens> In the old days you had to add escape codes to mark parts in bold or italic. Now you just click a button
08:44:31 <gjanssens> The former required some experience, the latter can be done by most
08:44:45 <gjanssens> with all kinds of horrible documents as a consequence, but that's another topic
08:45:12 <gjanssens> I don't mean to imply it's you that should write that parser/generator pair
08:46:33 <gjanssens> But it would be a nice to have at some point and I don't think we can fully remove the old stylesheet code until we have a way for users to do simple style tweaks via a graphical interface.
08:47:18 <gjanssens> But that's something for way in the future anyway.
08:47:58 <chris> perhaps stylesheet-css.scm is a good option for now then... future oriented, very customisable, and old stylesheets present as old-school option until completely obsolete
08:48:39 <gjanssens> Having a stylesheet that fits in the current infrastructure but is purely css based (the one-single-css option idea) will allow us to advance one step at the time
08:48:47 *** omnireq_ has quit IRC
08:49:35 <gjanssens> And time will tell whether css based without a gui will be sufficient or not.
08:49:56 <chris> :)
08:50:07 <gjanssens> Oh and jumping back to your original notes: I'm fine with holding off the double header until after 3.8
08:50:09 <chris> do we want one done before 3.8 is out the door?
08:51:08 *** omnireq_ has joined #gnucash
08:51:30 <chris> (not just double header... arbitrary number of <th> rows <g>)
08:51:55 <chris> brb
08:55:20 <gjanssens> Ok
09:04:37 <gjanssens> What do you mean with "do we want one done before 3.8 is out the door?"
09:07:30 <chris> ^ stylesheet-css.scm :)
09:07:35 <chris> should be easy
09:21:09 *** boldstripe has quit IRC
09:21:27 *** Mechtilde has quit IRC
09:22:25 *** boldstripe has joined #gnucash
09:36:15 *** Mechtilde has joined #gnucash
09:41:06 *** Mechtilde has quit IRC
09:52:47 *** omnireq_ has quit IRC
09:52:51 <gjanssens> Oh, sure, that would be interesting, though let's mark it as experimental in some way
09:53:13 <gjanssens> For example name it "Css (Experimental)" or something like that
09:53:45 <chris> done :)
09:54:02 *** omnireq_ has joined #gnucash
10:01:36 *** boldstripe_ has joined #gnucash
10:01:51 *** boldstripe has quit IRC
10:01:51 *** boldstripe_ is now known as boldstripe
10:14:17 *** omnireq_ has quit IRC
10:16:38 *** omnireq_ has joined #gnucash
10:21:46 *** boldstripe_ has joined #gnucash
10:22:00 *** boldstripe has quit IRC
10:22:03 *** boldstripe_ is now known as boldstripe
10:25:32 *** omnireq_ has quit IRC
10:28:16 *** manj-gnome has joined #gnucash
10:44:25 *** jervin has quit IRC
10:53:31 *** ArtGravity has joined #gnucash
10:53:31 *** ChanServ sets mode: +v ArtGravity
11:05:39 *** omnireq has joined #gnucash
11:05:39 *** ChanServ sets mode: +v omnireq
11:07:06 *** o01eg has quit IRC
11:07:17 *** boldstripe has quit IRC
11:07:47 *** boldstripe has joined #gnucash
11:19:23 *** manj-gnome has quit IRC
11:22:08 *** manj-gnome has joined #gnucash
11:25:20 *** manj-gnome has quit IRC
11:38:35 *** manj-gnome has joined #gnucash
11:48:23 *** manj-gnome has quit IRC
12:08:42 *** fell_laptop has joined #gnucash
12:08:42 *** ChanServ sets mode: +o fell_laptop
12:10:57 *** manj-gnome has joined #gnucash
13:10:38 *** manj-gnome has quit IRC
13:20:54 *** PowaBanga has quit IRC
13:21:50 *** PowaBanga has joined #gnucash
13:29:07 <jralls> chris, gjanssens, on the topic of "before 3.8 is out the door", that's real soon. I'm hosting a dinner party tomorrow so I'm going to start on the release notes today for a Sunday release as usual.
13:32:12 <jralls> As for CSS, that's pretty easy to parse and a CSS editor widget would be dual-use because we could also use it for styling Gtk.
13:33:48 *** guak has joined #gnucash
13:41:13 <gjanssens> jralls: ok on the 3.8 as far as I'm concerned. I won't have time to add more to this release.
13:42:25 <gjanssens> As for CSS, that's an interesting second use case. Do you have experience writing parsers or know of a CSS parser we can reuse ?
13:49:10 <jralls> I've written a few over the years. Writing them from scratch is tedious but not difficult. lex and yacc make it easier, and I understand that Boost::Spirit makes it easier still. But parsing css is so common there must be a bunch already written... and we already depend on this one: https://github.com/WebKit/webkit/blob/master/Source/WebCore/css/parser/CSSParser.cpp
13:53:42 *** KevinDB has quit IRC
13:55:16 *** KevinDB has joined #gnucash
13:55:16 *** ChanServ sets mode: +v KevinDB
13:56:03 *** Mechtilde has joined #gnucash
14:09:07 <jralls> gjanssens: New subject. Dunno if you've been following https://bugs.gnucash.org/show_bug.cgi?id=797283. mdf got mingw-w64-webkit to build with the current Mingw32 packages. I've copied his changes and made some more to reduce the dependencies and to add a test feature to its threading code.
14:10:09 <jralls> It occurs to me that going forward it will be necessary to rebuild it periodically and that we should keep the package build directory in a repo. Should I just add it to gnucash-on-windows?
14:20:55 <gjanssens> jralls: I have followed it more or less
14:22:18 <gjanssens> Are you talking about adding binaries to the gnucash-on-windows repo, that is pacman package that results from buiding mingw-w64-webkit ?
14:23:28 <jralls> No, the mingw-w64-webkitgtk directory from https://github.com/msys2/mingw-packages with mods from mdf and me.
14:25:01 <jralls> Except of course he's removed it from there. I have an old clone that still has it, as does mdf.
14:26:13 <jralls> The binary is https://downloads.sourceforge.net/gnucash/Dependencies/mingw-w64-i686-webkitgtk3-2.4.11-999.1-any.pkg.tar.xz
14:46:51 *** KevinDB has quit IRC
14:48:02 <gjanssens> Ok, I'm fine with adding that to gnucash-on-windows
14:48:11 *** KevinDB has joined #gnucash
14:48:11 *** ChanServ sets mode: +v KevinDB
14:48:24 <gjanssens> jralls: Should we reuse our "borrowed" concept ?
14:51:27 <gjanssens> As for parsers, I recently heard a cppcast podcast where the guest spoke of https://github.com/taocpp/PEGTL which is also a library to write simple grammars in.
14:52:46 <gjanssens> According to the author it's less advanced as boost::spirit, but faster. I have considered rewriting our expression parser based on that as an experiment
14:53:11 <gjanssens> If I were to have time for that...
14:53:50 <gjanssens> So nothing concrete but it sounded like an interesting project to eventually return back to.
14:55:01 <gjanssens> Other than that, I'll probably go to bed early today. I'm very tired. If you have anything else, you can leave a note.
14:55:53 <gjanssens> See you later!
14:56:03 *** gjanssens has quit IRC
16:23:09 <chris> of course, guile also has (ice-9 peg) but of course we'll stay away from this
16:23:50 *** Mechtilde has quit IRC
16:35:37 *** jervin has joined #gnucash
16:44:40 *** jervin has quit IRC
16:46:16 *** KevinDB has quit IRC
16:47:15 *** jervin has joined #gnucash
16:47:44 *** KevinDB has joined #gnucash
16:47:44 *** ChanServ sets mode: +v KevinDB
16:54:45 <jralls> chris: It's much easier to write the parser in C/C++ than it is to write the accompanying UI in Scheme. ;-)
17:03:27 *** chris has quit IRC
17:03:47 *** chris has joined #gnucash
17:03:47 *** ChanServ sets mode: +v chris
17:04:29 *** oozer has joined #gnucash
17:09:21 *** chris has quit IRC
17:12:34 *** chris has joined #gnucash
17:12:34 *** ChanServ sets mode: +v chris
17:20:21 <chris> my concern iisn't necessarily the parsing/generating of simple css... it's about deciding the class names, cascading rules etc
17:36:03 <jralls> @tell mdf I've finally got webkitgtk fixed up and uploaded and setup_mingw64.ps1 fixed to run pacman -Syu twice and modified to load the webkitgtk3 package from sourceforge.
17:36:03 <gncbot> jralls: The operation succeeded.
17:40:23 <chris> off soon. sorry for my huge number of commits. I didn't manage to find time to summarise the notable features.
17:41:04 <jralls> chris: I don't think we need to have a full css parser, but if we do we can use WebKit's. We just need to read and write enough css to make a simple editor for handling the basic things that the current stylesheet editor does. We can provide a text window for fine tuning. That's already in at least one report, though I don't remember which one offhand.
17:41:56 <chris> invoice.scm
17:42:08 <chris> and soon, stylesheet-css.scm
17:43:00 <chris> ah the eguile reports also allow custom css
17:54:01 *** jervin has quit IRC
17:55:10 *** jervin has joined #gnucash
18:01:58 *** jervin has quit IRC
18:07:54 *** o01eg has joined #gnucash
18:09:57 *** boldstripe_ has joined #gnucash
18:10:12 *** boldstripe has quit IRC
18:10:12 *** boldstripe_ is now known as boldstripe
18:38:54 *** chris has quit IRC
18:45:29 *** ArtGravity has quit IRC
18:46:17 *** chris has joined #gnucash
18:46:18 *** ChanServ sets mode: +v chris
18:46:21 *** ArtGravity has joined #gnucash
18:46:22 *** ChanServ sets mode: +v ArtGravity
18:59:50 *** ArtGravity has quit IRC
19:06:48 *** frakturfreak has quit IRC
19:08:10 *** omnireq has quit IRC
19:44:27 *** gtpedrosa has joined #gnucash
19:59:35 *** manj-gnome has joined #gnucash
20:11:27 *** boldstripe has quit IRC
20:16:40 *** omnireq has joined #gnucash
20:24:06 *** oozer has quit IRC
20:39:59 *** storyjesse has joined #gnucash
20:44:42 *** chris has quit IRC
20:45:00 *** chris has joined #gnucash
20:45:02 *** ChanServ sets mode: +v chris
20:52:22 *** guilherme_ has joined #gnucash
20:52:49 *** gtpedrosa has quit IRC
21:30:07 *** boldstripe has joined #gnucash
21:46:57 *** guak has quit IRC
22:43:45 *** Gerd1 has joined #gnucash
22:44:20 *** Gerd has quit IRC
22:44:20 *** Gerd1 is now known as Gerd
23:12:37 *** jervin has joined #gnucash
23:20:45 *** manj-gnome has quit IRC
23:23:37 *** jervin has quit IRC
23:40:47 *** boldstripe has quit IRC