apaku

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.

I’ve made quite some progress the last days in the parser work for KDevelop4’s python support. That means the plugin itself doesn’t compile at all anymore

Thats quite ok, given that I’ve exchanged the parser generator (switched to the kdev-pg-qt) and that created a new AST from hand based on the Python 2.6 language reference. That new AST is closer to the actual structure of the code, whereas the generated AST is closer to how the language can be parsed. I’ve already started a AST builder that creates the new AST structure from the existing AST and also integrated that into the parser driver.

The result is sthat now the parser and its structures can be discarded as soon as the new AST structure is built. That should reduce memory overhead quite a bit as all the strings for tokens that are not used in the AST (like keywords, operators and such) are not held onto.

One hard small stumbling block was that kdev-pg and kdev-pg-qt didn’t initialize the token members in the generated AST. This results in them being initialized to 0. Obviously thats a proper token index in the token stream and you get a valid token and thus token text for that index. Unfortunately this means that whenever you have a rule like this: ( name=IDENTIFIER | 0 ) you need an extra boolean to store wether the member name actually was parsed or not.

The solution: Let kdev-pg-qt create proper initialization code. First attempt, done late last night (2-4 am) was obviously stupid and didn’t even get close to it. The right way was of course creating a new Generate-class that uses the visitor pattern to let the default visitor do the hard work of walking the kdev-pg-internal model and only hook into the variable declarations. In that part you have access to the member variable information and can print something like (*yynode)->name = -1;. This Generator put right after creating a new AST node solved my problem. Thats my 3rd feature contribution to kdev-pg(-qt), YAY

To close this post just a short note regarding the bashing going on on the dot: KDE4.0 is for enthusiasts, developers and eventually power users. Not for average joe who’s accustomed to kde3’s desktop and hesitant to change his habits. And quite frankly I don’t see that much of a difference between plasma and kde3 desktop from the users pov, its a taskbar with applets (or plasmoids, whatever), a desktop where you can put things (things being not only icons but also cool widgets) and a menu. And Aaron, before you get passionate again ;), I know the underlying technology is completely different and the abilities of plasma are way beyond what kicker and Co could ever deliver - but it really doesn’t look all that different at first glance.

The last two days I’ve spent hacking on KDevelop-PG, the parser generator originally written by Roberto Raggi and used for forthcoming QMake, Python and Ruby support in KDevelop4.

There are basically two changes I’ve done, change from STL like class and method names to Qt-ish and change the container classes and similar things to use Qt classes - both for the kdevelop-pg code and the code it generates for your gramar. Most important reasoning for this is maintainability by those people that currently use KDevelop-PG, which is Alexander Dymo and myself. I guess its not that big a problem for Alexander, but I often have a hard time really understanding how STL works - mostly due to me not yet spending any time for an in-depth review.

As introducing Qt as a dependecy for kdevelop-pg as well as the generated parsers is a step not every possible user of kdevelop-pg wants to take we’ve essentially forked the parser generator, creatind KDevelop-PG-Qt. So anybody who wants to have a good LL(1) parser generator (with static and also kind of dynamic lookahead for k>1) without the heavy Qt library can still use kdevelop-pg.

The work was tedious, but not too hard, especially with KDevelop3 project wide search and search+replace I’ve also already changed the python parser to the new KDevelop-PG-Qt, though the rest of its language support will have to wait until the hand-crafted Ast is done.

My next todo item for KDevelop-PG-Qt is making it bootstrap itself, possibly including a hand-written lexer to be able to read unicode input properly - just in case anybody wants that