Delete gtk 2.0 code?

[yetist]

8 years have passed since the first release of gtk 3.0 in 2011. I think it is time to drop support for gtk2.0. This way we can clean up the code and help to better maintain the existing code.

[karlkleinpaste]

that will depend entirely on the level of support for gtk3 in windows, namely in how well it displays. up to this point, the quality of display of gtk3 under a windows build has been nothing less than atrocious. gtk2 is perhaps ancient, but the mingw builds of it work and display very well.

[yetist]

Are you telling the truth? Is there a same display problem with gimp-2.10 and gedit-3.20 running on windows?

[karlkleinpaste]

if you're going to accuse me of lying, this discussion will be short.

i hadn't even bothered trying to build for windows using gtk3 in a couple years, because the running result looked so atrocious up to then, and there seemed to be no change toward improving it. gtk2 visuals are easily controlled using c:/Program Files/CrossWire/Xiphos/etc/gtk-2.0/gtkrc. gtk3 never seemed to offer something similar, that we could find when trying to get win32+gtk3 going.

feel free to give it a try yourself and see how it looks. maybe things have changed in recent mingw gtk3 builds. maybe facilities for controlling visuals in win32 w/gtk3 are up to par again. i don't know because i haven't looked in quite a while.

[yetist]

Sorry, I have no intention of accusing you of lying, just saying that what you said may not be true. In gtk3, similar to gtkrc is gtksettings. The theme and other things can be set via settings.ini, although I don't know what you have, but I think it can be fixed.

[karlkleinpaste]

when we can buld again for windows using gtk3, and get a good-looking display, i'll be ok with removing the gtk2 code.

[domcorbex]

I'm afraid building for windows using gtk3 is not coming soon, the last comment of issue Update webkitgtk-3.0 to webkit2gtk-4.0 #3484 on msys2/MINGW-packages says:

It's unlikely that we'll manage to get this building and maintained without upstream officially supporting Windows.

[greg-hellings]

Yeah, it's monumentally frustrating. Especially since WebKit officially supports building on Windows out of the box. How difficult would it be, I wonder, to include the native WebKit widget directly into a GTK app?

[greg-hellings]

Alternatively, Chromium Embedded Framework exists and works directly out of the box with Windows. Sorry to say, but WebKit is falling by the wayside in favor of Blink/WebEngine. I'm not sure if anything but Safari and Ephiphany still use it and all of them have dropped Windows support from what I can tell.

But that's part of the upgrade treadmill that @karlkleinpaste hates. Here's a guy who demonstrates wrapping Blink into GTK apps including building for Windows with MinGW: https://github.com/cztomczak/cefcapi

[yetist]

webkitgtk-3.0 can be compiled with gtk3, it does not necessarily require gtk2, which is not the real reason why we cannot delete the gtk2 code.

[yetist]

The real problem is that no suitable webkit2gtk package is available under windows, while gtkhtml and webkitgtk-3.0 under LInux have been deprecated, only webkit2gtk is available.

And the HTML editor feature now can only work on gtkhtml and webkit-3.0, and have not been ported to webkit2gtk.

So, how to solve it is a problem.

[greg-hellings]

The problem is: Webkit API v1 is deprecated everywhere and removed in most places. Newer versions of WebKitGTK (anything later than 2.4, current is 2.18) officially don't care about Windows. GtkHTML has been a goner for a long time, as well.

If we want a single display mechanism, we

1) Have to accept that our app will forever be ancient and antiquated on Windows, sporting oodles of active CVEs and worse. 2) We need to find an alternative workaround.

• We could embed Blink directly with the Chromium Embedding Framework, which is compatible with Windows and GTK.
• We could go with official builds of WebKit for Windows, but that would mean we need to give up the Fedora cross-build ecosystem (With Github Actions and Travis CI both offering free build time on Windows machines, this isn't an impossible task. Also, the existence of vcpkg from Microsoft makes this task much less daunting, even if it doesn't include a WebKit package directly). A daunting task, but it might be less daunting than...
• The entire app could be rewritten into a display toolkit that cares about both cross-platform displays AND rich HTML displays.

[yetist]

In my opinion, xiphos needs to support both gtkhtml and webkit2gtk, and include gtkhtml as a third-party dependency fallback.

In an environment with webkit2gtk, html view uses webkit2gtk and html editor uses gtkhtml. In an environment without webkit2gtk, html view uses gkhtml, and html editor uses gtkhtml.

Until one day, we completed the porting of html editor function to webkit2gtk, and webkit2gtk is effective on all platforms, we can delete the gtkhtml related code, and only keep the code of webkit2gtk.

[greg-hellings]

@yetist

1) You're not going to get buy in from packaging folks to embed/vendor gtkhtml. It's just not going to happen. We're going to lose packages in basically every distro out there (maybe Arch excepted?)

2) webkit2gtk is not going to support Windows. The developers don't want to support it and they're not going to support it. WebKit's GTK port exists only to give Gnome a rich HTML widget for its personal vendetta to make Epiphany or whatever its successor might be exist.

So we either need to ditch WebKitGTK entirely, or ditch Windows entirely, if we want to remain up to date. In the world of weird things, I've found this library: https://github.com/zserge/webview which is a header-only library that embeds a native widget (WebKit2GTK on Linux, MSHTML/EdgeHTML/EdgeChromium on Windows, or WebKit on Mac OS) into the window you give it. There's lots of cross-platform options out there. It's now clear the WebKitGTK is not one of them.

[yetist]

1. You're not going to get buy in from packaging folks to embed/vendor gtkhtml. It's just not going to happen. We're going to lose packages in basically every distro out there (maybe Arch excepted?)

