Just a “quickie” while I wait for kdevelop3 to open the kdev4 sources.
I just did some debugging with MS Visual C++ and I feel like hugging our own debugger guru Vladimir Prus. I often heard people on #kdevelop complaining about the KDevelop3 debugger being sooo slow when debugging, especially compared to MSVC. Sorry, but I can’t sign that anymore, doing a procedure step in MSVC takes at least 1 or 2 seconds and it is not much slower than in KDevelop3 (kdev3 is a bit slower than that, but nothing that you have to whine about it :). Also I noticed that MSVC forgot about a few local variables in its variable list, something that never happened in Kdevelop3 for me.
We do lack a couple of features from MSVC and I agree that KDev3’s debugger still does some things far too often, but really its not that bad at all.
I was almost there, I was soooo close to fixing the last few bugs in KDevelop4’s cmake support to work properly on win32.
And then I did a horrible mistake: Let Windows XP install the security updates. I don’t know how, but that completely screwed Windows network stack, to a point where nothing network-related even started. I started to undo some of the updates and at some point I got the network connections folder populated again. But I couldn’t get it back to actually assign IP’s as configured to the network adaptor.
So now I’m sitting here re-installing windows, just to test wether the last bugfix really helped…
I’m up and running again (after only 3 hours) and that bugfix I was talking about wasn’t the last one. There are at least two more asserts waiting to be fixed.
The last few days I spent again some time on porting kdevelop4 to win32. The first try was with mingw compiler, but the debugging techniques with that compiler are really poor. I don’t like the gdb console interface, especially that I can’t easily see breakpoints directly in the source code. I’ve tried a few visual debuggers but none really worked well.
So I decided to do the registration crap with M$ to re-activate my MSVC 2005 Express Edition. Along the way I found a strange bug in building qdbus here and also a shortcoming in the windbus cmake files (which got fixed meanwhile by Ralf Habacker). This time I used the emerge building-script for the first time and I’m quite impressed. It comes really close to what kdesvn-build provides for linux.
The larger task however was fixing all those little things where MSVC errors out because its often a lot pickier about correct code, like having no return statement in a non-void function. Unfortunately I’m stuck on the C++ part with a really strange linking problem (which doesn’t occur on mingw of course). If you’re interested have a look at the thread on the kde-windows mailinglist.
I also tried to replace the CommonC++ dependecy in the Teamwork plugin, but unfortunately I failed because of my lack of understanding how implicit-sharing and especially the WeakReference-stuff in the network library works. So still no win32 port for that plugin 😦 If anybody wants to have a try, there’s a “starting patch” that replaces the server-classes from CommonC++ with the eqiuvalent from Qt.
Alltogether it wasn’t that much effort (most of the problems where with the duchain and c++ support), though the gdb-part is not ported yet. I’m waiting for Vladimir to finish the threaded-debugger effort before starting that port.
So, today I said farewell to all the co-workers at the “Zentrum fuer Graphische Datenverarbeitung e.V.” in Rostock (thats a non-profit research facility). I’ve been working there as student since April 2005, so its been really quite a long time now. The last months was contract work because I’ve finished university. Its always been fun to work with them, though the work itself wasn’t always that much fun 🙂
Now I’m sitting here at my parents house and only have a bit more than one week before I’ll be one of those boring tax-payers. I’m going to move to my girlfriends place for the first days and see how driving from Lübeck to Hamburg will be. Whats great about the new job? I might have the opportunity to work with Qt/C++. I’ll be starting on January 2nd at Froglogic GmbH (some of you might know the founders) and as far as I can tell from the interview those guys are really nice and it seems to be a really cool working environment.
I’m looking forward to this new part of my life, though it’ll probably be a rough cut wrt. my spare time for KDE/KDevelop (also seeing that I’m not going to have internet for at least another week or two at my new home).
Diego is wrong, I doubt Konqueror will use QtWebkit with KDE 4.1, as far as I can see there’s still quite some way to go until there is a KPart for QtWebkit that has the same featureset as KHTML. Apart from that KHTML is still very active and very maintained, anybody looking at the commit log can see that. And so far I’ve only come across one site for which I need firefox, this blog page.
Diego is also wrong about another thing he said recently in his QDevelop announcement, unfortunately my comment there hasn’t been approved yet. Maybe there was something wrong about my name and email, unfortunately the blogsite doesn’t show anything in readable english and thus I had to guess where to write what. Anyway, what I wanted to comment on is that KDevelop can’t do the “maximize editor area to full mainwindow” thing, it can, all you have to do is close all toolwindows and you can do that in KDevelop3 with a simple keyboard shortcut. In KDevelop4 however you can even maximize the toolviews, this has been added by Hamish a few weeks ago, its really super-handy and very nice.
And last but not least I guess I also have to say something about the move of Trolltech. Its great, seeing that the xine-backend triggers a few problems/bugs in xine or even the kernel its really good to have another backend under linux (I have to admit that I’m not sure gstreamer works directly on top of alsa, maybe its using xine as well and thus the same problems might arise there). Its even better that we’ll have Windows and MacOS backends for KDE 4.0, that makes the whole process of porting to these platforms a lot faster – at least for the multimedia apps. And those might give KDE4 quite a momentum, at least on Windows where there are mainly two competitors which both are not as great as amarok.
Looking through the comments to the KDE4.0 RC2 makes me realize something once again: People don’t read and they don’t care.
Again comments of the type “KDE4 doesn’t deliver all stuff from KDE 3.5” and all of them are lying. Nobody knows what KDE4 will deliver when its matured. None of you people has only the slightest idea what KDE 4.5 will look like.
Please people, start to read: We’re approaching the release of KDE 4.0.0, the important part there is the 0. KDE 4.0.0 is still a baby, it just started to learn how to walk and can barely talk. Give it time to actually grow up.
Hmm, I’m wondering if any of those who need a KDE4 KMail will actually read this…
Due to the recent amount of bugreports that are filed against KDevelop4, I’m inclined to write this.
When you find a build error in KDevPlatform or KDevelop and you can’t fix it yourself, write to the kdevelop-devel mailinglist. Subscription is here: http://www.kdevelop.org/index.html?filename=mailinglist.html
If you find crashes, other bugs or have feature wishes: Write to the -devel adress as well. KDevelop4 is not open for general testing, its currently in a kind of alpha state. So anybody trying to compile or run it should be able to either fix problems he encounters himself or talk to the developers on the mailinglist or on IRC (in #kdevelop).
Until further notice all bugreports against KDevelop4 will be closed as Invalid.
I’ve blogged a lot lately, so let me add one last blog and then I’ll concentrate more on coding again (I’ve just managed to get myself a workload of new todos today).
People following the core lists or the schedule pages know that the next release candidate is coming, this might be the last rc as there probably won’t be anybody doing releases during christmas.
So I had another try with a KDE4 desktop on my laptop. You know that one with Xinerama (or rather XRandR 1.2 nowadays), two screens and not really that powerful CPU or graphics card (being more than 4 years old now). I have to say: I’m impressed. There’s been really great progress everywhere, kwin is as smooth as its kde3 version (sure composite doesn’t work fast enough for daily work, but its still usable for showing off). The menu seems to behave good, the panel isn’t just an ugly black bar and does sit where its supposed to sit. The background is customizable.
Congratulations to all people that worked their ass off to get the desktop into this state and my best wishes for the last few weeks (as I’m mostly out of that game, due to my points of interest and knowledge).
In fact I’m planning to use kde4 as my main desktop the next couple of days, because there’s one thing I really miss: khotkeys. And while I managed to fix the crashes in the kcm for it, making it work again needs a running kde4 environment. And constantly switching between X servers is not what I’d like to do every day.
Oh, there’s one other thing I need to figure out then: A good ICQ/Jabber client, currently I’m using Pidgin but unfortunately that one crashes with an X11 BadMatch error when it starts up, shortly after trying to put its icon into the systray. And kopete doesn’t seem to connect to ICQ server at all for me.
A minor issue for me is a nice theme, in kde3 I currently use polyester and a greenish color scheme, but with kdebase+kdeartwork I haven’t yet found something that really is appealing to me. That will come with time and for now its ok with Keramik windec+Plastique style.
Once again: Keep up the good work everybody and lets get this release out of the door.
I don’t know why, but somehow I had a great evening yesterday hacking away 6 hours straight. It was very fruitful, though not that much code was written. You could say I followed Trolltechs advertisement of “code less, create more”.
The result of that “little” more code: working support for importing a new project into Subversion or CVS. It was almost too easy to implement. The hardest parts where finding out that for some reason unpacking with KArchive* works fine when you use the “real” target directory, but not so well when you use a KTemDir and getting the import() function in the subversion plugin implemented.
Along the way the VcsMapping and VcsLocation classes got some extensions, mostly what was needed for CVS to work properly with them. That means a repository location consists now of a server string, a module, a branch string a tag and a path. Though anything except the server is allowed to be missing. Its also possible to transport some vcs-specific information, like the Vendor Tag information for CVS import.
IMHO our long discussions about the vcs interfaces really start to pay off, the app wizard has absolutely no idea about how to do the importing, or even get the metadata needed for importing. It also doesn’t know anything about checking out a project from the VCS, except that flipping the source and destination in the mapping for import() and handing that to checkout() will work properly.
I’ll skip the screenshot, its just too simple – combobox for vcs plugin and a few lineedits…
The last 2 days I’ve been bug-squashing KDevelop3. It was interesting sometimes, seeing how easily fixable some really old bugs were once you’ve checked the source. Sometimes its weird as well, like crashes in memcpy() while debugging an application.
The result is pretty cool, IMHO. about 80 bugs are now either fixed, worksforme, invalid or duplicates so that means KDevelop3 is now down to 202 bugreports. Thats less than kate, kopete and even the general kde component.
I plan to try to check out the feature wishlist as well during the next week, hopefully finding some old feature wishes that have been implemented in the meanwhile.