2017-02-21 GnuCash IRC logs
00:07:47 *** O01eg has quit IRC
00:40:44 *** bertbob has quit IRC
00:41:46 *** bertbob has joined #gnucash
01:09:08 *** tuxd00d has quit IRC
01:14:58 *** tuxd00d has joined #gnucash
01:29:11 *** Mechtilde has joined #gnucash
01:41:43 *** mlncn has quit IRC
01:50:10 *** Mechtilde has quit IRC
01:56:01 *** fell has joined #gnucash
01:57:51 *** fell__ has quit IRC
02:24:05 *** gjanssens has joined #gnucash
02:24:05 *** ChanServ sets mode: +o gjanssens
02:55:10 *** bastianilso has joined #gnucash
03:34:00 *** mrklintscher has joined #gnucash
04:24:18 *** fabior has joined #gnucash
04:28:18 *** fekepp has joined #gnucash
04:28:42 *** fekepp has quit IRC
04:40:55 *** fekepp has joined #gnucash
04:45:31 *** fabior has quit IRC
05:17:26 *** fabior has joined #gnucash
05:27:38 *** fabior has quit IRC
05:41:27 *** storyjesse has joined #gnucash
05:47:20 *** jralls has quit IRC
06:47:45 *** jralls has joined #gnucash
06:47:45 *** ChanServ sets mode: +o jralls
06:55:46 *** jralls has quit IRC
07:10:33 *** User has joined #gnucash
07:12:13 *** User_ has joined #gnucash
07:14:21 *** User has quit IRC
07:32:59 *** tuxd00d has quit IRC
07:33:59 *** gncbot sets mode: +o fell
07:46:34 *** rickoehn has joined #gnucash
07:54:09 *** jralls has joined #gnucash
07:54:09 *** ChanServ sets mode: +o jralls
07:58:06 *** jralls has quit IRC
08:01:14 *** tuxd00d has joined #gnucash
08:35:01 *** mlncn has joined #gnucash
08:42:25 *** fabior has joined #gnucash
09:20:12 *** tuxd00d has quit IRC
09:56:44 *** jralls has joined #gnucash
09:56:44 *** ChanServ sets mode: +o jralls
10:01:27 *** jralls has quit IRC
10:06:14 *** kael has joined #gnucash
10:47:10 *** mlncn has quit IRC
10:48:00 *** fabior has quit IRC
10:49:18 *** storyjesse has quit IRC
10:54:27 *** O01eg has joined #gnucash
10:58:41 *** odo2063 has joined #gnucash
11:19:28 *** fekepp has quit IRC
11:24:29 *** tuxd00d has joined #gnucash
11:25:20 *** fabior has joined #gnucash
11:28:34 *** mlncn has joined #gnucash
11:37:39 *** kael has quit IRC
11:43:58 *** fabior has quit IRC
11:59:50 *** jralls has joined #gnucash
11:59:51 *** ChanServ sets mode: +o jralls
12:03:02 *** jralls has quit IRC
12:17:16 *** jralls has joined #gnucash
12:17:16 *** ChanServ sets mode: +o jralls
12:18:03 <jralls> gjanssens: Thanks for cleaning up my mess.
12:21:03 <jralls> gjanssens: Now to webkit: What about instead of WebKit we use https://github.com/litehtml/litehtml and draw the results directly on a Cairo surface?
12:21:13 <gjanssens> jralls: you're welcome
12:22:17 <jralls> gjanssens: We'd also need either to provide for javascript or replace jqplot with something in C/C++; gnuplot seems popular and widely supported.
12:23:25 <jralls> That might or might not be more work in src/html, but compared to a gtk3 conversion might be less work overall.
12:25:03 <gjanssens> jralls: hmm, that's a big change as well
12:25:39 <gjanssens> I'm not sure gtk3 conversion in itself is big, at least not in the gnucash code itself.
12:25:59 <gjanssens> For the extra platforms like windows and OS X it may add quite some overhead though
12:29:55 <gjanssens> I know mingw-64 comes with most of our dependencies precompiled (including webkit). Unfortunately we're not using that platform yet
12:30:24 <gjanssens> Do you have experience with gtk3 on OS X ?
12:31:41 <gjanssens> Back to litehtml vs webkit, I do think in the long run webkit is overhead and litehtml could be a viable option
12:31:52 <jralls> Yes. Gramps uses Gtk3, and gtk-osx has been able to build it since it was 2.9.x. The change on the OSX build system is trivial.
12:32:25 <gjanssens> However if we intend to move away from webkit, we may want to think further and move away from html as well.
12:32:51 <gjanssens> But I think we're too late in the development cycle to really go that route.
12:33:51 <gjanssens> I fear it will mean reworking several reports which I enjoy much less than porting to gtk3
12:34:55 <jralls> Moving away from html completely means rewriting all of the reports. Changing html engines just means changing src/html... and converting from WebKit1 to WebKit2 is also changing html engines.
12:36:13 <gjanssens> Webkit1 to Webkit2 means we keep javascript for now. litehtml requires to replace that as well
12:36:20 <gjanssens> Or implement it somehow
12:36:31 <gjanssens> (brb)
12:36:39 *** mrklintscher has quit IRC
12:41:36 <jralls> Yes, there are a couple of javascript libraries out there we could use. I think V8 (https://github.com/v8/v8) is widely supported. I think we'd have to add a <script> handler to litehtml to pass the javascript to it and get the drawing instructions back.
12:50:15 <gjanssens> ok back
12:51:11 <gjanssens> jralls: if you believe it's less work than porting to webkit2, we can try that route as well
12:51:58 <gjanssens> Still I believe regardless of the choice of html renderer, we should port to gtk3 all the same
12:52:17 <jralls> I was looking for webkit2 migration instructions while you were afk. I'm not having much success.
12:52:19 <gjanssens> I don't think we can afford another 4 years before we do so
12:52:46 *** ben_john has joined #gnucash
12:53:10 <jralls> Are you worried that distros will start yanking libgtk2?
12:53:19 *** Mechtilde has joined #gnucash
12:53:20 <gjanssens> And at the current c++ conversion pace I looks like the next major release will not be ready yet for a port to qt or wxwidgets
12:54:43 <gjanssens> That's one possibility. The other is that gtk2 applications will start to show their age as time progresses
12:55:05 <gjanssens> Which I think will make gnucash less attractive in the long run
12:56:04 <jralls> We don't need a pure C++ backend to use wxWidgets or Qt. We *do* need to extract the business logic from the Gtk code.
12:56:42 <gjanssens> True. I did that in the csv transaction importer, so I see what you mean
12:57:24 <gjanssens> But it'll be more fun to port to Qt or wxWidgets if more of the base code is in C++ imo
12:57:47 <gjanssens> As a sidenote, perhaps we should reconsider our development model at some point as well
12:57:54 <jralls> Gtk2 applications already show their age. Gtk3 isn't much of an improvement in that regard. Gtk4 is heading towards a more dynamic operation, but it's not yet clear to me how that will work out for an office app like GnuCash.
12:58:19 <jralls> Development model or roadmap?
12:58:22 <gjanssens> 4 years without releasing features puts off users
12:58:42 <gjanssens> And as you note even Gtk wants to shift gears to faster release cycles
12:59:04 <gjanssens> I think both go together
12:59:48 <jralls> And yet even 4 years isn't enough time to make major changes when we have barely a single full-time developer when we add up everyone's time.
12:59:48 <gjanssens> I think our current way of working is still partly due to our cvs/svn history in which branching and merging was a nightmare
13:00:00 <gjanssens> I understand
13:00:58 <gjanssens> The alternative (very experimental) idea I was playing with was to rely more on feature branches that merge-when-sufficiently-ready into a releasable branch
13:01:27 <jralls> Aren't we doing that now?
13:02:04 <gjanssens> Yes and no. We merge into master, which only gets released every 3-4 years
13:02:28 <gjanssens> And we're much more relaxed about code quality on that branch until we start doing beta releases
13:03:12 <jralls> That's because we release every 3-4 years. We can make that every 2 years, maybe with only 3 months of beta instead of 6.
13:03:31 <gjanssens> This works fine for big features like a c++ rewrite. It doesn't work for smaller features which we currently don't allow on maint for various reasons.
13:04:02 <gjanssens> I've had to tell users their issue was fixed and they would see it in a year or two. That's not good.
13:05:06 <gjanssens> So perhaps the shift I'm looking for is a process that lets us add smaller features to the stable series and yet keep it stable.
13:05:28 <gjanssens> I realize this would require a much better test coverage than we have now
13:05:42 <gjanssens> And another bottleneck would be translations
13:06:08 <jralls> So your concern is more major bug fixes that require substantial changes. We can be more flexible on that. I think I pushed the envelope a bit last year with the pricing change and the change of neutral time.
13:07:05 <gjanssens> Yes, indeed. But not only bug fixes, smaller features as well.
13:08:15 <gjanssens> I'd have to scroll back in the history to find a good example but the general point is I see more and more other software always releasing a mix of bugfixes and "features/improvements"
13:09:13 <gjanssens> We've been fairly strict on bugfixes only. I'm questioning that policy now, though we may not be ready to do better (see test coverage and such)
13:09:50 <gjanssens> I brought it up in the context of gtk3 really.
13:10:29 <gjanssens> Suppose we focus now purely on getting rid of webkit1, it would push gtk3 a couple of years out
13:10:49 <gjanssens> Even though the work to complete the migration to gtk3 would only take a month or two
13:11:36 <gjanssens> So if after 2.8, gtk3 could go into stable as soon as it's ready (with proper testing obviously) people could have it in less than half a year
13:11:54 <gjanssens> This is just one example
13:12:05 <jralls> It took more like 6 months to change Gramps over.
13:13:04 <gjanssens> Ok. Other than the register I have all required linux changes in a branch already, so it depends on how much work the register would become
13:13:08 <jralls> BTW, there are performance issues on Gtk3 GtkTreeViews when there are more than a couple of thousand rows in them. Gramps had to window the data to get around that.
13:13:42 <frozenjim> FWIW: Today's vision of Agile "release first, test later" is why I am not using a different accounting software. I am SUPER happy that GNUCash sticks to the unix principle of doing one thing well. Bells and whistles scare me. They bring bugs and annoying "upgrades".
13:14:03 <frozenjim> 2 cents.
13:14:13 <gjanssens> Good to know, and good you have the experience. We'll need it if we want to finish the gtktreeview port of the register
13:14:29 <jralls> frozenjim: Not that GnuCash has any shortage of bugs! :-/
13:14:51 <frozenjim> :-) Still the most stable software I use daily.
13:15:19 <frozenjim> We don't thank you guys enough. You do an incredible job.
13:15:19 <gjanssens> frozenjim: I'm not promoting "release first, test later", rather "release as soon as well tested" where we currently doing "release every 3-4 years with whatever is ready"
13:16:07 <frozenjim> Yeah, I get it.... your concerns are valid. But I know devs can panic sometimes when there is no fire.
13:16:19 <frozenjim> "The barn looks fine from inside".
13:16:43 <gjanssens> As for the registers, I will probably first try the goocanvas route.
13:16:49 <jralls> gjanssens: So how *do* we handle user testing?
13:16:56 <gjanssens> From the statistics you mentioned to Bob a bit back it looks like not too much changes would be required
13:17:25 <gjanssens> jralls: currently that's another weak point and one more reason for me to migrate to gtk3 as fast as possible
13:17:32 <gjanssens> Let me explain what I mean there
13:18:01 <gjanssens> It's currently pretty difficult for users to get hold of an unreleased gnucash, yet ready to install
13:18:17 <gjanssens> I have set up my copr repository for this and we have the windows nightly builds
13:18:44 <gjanssens> But outside of Fedora and Windows, users need to roll their own, which is a pretty high barrier for most
13:18:44 <jralls> I think drawing directly on a Cairo surface is more promising, particularly in Gtk3 which exposes the Cairo surface for just that.
13:19:59 <gjanssens> I believe I looked into that but it required quite a bit of extra glue to integrate widgets on that surface and stick with the visuals of the theming engine
13:20:03 <jralls> So we need a Debian/Ubuntu equivalent of copr and Mac weeklies...
13:20:19 <gjanssens> I think most of what goocanvas does is fill those gaps. It does write directly on cairo
13:20:32 <gjanssens> Back to the other thread...
13:20:40 <gjanssens> Yes we'd need something like that.
13:21:01 <jralls> No theming engine in Gtk3 after 3.8(IIRC). Theming is done with CSS and the engine is built in.
13:21:33 <gjanssens> For linux I think the most promising format would be Flatpack. It's all over the place and meant to be distribution agnostic
13:22:02 <gjanssens> However unless we want to package gtk2 ourselves in flatpack, we should migrate to gtk3.
13:22:32 <gjanssens> Flatpack provides a standard gtk3 environment, which would simplify packaging gnucash for it
13:22:53 <gjanssens> So that would cover easy to install test builds for (almost) all linux distros
13:23:33 <gjanssens> I have no idea how difficult it would be to automate a nightly OSX/Quarz build
13:24:29 <jralls> Pretty easy, actually, as in a one-line cron job.
13:25:35 <gjanssens> Good. And probably some lines to give it a proper (versioned) name and upload it to somewhere for users to consume.
13:26:07 <jralls> Well, 1 line to do the build, one line to make the bundle, and 2 or three lines to make the dmg and upload it somewhere.
13:26:32 <gjanssens> All of this is irrelevant for our 2.8 cycle though. But we should pick this up once that release is out and the first dust has settled IMO
13:26:58 <gjanssens> But with this you have an idea of where I'd like to go.
13:27:33 <gjanssens> As for the theming vs css I haven't been following the gtk evolution for some time
13:27:41 <jralls> Well, part of it's irrelevant. It's relevant to deciding whether to do Gtk3.
13:28:57 *** tuxd00d has quit IRC
13:29:32 <gjanssens> I think the issue remains the same (theme or css): if we draw directly to cairo, what api is available to ensure what we draw follows the guidelines of the currently chose css styling ?
13:29:39 <gjanssens> chosen*
13:30:01 <gjanssens> From what I remember cairo primitives are pretty direct
13:30:11 <jralls> Gtk evolution is confused just now. They've declared the end of active development of Gtk3. Gtk4 integrates Clutter and "composits" a "frame" with OpenGL. I have no understanding of how portable it's going to be nor how it will work with office applications like GnuCash.
13:30:36 <gjanssens> draw a line from here to there, draw a box of this size over there
13:30:48 <gjanssens> Does it take css styling into account as part of that ?
13:32:35 <gjanssens> My current (outdated) understanding is this is what goocanvas is about. But I'll know more when I looked at it again in more detail.
13:32:43 <jralls> We want whatever we draw to derive from GtkWidget, which provides the styling properties; we use those properties to control the features that we draw.
13:33:23 <jralls> Goocanvas may provide some of the glue for that, I don't know.
13:33:39 <gjanssens> TBI right...
13:33:42 *** tuxd00d has joined #gnucash
13:34:58 <gjanssens> FWIW if it can be done directly on cairo without lots of stuff to implement ourselves I'd prefer that. I'm not too keen on adding dependencies.
13:35:21 <gjanssens> So I'll certainly take it into consideration
13:35:38 <jralls> OK.
13:36:22 <jralls> Now how to divide the work? It sounds like you're ready to go on converting register. Shall I go after WebKit?
13:38:12 <gjanssens> That's fine for me.
13:38:40 <gjanssens> However how will you build and test if the rest is not gtk3 yet ?
13:39:35 <gjanssens> I can disable the complete html and reporting modules while doing my conversion so I won't be bothered by a gtk2 webkit
13:40:03 <jralls> By connecting to an external browser for display.
13:40:20 <gjanssens> I don't know if the registers can be disabled likewise until I'm through
13:41:03 <jralls> You can convert the GtkTreeView registers and use those if you need to.
13:41:24 <gjanssens> No I was thinking of you.
13:41:46 <gjanssens> If you want to go for webkit2, you'll have to build gnucash with gtk3 support IUC
13:42:02 <gjanssens> But the registers won't build in that context
13:42:24 <gjanssens> Or do you think building only the html part for gtk3 ?
13:42:25 <jralls> No, I can direct the webkit calls to a separate process that displays a Gtk3 window.
13:42:45 <gjanssens> Oh, ok
13:42:52 *** fabior has joined #gnucash
13:42:59 <gjanssens> That's something I have no experience with :)
13:43:49 <gjanssens> Perhaps you could commit that intermediate state as well so I can learn from it afterwards...
13:45:24 <jralls> Yes, I'll put the development branch in my github repo as usual.
13:45:44 <gjanssens> Also if you prefer migrating to litehtml/v8 and the work would be reasonable I'm fine with that too btw
13:46:00 *** kael has joined #gnucash
13:46:10 <gjanssens> I haven't had the chance to investigate that route thorougly
13:46:35 <gjanssens> I'm not married to webkit in any way :)
13:46:47 <jralls> WebKit2 already runs as a separate process. The hard part is probably going to be getting that to draw in our GtkNotebook without deadlocking one or the other event loop.
13:47:12 <gjanssens> Ok
13:47:46 <gjanssens> On that note, did you see Bob's most recent patches in bugzilla ?
13:48:11 <gjanssens> They are related to loading our jqplot charts
13:48:29 <jralls> libehtml won't have *that* problem, we just get a surface and draw. Integrating JS will be the hard part there.
13:48:53 <jralls> I saw the bug mail but didn't look at the patches.
13:49:16 <gjanssens> You may want them merged before you start redoing the html interface
13:49:42 <gjanssens> I haven't tested them yet though and I have some questions for Bob still
13:51:09 <gjanssens> Or one more precisely: whether he considered the web-view-ready signal
13:51:23 <gjanssens> I'll ask on the report
13:51:34 *** fabior has quit IRC
14:22:40 *** kael has quit IRC
14:25:57 *** fekepp has joined #gnucash
14:42:31 *** fekepp has joined #gnucash
14:44:03 <jralls> gjanssens: I just re-reviewed src/html/gnc-html-webkit against the WebKit2 WebKitWebView docs. Looks like the teeny bit of API we use isn't any different, so for a first pass all of the work will be having gnc-plugin-page-report make a Gtk3 window.
14:45:44 <warlord> jralls: Huh? I'm not sure how that is possible.
14:46:26 <warlord> WOW... I wonder how they accomplished that!?!
14:46:37 <jralls> How who accomplished what?
14:48:11 <jralls> As for how it's possible, it currently is called to provide a widget to either stick in a GtkNotebook or to create a new window depending on a preference. That just needs to be short-circuited so that it only creates a window... and if it's linked against libgtk3 it will be a Gtk3 window.
14:48:26 <jralls> There are a few details I left out...
14:49:26 <gjanssens> jralls: that looks promising
14:49:46 <warlord> jralls: getting that email through to -announce
14:51:55 <jralls> Ah, you were replying to yesterday. It looks like his MTA connected directly to code and passed through the message by SMTP, somehow bypassing the mailing list.
14:52:33 <jralls> Except that the mailing list processed the "to" address even though he's not an authorized poster.
14:53:01 <jralls> So I guess I should have said "bypassing the mailing list's authentication".
14:59:00 <warlord> But it didn't.. The message got held at 08:37... Somehow it cleared the queue at 16:05
14:59:40 <jralls> So maybe Liz blessed it through by mistake?
14:59:57 <warlord> MAYBE.. But the list had no owner.
15:00:08 <warlord> (not sure why).
15:04:08 <warlord> Hmm, it does look like Liz let it through.. I see the logs at 16:0x
15:06:49 <warlord> I just emailed Liz
15:15:48 *** mlncn has quit IRC
15:35:08 *** mlncn has joined #gnucash
15:37:14 *** KaiForce has joined #gnucash
15:45:17 *** haclong has joined #gnucash
15:47:13 *** ben_john has quit IRC
15:49:48 *** Mechtilde has quit IRC
16:10:28 *** mlncn has quit IRC
16:25:01 *** yamd has joined #gnucash
16:25:42 *** yamd has quit IRC
16:27:03 *** digiyam has joined #gnucash
16:44:23 *** mlncn has joined #gnucash
16:46:19 *** haclong has quit IRC
16:47:14 *** fekepp has quit IRC
16:56:18 *** digiyam has quit IRC
17:27:23 *** haclong has joined #gnucash
17:43:49 *** odo2063 has quit IRC
17:46:46 *** User_ has quit IRC
17:55:21 *** gjanssens has quit IRC
17:59:57 *** rickoehn has quit IRC
18:04:31 *** bastianilso has quit IRC
18:18:00 *** bastianilso has joined #gnucash
18:29:57 *** bastianilso has quit IRC
18:36:57 *** mlncn has quit IRC
18:37:20 *** jchonig has quit IRC
18:42:51 *** kael has joined #gnucash
19:02:26 *** jchonig has joined #gnucash
19:51:30 *** mlncn has joined #gnucash
20:03:17 *** kael has quit IRC
20:51:55 *** haclong has quit IRC
20:56:44 *** mlncn has quit IRC
21:12:52 *** CDB-Away has joined #gnucash
21:43:48 *** kael has joined #gnucash
21:52:56 *** mlncn has joined #gnucash
22:28:08 *** ben_john has joined #gnucash
22:29:47 *** ben_john is now known as MrWhite
22:31:59 *** MrWhite is now known as ben_john
22:35:01 *** ben_john is now known as MrWhite
23:24:46 *** kael has quit IRC