[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KHTML, KJS Unfrozen -- details
From:       Richard Moore <richmoore44 () gmail ! com>
Date:       2006-01-10 23:54:32
Message-ID: 5491a5150601101554n2ab0bb13ge47dc67e4caa45b2 () mail ! gmail ! com
[Download RAW message or body]

On 1/10/06, Joseph Wenninger <jowenn@kde.org> wrote:
>
> Is there a chance that KJSEmbed is going  (soon) to be moved to kdelibs,
> if
> KJS should not be used directly anymore ? Or will it still stay in
> kdebindings ?


I think that the core part of KJSEmbed (ie. the wrapper around the
interpreter) can be moved to kdelibs relatively easily. Now that we have Ia=
n
Geiser's new design for the bindings code, this can be kept more loosely
coupled, so it would be possible to hold it in another module. That said,
the discussions in Malaga resulted in agreement that we should integrate
KJSEmbed tightly into applications (eg. as is already planned for Plasma,
see Zack's work on Dashboard compatibility as an example). Together this
implies that KJSEmbed should be in kdelibs, though possibly without full
access to all of the Qt/KDE apis.

Rich.

[Attachment #3 (text/html)]

<br><br>
<div><span class="gmail_quote">On 1/10/06, <b class="gmail_sendername">Joseph \
Wenninger</b> &lt;<a href="mailto:jowenn@kde.org">jowenn@kde.org</a>&gt; \
wrote:</span> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px \
0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Is there a chance that KJSEmbed is \
going&nbsp;&nbsp;(soon) to be moved to kdelibs, if<br>KJS should not be used directly \
anymore ? Or will it still stay in <br>kdebindings ?</blockquote>
<div>&nbsp;</div>
<div>I think that the core part of KJSEmbed (ie. the wrapper around the interpreter) \
can be moved to kdelibs relatively easily. Now that we have Ian Geiser's new design \
for the bindings code, this can be kept more loosely coupled, so it would be possible \
to hold it in another module. That said, the discussions in Malaga resulted in \
agreement that we should integrate KJSEmbed tightly into applications (eg. as is \
already planned for Plasma, see Zack's work on Dashboard compatibility as an \
example). Together this implies that KJSEmbed should be in kdelibs, though possibly \
without full access to all of the Qt/KDE apis. </div>
<div>&nbsp;</div>
<div>Rich.</div>
<div>&nbsp;</div></div>



[prev in list] [next in list] [prev in thread] [next in thread]