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

[Geert Janssens]

Op zaterdag 7 september 2019 17:56:46 CEST schreef John Ralls:
> > 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.

Yes, agreed.
I have been thinking to deal with it the way wxWidgets does [1]: on linux it 
links webkit for it's htmlview, on Windows it links to Windows' own html 
component. As our htmlbackend is swappable we may be able to do a similar 
thing for gnucash. That's the idea, but I haven't had time so far to try this.

Regards,

Geert

[1] https://docs.wxwidgets.org/3.0/classwx_web_view.html