[xiphos-devel] webkitgtk, gtkhtml, and GTK2 dependencies

[Karl Kleinpaste]

On 6/7/24 12:32, Scott Buchanan wrote:
> Even setting aside the monumental task of actual implementing whatever 
> change is needed, first a consensus needs to be reached which approach 
> we take. In my opinion, the best option would be to use a stripped 
> down, not even necessarily HTML-based, renderer in place of both 
> webkitgtk and gtkhtml which is cross platform and well supported. Feel 
> free to challenge me if that seems like a bad idea.

I wanted to let this sit and stew a few days, in hopes that some other 
folks might have something to say about it. OK, well, perhaps not.

Up to this point, differences between the Windows' build's restriction 
to GTK2¹ (with older webkit) have been handled entirely by #ifdef'ing to 
distinguish the variances between older and newer forms.

I suppose my initial wondering is how this is not sufficient going 
forward in a world where the modern toolkit is webkit2gtk-4.1 (as seen 
in recent commits to cmake/XiphosDependencies.cmake) versus where we 
remain for Windows.

Aside from that, I have to wonder what alternative renderer might be 
possible. Bear in mind that there have been 5 display engines in Xiphos 
over the years (gtkhtml, seamonkey, gtkmozembed, xulrunner, webkit) and 
every time it has changed it has represented an awful effort that I have 
referred to as "treadmill work" because the result hasn't actually gone 
anywhere but it's work that has been needed in order to move the base 
for display forward as older toolkits fell out of favor.

I have no idea what other toolkits would be available if we wanted to do 
this yet again. I will say that moving away from an HTML renderer would 
be an especially difficult choice because HTMLisms are deeply, deeply 
embedded in the code. Aside from general display, the fact that the 
editor remains as libgtkhtml is a source of pain -- we know that it is 
deeply outdated and in need of being replaced.

Opinion or further information is most welcome.

The other Windows-specific matter needing thought is that the version of 
Sword used for Xiphos is a Xiphos-specific hacked version employing glib 
as a means of insulating Xiphos' code from (notably) NTFS peculiarities. 
This became a necessity long ago, right after first Windows 3.0 release 
because of the need to handle (again, notably) accented characters in 
such fundamental places as users' login names. Sword itself is built and 
attached to the overall Windows build and the patch needed to support 
this almost certainly needs to be updated to handled today's Sword. Greg 
used to handle this but it has sat dormant a long time.

--karl

--
¹ For anyone who isn't aware, the Windows build is effectively stuck 
with GTK2 and older WebKit 1.0 because there were never produced 
functional builds of more recent versions of these libraries, and thus 
that's where the Windows side sits. It means a slightly different and 
slightly less featureful display, especially in multi-column display, 
where more recent WK balances vertically but in Windows it fills 
vertically leaving a fractional last column.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://crosswire.org/pipermail/xiphos-devel/attachments/20240617/08e4fe7e/attachment.htm>