[GNC-dev] WebKitGtk now defaults to Gtk4

[Geert Janssens]

Op zondag 19 november 2023 05:00:49 CET schreef john:
> I spent some time this afternoon poking at webkit replacement. The options I
> found are:
> * Keep using WebKitGtk
> * Figure out how to wrap a native (meaning Apple AppKit or Microsoft)
> WebView in a GtkWidget

I agree it's probably a lot of work, we can get some inspiration from WxWidgets. It has a 
wxWebView class that uses a different backend on Windows (IE or Edge) and WebKit on 
MacOS and Linux.
https://docs.wxwidgets.org/3.2/classwx_web_view.html[1]


> * Send the HTML/JS/CSS to the default browser. This
> will lose the links to GnuCash objects like transactions

Keeping the links as you suggested in another reply in this thread is definitely tricky. I have 
been researching this for an unrelated project. Browsers are (rightfully) very reluctant to 
let a webpage interface with the local filesystem in any way. The only universal method is 
defining a custom handler for the user's default webbrowser. Similar to what we do with 
the integrated WebKit instance, though now it has to be installed for the users default 
browser, so somewhere on the user's system, outside of GnuCash' direct control. I have 
never looked at whether there's a system-wide location to store such handler that's read 
and interpreted by all common browsers. I doubt it though.

Next all links in reports we want to be handled by gnucash need to be set up such that this 
custom handler is called. This is usually done by using a unique protocol or extension to 
the links that are associated with the handler.

Next we need to figure out how the browser can pass this request to a running gnucash 
and how this running gnucash can act on it. I think we may have to complete the 
transition to GtkApplication in order to achieve that. We currently have no way to pass 
messages to a running gnucash. GtkApplication on the other hand has methods to 
respond to re-entrant requests (that is re-launching gnucash would instead delegate the 
parameters as a message to an already running gnucash -- overly simplified explanation).

I imagine there will be several additional complications.

These are some I'm thinking of immediately:
* What should we do if the report remains open in the browser, but gnucash is closed by 
the user, yet the user clicks on a link in the report. Should that start gnucash again ?
* What if the report is open for another gnucash book than the one that's currently open 
in gnucash and the user clicks a link ? I think at the minimum the links need to hold a 
reference to the book for which the report was generated. But that's only half of the 
solution. GnuCash still needs to act on a book mismatch in some way.
* Currently one could have two instances of gnucash running, with a different data set 
loaded and each having their own reports open. What if they both now will send their 
reports to the user's default browser ? How will the browser know what gnucash to 
forward the requests to when a user click on a report link ? Here also the migration to 
GtkApplication could help in solving this issue. Particularly if it's configured to be a 
singleton application. In this case there could only be a single gnucash running accepting 
messages from the browser. As with the earlier issues the links embedded in our reports 
would need to have an indication as to the gnucash book they relate to. This book 
information could be used by the single gnucash instance to act on the proper book.
* That leads to the next design challenge though: currently our backend code may not be 
capable of managing two GncSessions in one running gnucash instance. If we convert to 
GtkApplication in singleton mode, we would loose the option to have two gnucash books 
open at once. To fix that we'd have to rework the engine code to be fully capable of 
managing more that a single open Session.

So this avenue may be possible, but will definitely open a big can of worms if you ask me...

> * Configure a
> GtkTextView to understand HTML tags. This doesn't support charts, printing,
> or PDF export.

While probably less work, the result would be a huge step back IMO.

> * Write reports directly to PDF. There are libraries out
> there but I didn't find any FLOSS ones that mention CSS styling or drawing
> charts in their feature sets.
> 
I don't know of one either. The more common way is to go via an intermediate format, be 
it html or xml or whatever. Pandoc (https://pandoc.org/[2]) comes to mind here as it can 
handle plenty of input formats. However it doesn't do pdf generation directly, it relies on 
other pdf generators. Several are listed on the page I linked. They may be usable directly 
or not.

Regards,

Geert

--------
[1] https://docs.wxwidgets.org/3.2/classwx_web_view.html
[2] https://pandoc.org/