Op zaterdag 7 september 2019 17:56:46 CEST schreef John Ralls: > > 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 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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
