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

[Christopher Bayliss]

On Mon, Apr 24, 2017 at 02:45:28AM -0500, Greg Hellings wrote:
> On Sun, Apr 23, 2017 at 10:43 PM, Christopher Bayliss <
> christopher.j.bayliss at gmail.com> wrote:
> >
> > 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.

Good points, I agree. Just for the record, my reasoning is if we have
libxiphos, we wouldn't necessary have to use c/c++ for a frontend.
However I prefer c. :) Where this could be of benefit, for example:
someone could write a cocoa interface in swift (for macOS). Or an
android interface in java (or whatever Google's android java fork is).

> 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.

This is a brilliant idea, although IMO we should target GTK 3.14 and
newer. Debain stable (soon to be oldstable) and Centos 7 both have GTK
3.14, everything else has a newer version. (Ubuntu 16.04 has 3.18)
 
> 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.

One things about webkit2gtk that really annoys me is the lack of
documentation. But it was two year ago when I last looked, hopefully
that has been fixed. But even without documentation, I'm sure we could
figure this out.

One problem that we will start facing very soon that I forgot to mention
in the first email is xiphos' dependency on X11. We use it for keyboard
shortcuts. This means that xiphos will be running under the xwayland
compatibility mode on Fedora 25 and later. Also Ubuntu is going to use
wayland by default on Ubuntu 18.04[1]. This adds weight to fixing our GTK
implementation and removing X11.

[1] http://www.omgubuntu.co.uk/2017/04/ubuntu-will-run-wayland-default