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