Archlinux also does not package gtkhtml, because it has stopped maintenance. I mean add the gtkhtml code to the xiphos code tree, such as 3rd-party/gtkhtml, and compile it together at build time.

[greg-hellings]

1) Arch still provides gtkhtml4-git, which can be installed from aur 2) That's exactly what I'm saying you're going to die on packaging from most any distro anywhere. There is a reason GtkHTML was removed (vulnerabilities, bugs, and no upstream maintenance) and those are the exact reasons that packagers refuse to permit bundled code.

So, if you want to maintain availability in mainline distros (I can speak for Fedora, and I've heard the same from Ubuntu, Debian, and SuSE), that option is a complete non-starter for running on those distributions.

[yetist]

For xiphos, we only need basic HTML display and editing functions, do not need too many functions, and do not need to depends on too large external libraries. Therefore, as long as xiphos can self-contain a small html library and realize html viewing and editing is enough.

The so-called web security issue does not apply to xiphos because its data source is trusted.

[greg-hellings]

Its data source is very much untrusted (anyone can create a Sword module and give it to anyone else to run; our modules are typically downloaded over FTP or possibly HTTP both of which are vulnerable to attacks) and none of that negates the fact that embedding a library is pretty much a terrible idea.

And I can't foresee Xiphos rolling its own HTML widget internally, for sure.

[alerque]

Pretty much have to echo what @greg-hellings is saying all the way down here. You're going to loose packaging on most distros if you start doing things like bundling outdated HTML engines from 3rd party sources, and that includes Arch Linux. It's just a huge no-no.

Supporting multiple outdated and unmaintained HTML renderers is crazy too. This is just an absurd amount of heft to lug around. We're already discussing the editor on the mailing list and dropping GTKHTML does seem like it might happen sooner rather than later.

From this comment, I'm not too keen to see 1 — but any of the three ways of achieving 2 seem viable.

[yetist]

OK, let's get back to the topic. Can the gtk 2 code be deleted?

[karlkleinpaste]

xiphos is completely in bed with gtk, there is no functional gtk3 for windows, and there are no immediate prospects for the complete replacement of either flavor of gtk in the near future.

ergo, not yet, and not any time soon.

[bgermann]

Has the Windows situation changed with GTK4?

[greg-hellings]

I have not yet found any evidence that it has changed. Keep in mind it mainly has 2 issues - both a GTK+ build for Windows, which has existed basically all along. And a build of WebKitGTK for Windows. Which they stopped doing a LONG time ago. Long ago enough that we still need to use GTK2 to tie into that version.

It doesn't seem that the WebKitGTK folks care about ever porting to Windows, frankly. If we want to ever modernize past GTK2 we would need a different HTML display solution.

[bgermann]

vcpkg has a GTK4 port. Maybe using that would help. I guess WebKitGTK is a lost case. Where does the Windows build take its GTK2 version from?

[greg-hellings]

Lots of builds of GTK4 exist for Windows, so that's not the issue here. The problem is that WebKitGTK stopped supporting Windows in 2014 when they moved to WebKit2, and GtkHTML which was our fallback went out of maintenance in 2015. WebKitGTK for Windows now points people towards WebKitCairo, which is supposedly maintained and cross-platform. I haven't even looked into that to know if it's true.

Since we are not leveraging any advanced features of HTML and we are only using locally rendered content, it is unlikely that there is a huge in-app reason to move off the older code. However, it is beginning to fall out of Linux distro repositories as it is now riddled with less efficient code and a huge number of bugs and vulnerabilities. So all the pressure to move off the older code is external. But GTK does not seem interested in supporting an official way to cross-platform render HTML any longer.

If we want to move forward we would need to move to supporting multiple rendering engines based on our platform or to an entirely different solution as WebKitGTK is no longer viable.

[bgermann]

Would an editor component that does not have HTML rendering capabilites suffice? I guess there are plenty of GTK options in this case.

[greg-hellings]

You could use something like a Markdown editor which would then be rendered to HTML is one direction I've considered. But it doesn't help with the fact we don't even have a modern display widget in Windows. I'm not sure we ever even fully updated to WebKit2, did we? The last time I had looked at the editor APIs they had been mostly moved out to very different calls that needed to interact with the rendering subprocess, etc. But it's been a solid 2 years since I really went down that rabbit hole. So I don't know its exact status.

Another choice is to move to something that is better supported, like the Chromium Embedded Framework. That is the library designed to wrap around Blink/Chromium for use exactly as we use WebKit now. It has some demos of it being used in GTK apps, so it's a solid chance that we could get it to work well. But then we have yet another forklift of code to yet another rendering engine.

There are lots of options, each with benefits and drawbacks. Maybe we should start a discussion or Wiki page in the project to outline the different choices?

• Move away from HTML editing directly
• Move away from WebKitGTK on Windows builds
• Move away from WebKitGTK entirely

[TingPing]

I think your conclusions are mostly right, I just want to give slightly more context as a WebKit contributor.

WebKitGTK not supporting Windows is only because of lack of resources. I am confident patches providing such support would be accepted. But I do not expect any of you to take on that task.

While the WinCairo port exists and is maintained I don't think its as simple to use as WebKitGTK though and would take effort to integrate into GTK.

CEF also has no integration with GTK and you would have to do per-platform work yourself. The example code given in the CEF codebase only would work on X11 I believe, and foreign rendering on Wayland for example isn't reasonable to do I think. Actual integration like WebKitGTK would take a good amount of work there.

Embedding web engines in a different toolkit is a lot of work sadly.