Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Calligra 2.5 released
Posted Aug 13, 2012 15:32 UTC (Mon) by boudewijn (subscriber, #14185)
Posted Aug 13, 2012 15:44 UTC (Mon) by hummassa (subscriber, #307)
> I thought Calligra was kdelibs-based (and non-linux kde ports are off the map those days...)
> Yes, Calligra uses kdelibs. But I'm not sure I get your point here.
I had not been able lately to find a good, reasonably stable kdelibs-based-software (amarok, digikam, k3b?, the whole of kde if it's not asking too much) port to Windows and OSX. Even Calligra only has ATM AFAICT a "considered very unstable" MSI installer and no OSX installer/port that I can find.
So, even if it has the potential to be "a cleaner approach to a cross-platform office suite", it's not living to that potential.
OTOH, LibreOffice3.6 is working AOK -- and consistently -- on the three platforms I use today (Kubuntu precise, W7, Mountain Lion).
Posted Aug 13, 2012 17:03 UTC (Mon) by boudewijn (subscriber, #14185)
The reason it's experimental is that nobody in their right minds wants to develop on Windows. There is about a dozen dedicated users who test of u and report Windows-specific bugs. We've got a weird bug in the msword filter, somewhere in the wv2 library. OOo-generated .doc files load, MS-Word generated .doc files don't. But finding someone who wants to put spare time into investigating an issue like that is nearly impossible.
Building on Windows takes ages and debugging is horrible. We've got more of those bugs, sometimes causes by MSVC, sometimes by the Windows platform. I've got a bug in Krita that only happens if Krita is compiled with msvc. If I compile with Intel's icl compiler or with mingw, no bug...
People might jump up right now and claim that that's because I only have a couple of years of Windows experience compared to a decade of Linux, but if development on Windows were as easy and enjoyable as on Linux, there'd be developers joining the project. There aren't...
On the other hand, I got funding to make a touch-based version of Krita for Windows 8 now, and that really should help move at least that part of Calligra beyond the purely experimental stage.
As for OSX, well, nobody in the project has a Mac. When I had one, I regularly compiled for OSX, but that was 2007. Back then, yes, we had a problem with dbus on OSX, so that was clearly a platform issue caused by using the KDE libraries and frameworks. It's also five years ago.
Posted Aug 13, 2012 18:01 UTC (Mon) by drag (subscriber, #31333)
Good luck on the Windows 8 port.
Posted Aug 13, 2012 18:28 UTC (Mon) by boudewijn (subscriber, #14185)
It's the same problem apps like gimp have, of course. Gimp has many, many more users on Windows than on Linux and not a single Windows developer.
Posted Aug 13, 2012 18:48 UTC (Mon) by drag (subscriber, #31333)
I wonder if it is because the Linux-style programming approach is a big turn off to Windows developers. Unfamiliar APIs and tools and such. So they go and work on other more windows-focused users.
Does QT/KDE development platform integrate naturally into Visual Studio and such things?
Posted Aug 13, 2012 19:01 UTC (Mon) by boudewijn (subscriber, #14185)
However, I've never ever had a Windows developer come up to me and ask to help him get started, so I think that the basic interest just isn't there. I have a suspicion that the idea that you can, like develop software on your own, is not very current on Windows.
Posted Aug 13, 2012 20:49 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
However, setting up developer environment for a project with lots of libraries can be tricky. It usually involves manually installing and compiling libraries and then making sure that the target project correctly picks them up.
Posted Aug 13, 2012 22:57 UTC (Mon) by mathstuf (subscriber, #69389)
- limited target name length (260+ is not unheard of for generated targets);
- it's not Vim (yeah, personal choice, but Vim integration stuff was broken with 10);
- have to close VS every time I change a CMake file and reconfigure the vcxproj;
- horrendous error output (first thing I do on VS is turn on the Error/Warning window, then line numbers);
- refusal to debug Release applications (not even a backtrace!); and
- can't save command line arguments for "Run target" (or whatever the F5 action is) for later use (I have two files I want to test with, it only remembers one set of arguments).
Honestly, cmake --build is easier lots of the time. This list is by no means exhaustive, just what comes to mind.
Posted Aug 13, 2012 23:07 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
>- refusal to debug Release applications (not even a backtrace!); and
You certainly can do it, if you build debug information (it's called RelWithDebInfo in CMake). MSVC debugger even has very nice infrastructure for interfacing with symbol servers which is useful for post-mortem debugging.
>- can't save command line arguments for "Run target" (or whatever the F5 action is) for later use (I have two files I want to test with, it only remembers one set of arguments).
I think there's a plugin that does this.
Posted Aug 13, 2012 23:28 UTC (Mon) by mathstuf (subscriber, #69389)
> You certainly can do it, if you build debug information (it's called RelWithDebInfo in CMake).
IIRC, the bug wasn't reproducible other than in Release.
> I think there's a plugin that does this.
That's a relief. Just to find it and hope it works with Express… Any hints for the name?
Posted Aug 13, 2012 23:32 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
>> You certainly can do it, if you build debug information (it's called RelWithDebInfo in CMake).
>IIRC, the bug wasn't reproducible other than in Release.
RelWithDebInfo just generates debug information during a release build. It doesn't affect code generation at all.
Posted Aug 14, 2012 2:54 UTC (Tue) by HenrikH (guest, #31152)
Especially the madness of each new version of VC having a pair of new libc:s is what turns me off the most. Whoever made that decision at Microsoft should be thrown out.
Posted Aug 14, 2012 7:47 UTC (Tue) by boudewijn (subscriber, #14185)
Posted Aug 14, 2012 16:37 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
Posted Aug 14, 2012 17:17 UTC (Tue) by 2NZb42fVtpOEyCBv (subscriber, #86247)
True - for one project we rewrote our entire build system so that it passed all source files in a dir to the compiler at once, rather than the traditional (e.g. make implicit rules) approach of invoking the compiler once per source file. Transformed Windows build times. I think that it's to do with process creation being absurdly slow on Windows, but didn't look into it.
(That change then broke sparse, because there was a bug that cropped up when you pointed it at multiple source files - IIRC to do with scoping of static variables. Our patch for that got merged moons ago though.)
That makes our Windows builds tolerable. Still, the notion of having your project compilation mechanism dictated to you by the sloth of process creation on an "operating system" is laughable.
Posted Aug 14, 2012 17:29 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
Also, file system on Windows is excruciatingly slow. NTFS on Windows can literally be orders of magnitude slower than ext4 on Linux.
Posted Aug 14, 2012 17:36 UTC (Tue) by boudewijn (subscriber, #14185)
Posted Aug 14, 2012 8:22 UTC (Tue) by boudewijn (subscriber, #14185)
You'll end up with a tree that looks a bit like a standard unix tree: rootdir/bin, rootdir/lib and so on. From there to packaging the software for an installer is a matter of simply copying the right files to your installer.
If you use kde libraries, then the system is smart enough to make it possible to co-install two kde-based applications and run them at the same time. But even if I would work on a pure-Qt application that needed libraries like lcms, I would still use this system to get all those dependencies ready and in place.
Posted Aug 13, 2012 21:11 UTC (Mon) by dashesy (subscriber, #74652)
Actually Qt works really great with visual studio, and if you install the Qt Visual Studio Add-in, you get some extra debugging extensions too. If you can debug inside the pimpl structure fine, there is no need for the add-in really. I have not found a single showstopper bug in Qt, in the last couple of years. Using Qt properly there should be hardly any *other* API one may need to get accustomed with.
My guess is that Windows development for office applications is less exciting.
Posted Aug 14, 2012 3:56 UTC (Tue) by cmccabe (guest, #60281)
Ultimately developers do what's fun for them. And there's nothing wrong with that.
If you want to get involved with a Windows port of these applications, I'm sure that they'd be happy to accept your assistance!
I'm curious how these projects are going to handle the fact that the latest version of Visual Studio is not available for no cost.
Posted Aug 14, 2012 8:11 UTC (Tue) by boudewijn (subscriber, #14185)
Posted Aug 14, 2012 13:27 UTC (Tue) by drag (subscriber, #31333)
Cross platform stuff really isn't that interesting to me. I'd rather program games in Blender (which will take care of popular platform compatiblity for me, hopefully)
Posted Aug 13, 2012 15:47 UTC (Mon) by butlerm (subscriber, #13312)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds