Gnucash 2.6.10 question - Why WebKit ?

[Geert Janssens]

On Tuesday 29 December 2015 12:58:03 Fred Smith wrote:
> On Tue, Dec 29, 2015 at 05:19:27PM +0000, Arno wrote:
> > Dear Bill and Geert,
> > 
> > Thanks for your updates. I know about the EPEL repository and have
> > been using it for years in RHEL 5, 6, Centos 5 and 6, but it always
> > gives me unresolvable dependancy issues after maybe >1 years of
> > usage, so I am trying to stay far away from it if possible for my
> > CentOS 7 setup.
> Have you configured priorities=xx in all the .repo files in
> /etc/yum.repos.d? If not, I suggest that it's a good idea, BEFORE you
> get into the state where you get those dependency errors. the default
> (RHEL, Centos, etc) repos should be the lowest value (highest
> priority) and others working their way upwards. I make EPEL the next
> highest, so it will override other non-dist repos.

That would be my advice as well. Or alternatively keep EPEL disabled by default and only 
enable it temporarily to install extra libraries not in the main Centos repos. That's what I do and 
I can't remember having issues with this in the last 5 years at least.

IIRC correctly EPEL should never replace any package available in the main Centos repo, so in 
the worst case, a package in EPEL needs an update at some point because it depends on a 
package (or version of a package) that's no longer provided via the main repositories. EPEL is a 
community project so if you get into such state, you can ask the maintainer for an update.

I'll also note that the dependency issue I refer to above would also occur when you build from 
scratch yourself.

Regarding libwebkitgtk, I checked and indeed it's not part of the official RHEL/Centos 
repositories. It comes via EPEL, which is quite acceptable because GnuCash itself isn't in the 
official repositories either.

Finally as to your initial question "Why webkit?"

- gtkhtml was replaced because it lacked css/javascript support at a time there was interest in 
improved reporting. Only small parts of our report system has been adapted to make use of this 
though.

- using an external web browser for reporting would reduce the level of integration there is now. 
It's more than just "nice to have a separate tab with the report". Several reports contain links 
that when clicked open registers, invoices or drill-through reports. All of that would no longer be 
possible when the reports are opened in an external web browser.

Having said all that, I'm not particularly attached to webkit per se. But the alternative will have 
to be with something that allows for the same level of integration as mentioned above.

Regards,

Geert