> On Sep 7, 2019, at 7:14 AM, Geert Janssens <geert.gnuc...@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.gnuc...@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 

> * 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: 

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
gnucash-devel mailing list

Reply via email to