Just wondering if this is planned/being thought about? Or is Calligra still emphatically part of the KDE family?

(Please don't rant after you read the next part, this is my honest opinion and I realise other people - especially in a KDE forum will have different ones)

I think that getting rid of the KDE dependency in Calligra would enable it to be set up as a serious competitor to LibreOffice. The open source world seriously needs a better-integrated, prettier, leaner, faster office suite and while LibreOffice is a step in the right direction it'll most likely take years for it to shake off its stupid StarOffice heritage and become what the community seems to want. If Calligra could be installed in GNOME, XFCE, etc as well as KDE (without massive dependencies) it could become the same thing in a fraction of the time. Qt integrates well enough with GTK for Calligra to be the office suite of choice for Ubuntu, Elementary, ... the list goes on.

Calligra does still need a work to bring both the interface and the functionality up to scratch, but ... it's a lot less than LibreOffice and a lot cleaner code to start with (thank you Trolltech/Nokia and KDE )

Having said that I haven't looked at the code very much so I can't tell how much Calligra depends on KDE libs, so I'd like to hear the opinion of an actual developer ...

What are your opinions? (other than tldr )

We plan to discuss it in recent sprint( http://community.kde.org/Calligra/Meeti ... t-only_way ), so stay tuned:)

However I don't think the transition will happen before 2.4 is out.

I see. Thanks for the quick reply!

Ok, we discussed it.

There are two ways you can interpret "dependency on KDE":
- Dependency on the KDE desktops, i.e. one of the Plasma workspaces
- Dependency on the kde libraries.

For the first one, there is no such dependency already today. It's true that if you install Calligra on a Gnome desktop, it will drag in much of KDE's workspaces in addition to the pure libraries. That, however, is just a packaging issue. There is nothing that says it has to be this way.

The second one is true: Calligra is much dependent on the kde libraries today. And it will most likely remain that way for a long time. The reason for that is that if you want to build Calligra without kdelibs, you will have to reimplement much of what is in there, i.e. your savings will not be much in the end. For people that think that the kde libraries are too big, you can compile the kdelibs in using the 'mobile' setting which makes it much smaller. Calligra already today builds fine with kdelibs mobile, and it is this way it's used on embedded platforms, e.g. Maemo or MeeGo today.

When it comes to integration with Gnome, there is already today (in kdelibs!) support for gtk styles that makes it more or less totally blend in with the desktop. Try it!

Ah, I didn't know about the mobile option for kdelibs - I'll look into that.
Having had more of a look through the source I can see how much it depends on KParts and so on - I can imagine how annoying stuff like that would be to reimplement!
It doesn't quite blend in even using the gtk theme, but after fixing the fonts and so on it's a hell of a lot better than Libre - kudos to the kde and qt teams for that

If I can find the time I'll try and do some hacking on Calligra - it may be a good way for me to take the plunge in open source

Again, thanks for the info!

You will be very welcome when you find the time!

I just registered here so I could chime in and say I completely agree with the OP that Calligra could offer a great alternative to LibreOffice. And not just on Linux, either, but on Mac and Windows. I'm a Mac user primarily who also dabbles in Linux, and this is definitely one app I would definitely love to see receive solid cross-platform support, in the tradition of other great apps originating on Linux, like Scribus and Inkscape. In fact, I believe that the cross-platform nature of apps can do a great deal to eventually convince people to move to Linux, as it allows people to transition to the open-source apps first before jumping in whole hog. For instance, I think the cross-platform nature of Firefox has done a great deal to open people up to the joys of open-source software and lower the barrier for switching to Linux.

So, my question is: Is it possible to create a well-supported port of Calligra to Mac OS X and Windows, while still depending on the KDE libraries? If the answer is yes, then please continue on the current path. If on the other hand the KDE dependencies are standing in the way of porting to non-Linux platforms, then IMHO these dependencies should be removed/modularized out of the code base.

Thanks for listening and for building this great software!

kmk, KDE has been ported to OSX and Windows so don't worry:)
check koffice2 on Fink: http://pdb.finkproject.org/pdb/browse.p ... y=koffice2

With small modifications you can get calligra in the same way.

philacorns wrote:kmk, KDE has been ported to OSX and Windows so don't worry:)
check koffice2 on Fink: http://pdb.finkproject.org/pdb/browse.p ... y=koffice2

With small modifications you can get calligra in the same way.

Nice to see. Any chance that a binary download of the newest version might be provided in the future? IMHO this is the only way Calligra can get real adoption on the Mac beyond just developers. Especially considering that just to install Fink, you need to first install Xcode, and then wait for everything to be compiled, etc....

Cheers

A binary download for Mac is very unlikely to happen in the near future. There is little man power on the Mac version of KDE, and it is spread across different project (fink, macport). Which in turn decrease the chance of happening for Calligra.

cyrille wrote:A binary download for Mac is very unlikely to happen in the near future. There is little man power on the Mac version of KDE, and it is spread across different project (fink, macport). Which in turn decrease the chance of happening for Calligra.

That's a shame to hear. Still, I assume it should not be that hard to do... All that is needed is to bundle all the necessary libraries into the App folder structure. In fact, I'd be happy to look into it myself and let you know if I get anywhere with it.

What seems to be a more difficult problem to solve, however (if my assumptions are correct), is that the version on Fink is stuck at 2.0.0, and I'm assuming this is a result of the newer version depending on newer KDE libs, which in turn are not able to be ported quickly. So if this interpretation is correct, it actually seems as if the KDE libraries are after all forming an impediment to the newest versions of Calligra being ported to other platforms in a timely manner.

On the other hand, if Calligra were based off of "Pure Qt", the porting effort would be entirely already done for you, by the Qt team, and the port would be a cinch. Actually, I just looked it up and apparently Scribus made just this switch, and in turn it seems to allow them to pull off their ports with ease.

So it's something to consider, methinks. If as you say, the situation for porting KDE to other platforms is resource-starved and will not improve anytime soon, then IMHO a "Pure Qt" effort seems necessary. Assuming Calligra is actually serious about gaining adoption on non-Linux platforms, that is....

Earlier, ingwa mentioned:

Calligra is much dependent on the kde libraries today. And it will most likely remain that way for a long time. The reason for that is that if you want to build Calligra without kdelibs, you will have to reimplement much of what is in there, i.e. your savings will not be much in the end.

I am wondering, what is meant with "you will have to reimplement much of what is in there"? Are we talking utility classes for which equivalents are possibly present in pure Qt? The tie-ins to the KDE libraries like Akonadi? Layout APIs? Are they features that could be turned into add-on modules (e.g. Akonadi)? Have you done a realistic evaluation of actual effort needed to move off of the KDE libraries (I assume you have), and if so, what does it look like?

Please don't interpret this antagonistically, I am really just curious.

Cheers, and thanks for the dialog!

kmk wrote:On the other hand, if Calligra were based off of "Pure Qt", the porting effort would be entirely already done for you, by the Qt team, and the port would be a cinch. Actually, I just looked it up and apparently Scribus made just this switch, and in turn it seems to allow them to pull off their ports with ease.

The problem is that KDE adds a lot of functionality on top of Qt, functionality that Calligra needs. This includes platform-dependent features not found in Qt. So if Calligra switched to Qt, it would not mean the porting is already done, it would mean that these features would need to be re-implemented from scratch for Mac, Windows and Linux, while right now at the very least they are done for Linux, partially done for Windows, and a little done for Mac.

kmk wrote:I am wondering, what is meant with "you will have to reimplement much of what is in there"? Are we talking utility classes for which equivalents are possibly present in pure Qt? The tie-ins to the KDE libraries like Akonadi? Layout APIs? Are they features that could be turned into add-on modules (e.g. Akonadi)? Have you done a realistic evaluation of actual effort needed to move off of the KDE libraries (I assume you have), and if so, what does it look like?

For one thing, KDE's localization system is far superior to Qt's. KDE's file picker, file handling, and mimetype handling is much better (and highly platform-dependent). Qt has nothing remotely similar to KIO slaves which can be used for handling files seamlessly over network drives (highly platform-dependent). Qt does not have knewstuff, which lets them download plugins in a standard manner (not platform-dependent, but hard to implement). KDE provides an easy-to-use configuration system that Qt lacks. KDE provides a multithreading interface that Calligra uses (which is highly platform-dependent). KDE provides access to the system color scheme (highly platform-dependent). KDE provides kparts for embedding applications in others, which would be a mess to re-implement from scratch.

Thanks for that explanation, it was very enlightening!

I'm going to still press ahead and come up with arguments why I think Calligra's architecture could be changed, though. But keeping your comments in mind ...

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.

TheBlackCat wrote:KDE's file picker, file handling, and mimetype handling is much better (and highly platform-dependent). Qt has nothing remotely similar to KIO slaves which can be used for handling files seamlessly over network drives (highly platform-dependent). Qt does not have knewstuff, which lets them download plugins in a standard manner (not platform-dependent, but hard to implement).

It seems like these features are useful, but not deal-breakers if they're not available on other platforms. Can't these be used modularly, i.e. use the KDE file picker etc. in a KDE environment, and for all other environments build it with the standard Qt facilities? 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. 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?

TheBlackCat wrote:KDE provides access to the system color scheme (highly platform-dependent).

I don't think you'd have to worry about this with Qt on Mac and Windows, it just works automatically AFAIK. Perhaps it could be made optional for running in a KDE environment.

TheBlackCat wrote:KDE provides an easy-to-use configuration system that Qt lacks. KDE provides a multithreading interface that Calligra uses (which is highly platform-dependent).... KDE provides kparts for embedding applications in others, which would be a mess to re-implement from scratch.

Well, on these points you seem to have hit on very serious issues that pervade the entirety of these apps. Still, I'm thinking the settings could be abstracted to use an alternative backend when it's not running on KDE, and I guess the multi-threading could be replaced with Qt's facilities, although it would probably require a lot of refactoring. As for the KParts, well... any chance this could be ported standalone, separate from the rest of the KDElibs?

You might be asking why I keep pushing these points? Ultimately it's because I think more competition in office suites on more platforms is a good thing, especially when it comes to ODF support and unique user interface ideas. And I really like the apps in Calligra and would like to be able to recommend them to my non-Linux-using friends. Also, I get the sense that some Calligra developers are thinking in terms of portability, too, at least at the core level, as the planning for KoAbstraction library project seems to demonstrate (http://community.kde.org/Calligra/Libs/KoAbstraction):

Strategically, it's a showcase of #1 KOffice's advantage: portability and flexibility of the core, unmatched independence of the GUI. So far in my opinion we have not encouraged 3rd-parties to use this strength very consequently. It's much easier to expose this strength than first competing in area of features with mature competitors. --jstaniek
...
Standalone KOffice viewer widget (can be used in Designer!) Status: planning
...
Proof of concept even higher-level Qt-only API abstracting KOffice core

If the "core" is truly already as portable as that page makes it sound, then it seems that a good bit of work is already done.

Of course it's possible to do everything without kdelibs, but then you are effectively writing your own clone of kdelibs. Big companies are doing exactly that.

Beside that a Qt only doesn't automatically ensure that Calligra runs on windows. The problem is more that we are missing windows developers in general. The windows version continously needs work to keep up with compilers etc. Is there any reason why the new libraries should not have the same problems as kdelibs has now?

Well the core engine depends on kdelibs, but if you consider that there is a kdelibs mobile profile that already offers a much smaller footprint it's not really worth to put a lot of effort into it. Don't underestimate the effort it takes to maintain these cloned libraries.

slangkamp wrote:Is there any reason why the new libraries should not have the same problems as kdelibs has now?

That's a very good question, which of course I don't know the answer to. But based on the evidence of projects like Scriptus, which seem to have an easier time supporting cross-platform releases, I would suppose the answer is "yes". The concrete reasons are unclear to me, but I can only guess that it has to do with kdelibs being tightly tied to other parts of the GNU/Linux toolchain that lack support on other platforms.

Also note that for the most part I suggested decoupling kdelibs, not replacing them, so that certain features would simply be unavailable on other platforms. In other cases, specifically in regards to threading and internationalization, I argued for using Qt's own capabilities. Even if this were to require the creation of utility libraries of sorts, I doubt they would need to be updated much once created. The worst you can say about them is that they'd have great potential for introducing bugs and delaying new features.