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. * 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. Regards, Geert _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
