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 <b...@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 work >>> on Plan porting already now, and also am slightly fearing how much things >>> 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ärz 2015, 20:02:32 schrieb Yue Liu: >>> > 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. >>> >>> 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 has >> 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 not >> 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 > >
_______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
