<p dir="ltr"><br>
On May 22, 2014 1:57 AM, "Boudewijn Rempt" <<a href="mailto:boud@valdyas.org">boud@valdyas.org</a>> wrote:<br>
><br>
> On Tuesday 20 May 2014 May 22:12:07 Jaroslaw Staniek wrote:<br>
><br>
> > I wouldn't like to see any app and feature put in a drawer, so how<br>
> > about a call for volunteers as early as possible?<br>
><br>
> I'm of course fine with that. I just don't expect any response whatsoever. We've already got the Unmaintained!!! splashes for Karbon and Plan, with zero response. Maybe because they are disabled for the release, which means nobody but people who build from scratch see them... But I simply doubt that people will volunteer following a call for action, especially when there are so few people to welcome them.<br>

><br>
I'm interested in porting Karbon.<br>
> > As a backup plan perhaps some "who uses, maintains" rule can be<br>
> > applied by releasing early, simple version of Qt-only Calligra Engine<br>
> > so new people can try it, maybe use it, join us, maintain it and<br>
> > develop. So the target users would be software engineers. We're<br>
> > stronger in this area or to put it differently: our competition<br>
> > (especially FOSS one) is weaker there. That gives natural opportunity.<br>
><br>
> I'm not sure how this helps with unmaintained applications or with the problem that the shared engine isn't a good fit for both artistic applications and for office applications. I would like to sort of have our base libraries be comparable to Tier1 KF5 frameworks after the Qt5 port, though.<br>

><br>
><br>
> > Regarding Calligra 3.0 marketing. It's very important to me and we<br>
> > won't have another try. I'd like to propose using a popular Web 2.0<br>
> > meaning of Beta for a longer time, asking distros to package our<br>
> > releases earely and often. Display a beta sign on all prominent<br>
> > places: 3.0 Beta, then _no_ 3.0 stable but 3.1 Beta if needed, ...<br>
> > then when we're ready, 3.x stable.<br>
> > Alternative that I don't like would be a series of 3.0 Beta 1, 3.0<br>
> > Beta 2,  .... - a bit complex for users and suggests stagnation. I<br>
> > learned that in the time of 5 Betas of Kexi 0.1<br>
> > (<a href="http://www.kexi-project.org/wiki/wikiview/index.php@ReleaseSchedule0.x.html">http://www.kexi-project.org/wiki/wikiview/index.php@ReleaseSchedule0.x.html</a>)<br>
> > 10 years ago.<br>
> > I know the new approach is nonstandard but indicates the special<br>
> > stage. After we would be back to the usual rules.<br>
><br>
> But is that really needed? The port to Qt5 isn't really difficult, and if we're disciplined and do _no_ refactoring at all during the port, we should be able to release with confidence. I definitely do not want to go without our regular two releases a year, having a release is too important to keep users involved and happy. I also don't want to play number games: 2.9 is the last Qt4-based release, 3.0 is the first Qt5-based release.<br>

><br>
I've made a qt backend to a gtkmathview fork, it depends on qt5 so I haven't make any formula plugin based on that yet. It's very likely kformula will be replaced by it after port to qt5, in this case do we still need to port kformula to qt5 if the porting is complicated? (I hope it's straightforward)<br>

> ><br>
> > From Kexi side, there are the following stages during the transition:<br>
> > - finalization of porting from Qt3Support to Qt 4 - ongoing last<br>
> > larger part is being ported - 5 calendar weeks for me<br>
> > - porting Predicate lib (aka KexiDB 2) from Qt4 to Qt5 - 3 calendar weeks for me<br>
> > - then, these steps are needed in parallel:<br>
> > -- porting Kexi (and a bit of Plan, Words?) from KexiDB to Predicate<br>
> > -- 2 months for me (?)<br>
><br>
> That's something you either need to do _now_, for 2.9, or after the Qt5 port, for 3.1. Don't try to do anything but a straight Qt5 port during the Qt5 port, that way lies the KOffice 2 madness!<br>
><br>
> > -- porting Kexi to Qt5 to make it mostly work -- 2 months for me (?)<br>
> > - then this is Kexi 3.0 Beta, and we can start taking benefits from<br>
> > access to KF5 (less deps so attractive for 3rdparty computing<br>
> > environments) and new candies of Qt5 (solid scripting,<br>
> > distro/architecture-independent extensions, forming  community around<br>
> > such things)<br>
> ><br>
> > Regarding possibility of Krita forking some shared UI infra, I would<br>
> > welcome Krita continuing of taking usability and convenience/appeal<br>
> > for the user as a starting point. Sharing UIs between business/office<br>
> > and creative apps shouldn't have higher priority IMHO. And this is not<br>
> > a not-invented-here syndrome in Krita (or Kexi where there were<br>
> > similar challenges due to specialization of the app). There's still so<br>
> > much to be shared, our integration and frameworks won't go  away.<br>
> ><br>
> ><br>
><br>
> --<br>
> Boudewijn Rempt<br>
> <a href="http://www.valdyas.org">http://www.valdyas.org</a>, <a href="http://www.krita.org">http://www.krita.org</a>, <a href="http://www.boudewijnrempt.nl">http://www.boudewijnrempt.nl</a><br>
><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">https://mail.kde.org/mailman/listinfo/calligra-devel</a><br>
</p>