<div class="gmail_quote">On Fri, Mar 20, 2009 at 3:37 PM, John Tapsell <span dir="ltr"><<a href="mailto:johnflux@gmail.com">johnflux@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">2009/3/20 Aleix Pol <<a href="mailto:aleixpol@kde.org">aleixpol@kde.org</a>>:<br>
><br>
><br>
> On Fri, Mar 20, 2009 at 3:27 PM, John Tapsell <<a href="mailto:johnflux@gmail.com">johnflux@gmail.com</a>> wrote:<br>
>><br>
>> 2009/3/20 Aleix Pol <<a href="mailto:aleixpol@kde.org">aleixpol@kde.org</a>>:<br>
>> > On Wed, Mar 18, 2009 at 1:12 PM, Allen Winter <<a href="mailto:winter@kde.org">winter@kde.org</a>> wrote:<br>
>> >><br>
>> >> Howdy,<br>
>> >><br>
>> >> I assume we are all following the "Qt MathML Widget" discussion on<br>
>> >> k-c-d.<br>
>> >> Ideas on that issue?<br>
>> >><br>
>> >> My first thought was sourceforge with some folks to maintain it there.<br>
>> >><br>
>> >> kdesupport is basically the same as sourceforge, but somewhat easier<br>
>> >> to deal with.<br>
>> >><br>
>> >> Would kdelibs be ok? doesn't feel "right" to go there, but I won't<br>
>> >> object<br>
>> >> if someone claims maintainership there.<br>
>> >><br>
>> >> ??<br>
>> >><br>
>> >> --<br>
>> >> Allen Winter | Software Engineer | 1-888-872-9339<br>
>> >> KDAB, Inc. | "Platform-independent software solutions"<br>
>> >> <a href="http://kdab.com" target="_blank">http://kdab.com</a> | 1-866-777-5322 (US) | +46-563-540090 (Sweden)<br>
>> ><br>
>> > Referring to what thiago macieira said on the k-c-d list, I think that<br>
>> > he<br>
>> > has his point.<br>
>> > We should only put it in kdelibs if we're forking it (what are your<br>
>> > plans<br>
>> > john?) and renaming it.<br>
>><br>
>> I think we almost certainly want to do this, and encourage people to<br>
>> expand on it.<br>
>><br>
>><br>
>> ><br>
>> > Otherwise I'd be fine if it is in a separate library in kdesupport, but<br>
>> > since they don't ensure ABI stability i'm not sure whether that would be<br>
>> > a<br>
>> > good idea.<br>
>> ><br>
>> > Thanks,<br>
>> > Aleix<br>
>> ><br>
>> > PS: I'm not on this list, CC me if tehre is any other message on this<br>
>> > subject please.<br>
>> ><br>
><br>
> Wouldn't it be a better idea to keep the work on KFormula? we don't want 2<br>
> KDE codes doing the same thing!<br>
<br>
</div></div>It might be worth dropping the KDE4 KFormula.<br>
I would suggest either:<br>
<br>
*) Go with QtMMlWidget. It works. It's read only, but it's still<br>
useful and if we can pry open the API a bit we could get it working in<br>
KOffice. Adding editing can be then done on top, building on an<br>
already supported base.<br>
<br>
*) Redo the port of KDE 3's KFormula, removing the fairly minimal<br>
KOffice specific code.<br>
<br>
I estimate the second option to be a solid two week's work for an<br>
experienced KDE developer.<br>
<br>
I think the first option is the more stable option and is ready now,<br>
even if it's not up to the feature level of KDE 3's KFormula.<br>
<font color="#888888"><br>
John<br>
</font></blockquote></div><br>After some chat between John and me, we decided that, since KFormula might want to use this QtMMLWidget code at some point but we want that KDE applications start to take advantage of MathML as soon as possible.<br>
Our idea has been to put it to kdesupport until KFormula has forked it (and it is working) so that we can deprecate the QtSolution's in kdesupport. Then KFormula's widget would go to kdelibs.<br><br>Is that ok?<br>
<br>Thanks,<br>Aleix<br><br>