[GNC-dev] CMake build system for gnucash-docs

John Ralls jralls at ceridwen.us
Sat Sep 7 11:56:46 EDT 2019

> On Sep 7, 2019, at 7:14 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> Op zaterdag 7 september 2019 16:04:08 CEST schreef John Ralls:
>>> On Sep 7, 2019, at 5:44 AM, Geert Janssens <geert.gnucash at kobaltwit.be>
>>> wrote:
>>> Again I'm not sure of the benefit of adding support for all that at this
>>> point. I think more interesting areas of study could be whether we can
>>> support a Macos native document format or whether the Windows help system
>>> has a way of identifying application documentation system-wide (that is
>>> outside of the application) and whether we need to add something to tap
>>> into that. Those are two platforms we do try to integrate with next to
>>> our gnome integration.
>> MacOS Help's native format is HTML just like everyone else's, packed in a
>> peculiar way just like everyone else's. It displays in an obnoxious window
>> that stays on top of everything. Many third-party applications do what
>> GnuCash already does, which is to use the user's default browser to display
>> help. As for Windows I've noticed that very few Windows 10 applications
>> still use the old Windows-3 help viewer. Most, including Microsoft's,
>> either display help in their own window or use the default browser.
> Good point.
>> Maybe we should follow that trend and get rid of *all* of the system/desktop
>> environment specializations and just open docs in a GtkWebKitView like we
>> do reports... alternatively given the troubles with WebKit maybe we should
>> switch to using the default browser for both reports and docs.
> A few remarks:
> * For Windows and Macos publishing the documentation as html is probably a 
> good way to go for the future, though I find our plain html output a bit 
> bland. If we want to make that our main format, it could do with some well-
> written css for a nicer visual presentation.
> * While on Windows and Macos it may be common to just open a webbrowser with 
> html pages, in the gnome and kde ecosystem the native help browser remains 
> very popular (yelp and khelpcenter respectively). So I wouldn't drop support 
> for ghelp just yet.

I guess that's OK for Yelp, but as you pointed out to Frank we don't support KHelpCenter. Do we require KDE users to install Yelp so that we can display our docs?

> * Opening an external browser for reports will solve our WebKit troubles at 
> the expense of backlinks into the rest of the gnucash data. Some reports have 
> links that refer to a register page, an invoice, another report... All of 
> those can only be handled because we integrate a webviewer inside the 
> application.

Roger, but the way things are headed on Windows the choice may be between having the links and being able to display reports at all: https://bugs.gnucash.org/show_bug.cgi?id=797283

On that note, I tried to build mingw-w64-webkitgtk on the current mingw32. It fails with a symbol not found error linking libjavascript.dll which is probably why Alex decided to drop it. I'll poke at it a bit more after the release, but it's yet another indication that we need to find a different solution for displaying reports on Windows.

John Ralls

More information about the gnucash-devel mailing list