<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 23, 2017 at 10:43 PM, Christopher Bayliss <span dir="ltr"><<a href="mailto:christopher.j.bayliss@gmail.com" target="_blank">christopher.j.bayliss@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The recent release made me think about this. :)<br>
<br>
I imagine the GTK3 support must be pretty bad now as there have been a<br>
lot of API changes, but I haven't used xiphos in awhile, life has been<br>
**very busy**. So I was thinking about a way to make it easier to use<br>
newer GUI toolkits:<br></blockquote><div><br>It still compiles just fine against the latest versions of GTK 3. So long as you aren't asking for the WebKit based editor with the WebKit2 API, then you can definitely get the job done with GTK3. As for how it looks or works, I have no idea on that.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We could separate out all the cool features of xiphos that are not GUI<br>
related and put them into a library called libxiphos.<br></blockquote><div><br></div><div>This is the route that BibleTime took. It is now available with at least 3 different front ends - one on Mac/Windows/Linux, the other two on Android. The separation was good for allowing multiple frontends, but also good for cleaning up and better defining the code within the application. I don't think that libbibletime is a uniquely installable artifact, but it's built as a separate step before the selected GUI is compiled onto the application.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Then write a new frontend in, for example, python and GTK3. Or not. If<br>
we have libxiphos, it would be easier to use an entirely different<br>
toolkit, like Qt5.<br></blockquote><div><br></div><div>I would suggest moving away from Python for this complex of an application. All moving to Python would do for us is make it harder to detect problems as the toolkits shift out from under our feet.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I guess my point is it will get harder to maintain the GTK3 part of<br>
Xiphos as they change the way it works more with each release, meaning<br>
we are going to have to rewrite the way we use the GTK3 API anyway.<br>
However it looks like the GTK team is working on a plan to make this<br>
easier:<br>
<br>
<a href="https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/" rel="noreferrer" target="_blank">https://blog.gtk.org/2016/09/<wbr>01/versioning-and-long-term-<wbr>stability-promise-in-gtk/</a><br>
<br>
IDK if my idea is a good solution, but I believe we are going to have to<br>
figure something out, so I proposing it anyway. :) One of the advantages<br>
of using a scripting language like python to write the frontend in is,<br>
it would be fast to write. (I hate python, but I see it's uses) And if<br>
we have libxiphos, which would be largely c and c++, we wouldn't have<br>
any of the performance issues that python commonly brings with it.<br></blockquote><div><br></div><div>The problems with Python are much less about performance than about maintainability across a large code base. Consistently, across all software, the larger the code base, the better are the results and impacts of sticking with a language that has a discrete compile step and explicit typing, type checking, argument checking, etc. Moving backwards, intentionally, from C/C++ to Python would be to give up all the current warnings and alerts that tell us when our underlying widget library has shifted.<br><br></div><div>I think the biggest thing that would benefit us in the planning is to setup a matrix of what combinations of libraries and toolkits do we depend on, and which ones do we absolutely need. Currently we have multiple versions of GTK2 that are supported, several versions of GTK3 that are supported, WebKit or WebKit2 for display, WebKit or GTKHTML for edit, and we have support for either Windows or Linux and an outstanding request for Mac OS X support.<br><br></div><div>We should endeavor to minimize this matrix. For instance, I would propose we move entirely to a single display technology and drop support for older versions: drop support moving forward towards 4.1 for all GTKHTML and all WebKit1 technology; completely eliminate any GTK version below 3.20 (as this is currently the latest we check for). Perhaps we have to keep one additional set of displays for Windows, but we should not try to support that technology also on Linux if it does not come for free with the supported Linux implementation.<br><br></div><div>If we could do that, then building and improving and moving forward would be much easier. As it presently stands, it is very difficult to build a build anything remotely resembling a unified experience for Xiphos across even just the two biggest distros (Ubuntu 17.04 and Fedora 26) as Fedora is dropping support for WebKit1 which means the Xiphos editor needs GTKHTML to run on the newest Fedora but Ubuntu 17.04 doesn't offer gtkhtml support and so the editor must be built with WebKit1. Both of those experiences could be unified if we had a WebKit2-based editor. That is, if such a thing is possible.<br><br></div><div>--Greg<br></div></div><br></div></div>