Where were we? Oh yes:
“So… long and short of it is: I want to do something, but the program doesn’t do it. I’m stuffed aren’t I?”
The thing about open source is that there’s usually a later version than the stable one. There may be more than one. Often there’s “stable”, “testing” and “CVS” (or “SVN”) – where the later isn’t a packaged version but access to the latest source in the source code repository system. So often on help fora etc you’ll see developers say things like “Oh yes that’s a bug. It’s fixed in the CVS version.” If you’re a hapless user without the ability to compile the latest CVS then it’s a bit of a show-stopper unless you can find someone to compile it for you.
Now I’m not quite in that boat. I know enough C to get by and enough C++ to be able to read it. I know how to compile. So I thought I’d have a go at the latest SVN version, hoping that the changes I needed were in there. Unfortunately the compilation instructions are rather terse and include this sentence:
“Trunk SVN admin directory needs QT4, so make sure you’ll downgrade kde 3.5 admin directory”
What follows is svn syntax to check out the relevant code from the repository. Now I must admit to misreading this. If the svn command had worked on my system – it didn’t I suspect SVN uses a blocked port on my work’s network – then I’d have probably not have made the mistake I did. However I read the above as meaning “The version of kmobiletools from SVN needs QT4”. I was nervous about this but I had a google around and found out that it was possible to have 2 non-conflicting versions on QT on a machine. So I downloaded the source to the latest QT 4.x and built it. I installed it in a directory where it wasn’t going to get picked up accidentally by my existing KDE stuff and tried to compile kmobiletools.
I kept getting an error from configure about QT:
configure: error: Qt (>= Qt 3.3 and < 4.0) (library qt-mt) not found. Please check your installation!
For more details about this problem, look at the end of config.log.
Make sure that you have compiled Qt with thread support!
This confused me because I was sure I needed QT4. I mustn’t have installed it with thread support. So I checked the compilation of QT – but I couldn’t find an option to enable/disable threading (possibly this isn’t possible now. Possibly it’s always threaded now).
More curiously configure worked ok when I didn’t try to point it at the QT4 files. But then the compile failed. Looking back the penny really should have dropped at this point but instead I persisted. I tried different combinations of configure options. I tried building on a Suse 10.1 vmware VM. It just didn’t work.
I should probably point out that during this process I’d “given up” a couple of times. But I kept coming back to it.
Anyway. The compile error, if I configured using the default QT3.3 were:
smspart.cpp:155: error: `setDisabled' undeclared (first use this function)
I figured I just wasn’t picking up the right version of some header file. It doesn’t help that we’re not only talking about QT but KDE libraries and header files too. As I think I said, Suse 9.3 had KDE 3.4. Now to cut to the chase, and avoid an installment 3, I’ll tell you what’s wrong here. Line 155 of smspart.cpp contains reference to copy->setDisabled where copy is defined as a KAction. I finally googled for this and found that this attribute of KAction only exists in KDE 3.5 and upward. So it wasn’t my version of QT that was wrong it was my version of KDE. So
“Trunk SVN admin directory needs QT4, so make sure you’ll downgrade kde 3.5 admin directory”
meant more or less the opposite to what I’d read it to mean. It means something like “Since KDE admin in KDE 3.5 needs QT4 and we don’t we need to downgrade that particular directory to one that’ll use QT3”.
So basically, I now know – I think – how to build kmobiletools. I’d need to
– download and build enough of KDE 3.5 to allow the building of kmobiletools.
Or in other words – the “k” is not there for nothing.
Now back in the day, I compiled the whole of KDE from scratch. (KDE 1.something) However I didn’t really fancy doing that. I fancied even less trying to pick apart which bits of KDE I need. Not to mention that I already have KDE installed. Was I going to uninstall it? Try to have an alternate KDE 3.5 alongside my 3.4 – that seems trickier than having QT4 alongside QT3. I realised that if I was going to do anything it would be:
1. uninstall kde 3.4
2. build and install kde 3.5 – just the base and libraries at first
3. attempt to build kmobiletools from SVN
4. if 3. fails, install and build a bit more of KDE 3.5 and repeat
This is somewhat tedious – but knowing me I’d probably go for it except that this is my work machine and I don’t want to mess it up too much. If I have to go back to stock 9.3 and restore from a backup my data it’ll be even more tedious.
And all this in the mere hope that it’d work better with my phone.
Ok I’ve told this out of order slightly. I discovered that there’s two kmobiletools websites. The original one, that I was looking at, and the new one, which was more up to date. The new one had the same howto on building from SVN but it also had a packaged version of source for 0.5beta1 – i.e. a new version which should compile. I tried again and failed with the same setDisabled error. It was actually at this point I discovered that I needed KDE 3.5 and not QT4 etc. However what was also on the new website was an ISO image for a live CD that had everything you need to run kmobiletools 05beta1 from.
Now this is a really good idea. It means I can download it, burn it and get to see it running with my phone without doing anything drastic – like the plan above. So I did. I ‘wasted’ a CD-R – but what’s that compared to the waste of my time?
Well the results were less than inspiring. Oh first of all the live CD uses Slax, which I like but which doesn’t work with my LCD display. I actually plugged in a CRT monitor from another machine because I wasn’t going to look into that as well. The new 0.5beta1 works better with my phone in that I could unplug and replug without a reboot (though I think that’s partly a kernel issue so I’d need a kernel upgrade too). It’s a redesign with an interface that looks a bit like a webpage. I didn’t like it much but it’s jsut aesthetics. They’ve separated out the outgoing from the incoming so I wouldn’t see the ‘conversation’ together, I’d have to keep clicking between the two lists. Which is moot because I still can’t store-and-send like I’d need to.
So after all that it doesn’t really fix the things I really want fixed.
Conclusion
So, I titled this originally, “What I hate about Linux”. What do I hate about this? I guess it’s the hassle involved in resolving dependencies that are so entwined in your system that what seems like a small change (new version of a program), becomes a big exercise. I guess I sort of feel like this stuff doesn’t happen so much on Windows – is that true/fair?
I guess the main difference is that I’d be downloading a pre-compiled binary. I’d only be downloading a new version if one had been compiled. Each version would likely have bigger changes and there’d likely be longer gaps between the releases. I might also be paying money.
So if “WinMobiletools” 1.0 didn’t work I’d probably not have a testing/svn/beta version to try. And it’s possible that by the time 2.0 was released, if it co-incided with a new release of Windows, I wouldn’t be able to use it without upgrading that too.
Still none of that changes the perception that it’s more hassle.
Having said all that kmobiletools 0.4.3.3 does 85% of the job I want/need it to do and the other 15% is mostly annoyance. I am very grateful to the people that have written it, figured out all the awkward, fiddly, complicated protocol stuff and produced something that’s eminently useful.