[xiphos-devel] an idea for the future of xiphos

[Greg Hellings]

On Sun, Apr 23, 2017 at 10:43 PM, Christopher Bayliss <
christopher.j.bayliss at gmail.com> wrote:

> The recent release made me think about this. :)
>
> I imagine the GTK3 support must be pretty bad now as there have been a
> lot of API changes, but I haven't used xiphos in awhile, life has been
> **very busy**. So I was thinking about a way to make it easier to use
> newer GUI toolkits:
>

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.


> We could separate out all the cool features of xiphos that are not GUI
> related and put them into a library called libxiphos.
>

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.


>
> Then write a new frontend in, for example, python and GTK3. Or not. If
> we have libxiphos, it would be easier to use an entirely different
> toolkit, like Qt5.
>

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.


> I guess my point is it will get harder to maintain the GTK3 part of
> Xiphos as they change the way it works more with each release, meaning
> we are going to have to rewrite the way we use the GTK3 API anyway.
> However it looks like the GTK team is working on a plan to make this
> easier:
>
> https://blog.gtk.org/2016/09/01/versioning-and-long-term-
> stability-promise-in-gtk/
>
> IDK if my idea is a good solution, but I believe we are going to have to
> figure something out, so I proposing it anyway. :) One of the advantages
> of using a scripting language like python to write the frontend in is,
> it would be fast to write. (I hate python, but I see it's uses) And if
> we have libxiphos, which would be largely c and c++, we wouldn't have
> any of the performance issues that python commonly brings with it.
>

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.

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.

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.

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.

--Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/xiphos-devel/attachments/20170424/e3fa47a7/attachment-0001.html>