State of Pidgin: The Webkit Dilemma
grim at reaperworld.com
Tue Oct 3 01:58:22 EDT 2017
If you have not yet seen the introduction email with a subject of "State of
Pidgin: Introduction", please go read it first.
As most of you are aware in the 3.0.0 development branch of Pidgin we
swapped out our custom GtkIMHTML widget for a webkit1gtk webview. When
this was added it was great and even Adium theme support was added.
However, the web moves fast and webkit2 has been released.
Porting our code from webkit1gtk to webkit2gtk is non-trivial, but doable.
However, there is currently no support on Windows for webkit2 at all. This
is obviously a problem for all of our Windows users of which that are
many. I don't have exact numbers, but viewing the weekly downloads on
source forge is quite telling.
But the story doesn't end there. webkit1 is deprecated and is being marked
for removal in many Linux distributions due to said deprecation, as well as
it's lack of maintainer-ship, and worst of all, the long list of currently
known security issues.
I've investigated a lot of potential solutions, but so far I've yet to come
up with a clear solution.
As mentioned earlier, webkit2 is not currently supported on Windows. This
is due to at the very least, the lack of the webkit2 IPC API not being
implemented. This is doable for someone that knows Windows development,
but is far outside of my wheelhouse.
Chromium Embedded Framework is awesome, but it is huge. I don't have it
downloaded right now, but iirc the library was about 180 megabytes in
size. That is unacceptable for us as it is NOT published in any
distribution as far as I'm aware.
GtkHTML is no longer supported/maintained, so this is a non-option as well.
https://github.com/litehtml/litehtml looks like it could be usable, but
like CEF it is not packaged by any distributions as far as I'm aware.
Our last and final option that I'm currently aware of, is to clean up
GtkIMHTML. We can always make the conversation widget easier to swap out
with a plugin which would give us the opportunity to move to something else
later, incrementally, without breaking ABI. This is my current contender
for the way to go.
All that said, our requirements are pretty basic. While it might be nice
working client. Right now we're dealing with a death clock that varies
across distributions and we need to pick something. At the very least we
need HTML and CSS support with some way to get events for elements being
clicked on so that we can handle hiding images and other modern IM features
like plugins that enable previews for youtube, vimeo, twitter, etc.
Gary Kramlich <grim at reaperworld.com>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel