> On 2013-01-24 15:50 (GMT-0600) Timothy Pearson composed:
>
>> Mozilla has explicitly stated that it will not support embedding Firefox
>> sessions in any third party application, and has removed all programming
>> hooks needed for doing so.
>
> So Camino is no more?

I don't know, sorry. :-)  When I looked into this many months ago the
interface to the Firefox core was being deprecated and removed, and I have
heard no information to the contrary since.

>>  This leaves TDE with three long-term options:
>> 1.) Use Webkit (preferred)
>> 2.) Investigate embedding a Chromium instance
>> 2.) Completely remove the KHTML kpart (not recommended)
>
>> I would prefer to embed a Webkit browser kpart, as I expect website
>> compatibility with Webkit to increase in the future, and a full-featured
>> Webkit widget already exists.
>
> http://fm.no-ip.com/SS/dpi1920x1200x144-gecko-konq3-chromium-konq4.png
> demonstrates that there is a cost to users of high density displays when
> Webkit is used to display web content. What cannot be seen in the
> screenshot
> is that Chromium's behavior matches IE, Opera and Safari, which is that
> physical units don't actually exist except when physical display density
> is
> in fact 96 DPI. Gecko also matches that fixed 3:4 pt:px ratio, but
> provides a
> workaround through the proprietary mozmm unit that is unnecessary for
> KHTML
> to display physical units at their actual size whenever desktop DPI
> matches
> physical display DPI.
>
> I vote stick to KHTML.
>
> URL to test for yourself: http://fm.no-ip.com/Auth/dpi-screen-window.html

To everyone on this list, how does the KDE4 version of KHTML compare with
WebKit?  Better or worse compatibility with most websites?  If KHTML is
pretty much the same as WebKit as far as CPU/RAM usage and website
compatibility, the easiest solution would be to integrate KHTML as a 
kioslave in very much the same way as the old version of KHTML works now
in TDE...

Thanks!

Tim