[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Rewriting Flow & formulashape for 3.0? (Re: Qt5 Port Status)
From: Yue Liu <yue.liu () mail ! com>
Date: 2015-04-09 18:20:37
Message-ID: CAJ341XQobDqN=L+aQWxpBe+7vH9tQY4QGHCCPygHSoOP_E4gpA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I agree we should port first then add new things, I'll drop ownership of
formulashape for now and continue working on libmathview.
For Flow it's just a kopageapp wrapper and a docker plugin that works in
all calligra apps, so the "re-write" actually means to move the plugin code
from Flow folder to Karbon folder, then fix all paths in cmake files,
#include lines, and identity strings in code. I can finish that before
releasing 3.0.
Cheers,
Yue
2015-04-08 14:16 GMT-07:00 Boudewijn Rempt <boud@valdyas.org>:
> As for me, I would say:
>
> * let's not already remove code until we're releasing 3.0. Just keep it
> UNPORTED -- otherwise, we'll get merge conflicts because of translations,
> if nothing else.
>
> * As for whether we should keep the formula shape or not, I think it's
> simple: if it hasn't been ported by 3.0 release time, we won't keep it.
> Otherwise, we will: and then we can replace it if there's an alternative.
>
>
> On Wed, 8 Apr 2015, Inge Wallin wrote:
>
> On Wednesday, April 08, 2015 22:07:46 Friedrich W. H. Kossebau wrote:
>>
>>> Hi Yue,
>>>
>>> good to see that you among other things have already turned Karbon back
>>> to
>>> life in the Qt5/KF5 spheres :) Rock on!
>>>
>>> Now, the plan for Calligra 3.0 was to focus on porting all code to Qt5
>>> and
>>> KF5.
>>>
>>> No refactoring or rewriting should be done ideally, as that will only
>>> complicate things, like history (including Calligra's) teaches.
>>> One step at a time, they say surely in many languages.
>>>
>>> With KoReport, KoProperty, CalligraDB we are breaking this initial idea
>>> that
>>> we informally agreed on, makes me not that happy, would have like to wo=
rk
>>> on Plan porting already now, and also am slightly fearing how much thin=
gs
>>> changed with those libs. But at least it seems things are getting ready
>>> almost in time now... not yet git-cloned the repos, but soon will do.
>>>
>>> Seems you, Yue, want to do more for 3.0 as well, let me comment on that
>>> please:
>>>
>>> Am Samstag, 21. M=C3=A4rz 2015, 20:02:32 schrieb Yue Liu:
>>> > I want to add something to the "Stuff that can be removed" part of th=
e
>>> > porting plan.
>>> > > plugins/formulashape/ - I will write a new formula plugin based on
>>> > libmathview.
>>>
>>> How broken is the current shape?
>>>
>>
>> I would really not like to remove the formula shape until there actually
>> *is* a replacement, not just a promise to create one. I don't care how
>> much the current shape sucks (well, actually I do, but work with me here=
).
>> But even if interaction sucks, visualization sucks and other things suck=
,
>> it still provides a roundtrip storage for formula objects.
>>
>> And if *that* fails, it should be fixed immediately and not removed. I
>> worked on the formulashape myself not too long ago and I know that it ha=
s
>> worked before.
>>
>> The same goes for the Flow application to some extent, but since the
>> formula shape is shared between all apps it is very important that it no=
t
>> be destroyed now.
>>
>> _______________________________________________
>> calligra-devel mailing list
>> calligra-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
> _______________________________________________
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
[Attachment #5 (text/html)]
<div dir="ltr"><div><div><div>I agree we should port first then add new things, \
I'll drop ownership of formulashape for now and continue working on \
libmathview.<br><br></div>For Flow it's just a kopageapp wrapper and a docker \
plugin that works in all calligra apps, so the "re-write" actually means to \
move the plugin code from Flow folder to Karbon folder, then fix all paths in cmake \
files, #include lines, and identity strings in code. I can finish that before \
releasing 3.0.<br><br></div>Cheers,<br></div>Yue<br></div><div \
class="gmail_extra"><br><div class="gmail_quote">2015-04-08 14:16 GMT-07:00 Boudewijn \
Rempt <span dir="ltr"><<a href="mailto:boud@valdyas.org" \
target="_blank">boud@valdyas.org</a>></span>:<br><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As for me, I \
would say:<br> <br>
* let's not already remove code until we're releasing 3.0. Just keep it \
UNPORTED -- otherwise, we'll get merge conflicts because of translations, if \
nothing else.<br> <br>
* As for whether we should keep the formula shape or not, I think it's simple: if \
it hasn't been ported by 3.0 release time, we won't keep it. Otherwise, we \
will: and then we can replace it if there's an alternative.<div \
class="HOEnZb"><div class="h5"><br> <br>
On Wed, 8 Apr 2015, Inge Wallin wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> On Wednesday, April 08, 2015 22:07:46 Friedrich W. H. \
Kossebau wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi Yue,<br>
<br>
good to see that you among other things have already turned Karbon back to<br>
life in the Qt5/KF5 spheres :) Rock on!<br>
<br>
Now, the plan for Calligra 3.0 was to focus on porting all code to Qt5 and<br>
KF5.<br>
<br>
No refactoring or rewriting should be done ideally, as that will only<br>
complicate things, like history (including Calligra's) teaches.<br>
One step at a time, they say surely in many languages.<br>
<br>
With KoReport, KoProperty, CalligraDB we are breaking this initial idea that<br>
we informally agreed on, makes me not that happy, would have like to work<br>
on Plan porting already now, and also am slightly fearing how much things<br>
changed with those libs. But at least it seems things are getting ready<br>
almost in time now... not yet git-cloned the repos, but soon will do.<br>
<br>
Seems you, Yue, want to do more for 3.0 as well, let me comment on that<br>
please:<br>
<br>
Am Samstag, 21. März 2015, 20:02:32 schrieb Yue Liu:<br>
> I want to add something to the "Stuff that can be removed" part of \
the<br> > porting plan.<br>
> > plugins/formulashape/ - I will write a new formula plugin based on<br>
> libmathview.<br>
<br>
How broken is the current shape? <br>
</blockquote>
<br>
I would really not like to remove the formula shape until there actually *is* a \
replacement, not just a promise to create one. I don't care how much the \
current shape sucks (well, actually I do, but work with me here). But even if \
interaction sucks, visualization sucks and other things suck, it still provides a \
roundtrip storage for formula objects.<br> <br>
And if *that* fails, it should be fixed immediately and not removed. I worked on the \
formulashape myself not too long ago and I know that it has worked before.<br> <br>
The same goes for the Flow application to some extent, but since the formula shape is \
shared between all apps it is very important that it not be destroyed now.<br> <br>
______________________________<u></u>_________________<br>
calligra-devel mailing list<br>
<a href="mailto:calligra-devel@kde.org" \
target="_blank">calligra-devel@kde.org</a><br> <a \
href="https://mail.kde.org/mailman/listinfo/calligra-devel" \
target="_blank">https://mail.kde.org/mailman/<u></u>listinfo/calligra-devel</a></blockquote>
</div></div><br>_______________________________________________<br>
calligra-devel mailing list<br>
<a href="mailto:calligra-devel@kde.org">calligra-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/calligra-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/calligra-devel</a><br> \
<br></blockquote></div><br></div>
[Attachment #6 (text/plain)]
_______________________________________________
Krita mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic