dependencies on KJS/KHTML in kdelibs and kdebase-runtime

[Aaron J. Seigo]

On Friday, October 1, 2010, John Layt wrote:
> Would I be right in thinking that if apps use the KPart it will
> automatically switch between khtml/kjs or kdewebkit/qtscript depending on
> what's available on the platform and not notice a difference in most
> cases?  Or is work needed here still?

the first KPart returned will be whatever is on the system and is marked as 
prefered. however, some apps look specifically for the KHTML part and use its 
API directly. those apps would need to be ported, or remain using KHTML. 

porting could happen in a couple of ways:

* design a generic interface (ala KTextEditor's interfaces) that both KHTML 
and KWebKit would implement, making the "look specifically for KHTML" 
unecessary. this would require looking at what API apps are actually using. it 
may not be able to capture 100% of usage, but it would probably cover most. 
this would also require both KWebKit and KHTML implementing the interface(s).

* port the "requires web renderer specific API above what is available in 
KPart's API" apps to KWebKit or QtWebKit.

personally, i'd prefer the shared interface as it means people can still 
easily use KHTML/KJS at their pleasure and it removes a hard dependency from 
those apps altogether.

in the proposed mobile profile for kdelibs right now, though, even KWebKit 
isn't included, since KWebKit is all about desktop env integration things 
which are not relevant on mobile platforms. it's an area of investigation that 
is needed. the shared interface bit might allow us to provide, in those cases, 
a small kpart that provides that interface and which uses "raw" QtWebKit 
underneath.
 
> It remains important for us to maintain khtml/kjs, both due to api
> guarantees and as a safety net.  No-one should be discouraged from working
> on or using khtml/kjs (especially if that is their "itch"), and apps are
> still free to choose to use khtml/kjs.

yep :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20101001/323e5588/attachment.sig>