Am Donnerstag, 9. April 2015, 11:20:37 schrieb Yue Liu:
> I agree we should port first then add new things, I'll drop ownership of
> formulashape for now and continue working on libmathview.
Ok, good we agree :) Will pick that shape tonight and see to make it build in
the frameworks branch (unles
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 t
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 b
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 re
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, l
On Mon, 23 Mar 2015, René J.V. Bertin wrote:
On Monday March 23 2015 11:01:11 Boudewijn Rempt wrote:
doesn't support sharing the same area across different libraries, which is
something we do a lot in Calligra. We have three options: remove all the
areas (as I did in koplugin), make areas per
On Monday March 23 2015 11:01:11 Boudewijn Rempt wrote:
>>> doesn't support sharing the same area across different libraries, which is
>>> something we do a lot in Calligra. We have three options: remove all the
>>> areas (as I did in koplugin), make areas per library or create a new
>>
On Sat, 21 Mar 2015, René J.V. Bertin wrote:
On Saturday March 21 2015 11:03:21 Boudewijn Rempt wrote:
doesn't support sharing the same area across different libraries, which is
something we do a lot in Calligra. We have three options: remove all the
areas (as I did in koplugin), make areas p
On Sat, 21 Mar 2015, Friedrich W. H. Kossebau wrote:
Am Samstag, 21. März 2015, 11:01:27 schrieb Boudewijn Rempt:
After a lot of frustration, koplugin now builds and links. That means that
we can start porting the rest of the libraries.
Boud, thanks for wading through all that frustration. Yo
I want to add something to the "Stuff that can be removed" part of the
porting plan.
plugins/formulashape/ - I will write a new formula plugin based on libmathview.
flow/ - I want to re-write calligraflow based on Karbon libraries.
Yue
2015-03-21 13:56 GMT-07:00 Friedrich W. H. Kossebau :
> Am S
Am Samstag, 21. März 2015, 11:01:27 schrieb Boudewijn Rempt:
> After a lot of frustration, koplugin now builds and links. That means that
> we can start porting the rest of the libraries.
Boud, thanks for wading through all that frustration. You know we all are
thankful for you having picked up t
On Saturday March 21 2015 11:03:21 Boudewijn Rempt wrote:
>doesn't support sharing the same area across different libraries, which is
>something we do a lot in Calligra. We have three options: remove all the
>areas (as I did in koplugin), make areas per library or create a new
Oh, another note:
the kde-dev-scripts allow us to port kDebug(AREA) to qcDebug() _but_ it
doesn't support sharing the same area across different libraries, which is
something we do a lot in Calligra. We have three options: remove all the
areas (as I did in koplugin), make areas per library or
13 matches
Mail list logo