kmk wrote:

TheBlackCat wrote:KDE's localization system is far superior to Qt's.

OK, I believe you, but somehow Qt's is still usable enough, it seems, for lots of major apps from big companies to manage.

Just because it is sufficent in some situations doesn't mean it is sufficient in others.. For instance Qt localization system lacks the ability to localize dates, which is absolutely essential for an office suite. There are other limitations as well, but the short version is that Qt localization system is missing features that I think would be essential for a project like Calligra.

kmk wrote:Likewise, if I can't access certain network files quite as easily, it probably won't stop the majority of average people from using the product.

In a corporate environment, it most certainly will.

kmk wrote:And in the (I'm assuming rare) case that an external plug-in needs to be installed, the ability to manually side-load it could be offered, no?

Perhaps, but it would still need to be coded from scratch, which is far from trivial.

kmk wrote:Still, I'm thinking the settings could be abstracted to use an alternative backend when it's not running on KDE,

This would have to be coded entirely from scratch, which is hardly trivial to do right. The effort going into re-implementing this could just as easily go into fixing KDE on windows or mac.

kmk wrote:and I guess the multi-threading could be replaced with Qt's facilities, although it would probably require a lot of refactoring.

Are you sure Qt's threading system is even sufficient for Calligra's needs? You just seem to be assuming it is.

kmk wrote:As for the KParts, well... any chance this could be ported standalone, separate from the rest of the KDElibs?

Not easily, it depends on a lot of other parts of KDE. It would probably be easier to just get KDE working on windows than to do such a massive change.

Which comes down to the main issue I have with your suggestion: all the stuff you are proposing would require a massive rewrite of Calligra and probably core parts of KDE, severely reducing Calligra's capabilities in the process. For all that effort, with feature regression, wouldn't it be easier to use that effort to get KDE working on windows and mac?

Your approach seems to be inefficient and I think it will ultimately hurt both KDE and Calligra. When faced with "KDE is preventing Calligra from working on that platform", your solution is "lets scrap much of Calligra and start over from scratch", while I think the better solution would be "lets get KDE working on those platforms". They both accomplish the same goal, but the latter approach moves us forward, while the former stalls us and probably will prevent Calligra from ever reaching its full potential.

The difference between Scribus and Calligra when it comes to MacOSX is that Scribus has actually people developing and maintaining the Mac version. Calligra has no one. Would it be more difficult ? I don't know, in fact, no one knows. Until someone start caring and doing the work. The Mac version would be easier than Windows, since it is a Unix system and a it uses the same compilers. Inge mentioned the kdelibs mobile profile that could be used to make it even easier.

However, whether Calligra is Qt-only, or depends on kdelibs, does not matter as long as there is no one who step in to do the work, the work is not done, it is as simple as that.

OK, so I guess my suggestions aren't less effort than getting kdelibs (at least the mobile version) running properly on Mac OS X and/or Windows. At least that's the message I'm hearing. Fair enough.

When I have free time I'll take a shot at hacking at getting a newer version to compile on Mac, but unfortunately I'm not too familiar with solving gcc compiler issues so I guess it will have to be a painful learning experience....

The KDE core developers seem to plan on modularizing the KDE libraries anyways (see e.g. [1]), in order to make them more accessible to pure-Qt application developers.

So in the future, the question of whether or not to "depend on KDE" might not even be relevant anymore.
Rather, the question may become, which of the many self-contained, small, Qt-extending libraries out of the KDE framework to use.

And Calligra would of course only need to depend on those that provide functionality which the Calligra devs would otherwise have to implement themselves...

Gnome-centric packagers could then maybe even offer self-contained Calligra packages which already include those KDE framework libraries actually used by Calligra, without pulling in any additional KDE stuff.

@developers: Please correct me if I'm wrong...

----------------
[1] http://lists.kde.org/?l=kde-devel&m=130738094416171&w=2

smls wrote:Gnome-centric packagers could then maybe even offer self-contained Calligra packages which already include those KDE framework libraries actually used by Calligra, without pulling in any additional KDE stuff.

That probably wouldn't even be necessary. With modern package managers, the parts of KDE could be divided into separate packages, and the dependency handler in the package manager could just pull in those packages that are needed for a given application. Of course this would be more work for packagers than the current system, but a lot less work then bundling the necessary libraries with every single application.

Old topic but still valid. So a small update after the Calligra Sprint 2014. Calligra largely moves to Qt 5 and thanks to modularization of KDE Frameworks 5 (KDE modules are just like Qt modules in many aspects), the apps will be largely Qt-only. Light dependencies will be the reality.

Already for the forthcoming 2.9, Calligra apps are independent of kbuildsycoca when it comes to enumerating plugins (despite the fact that 2.9 is still based on KDE 4 libs). Such steps are in our case inspired by porting to Windows and Mac, and often to mobile platforms where KDE technologies feel a bit alien or redundant.

The most visible changes you see are in Krita and Kexi, the most active Calligra apps at the moment.

Hello and thank you for the last post !

I am interested into calligra ported on qt5, I am currently using the 2.8.5 version.
You said that calligra was largely ported to QT5, but is that the git version ? Another from the 2.8.5 I assume, since the compilation guide for this version only refers to KDE4 and qt4 ? I was waiting for some report on that point from the last spring but can't find one ...
Or am I totally missing info / knowledge ?

Thank you for taking the time to answer me !

Hi sebius, thanks for the interest.
Calligra *moves* to Qt 5 these months. Any value-adding components of KDE Framework 5 shall be used. In particular I see a lot of value in KIO for Kexi, just thinking about it as an easy to install option.

The recipes are for Qt 4/KDElibs4, yes. Git master branch is still 2.9, with creation of calligra/2.9 branch (quite soon) you'd see the git master branch becoming 3.0 branch, i.e. Qt 5/KF5. Separate branches exist that contain the porting efforts.

I encourage to support the effort, e.g. by testing, providing feedback (link). The port is a large costly effort, in this time usually no new features come, this is also a big cost that we're paying.