What I really love about myself is that for some reason I can’t stop making really stupid mistakes. I know everybody makes them, but somehow I’ve got the feeling I’m doing much more than anybody else.
Latest two occurence are bugs in KDevelop3.5.0 (one of them being in probably all releases since 3.4.0). I mean how damn stupid does somebody have to be to
a) use 2 variables, one named line the other named sline in the same function and
b) then mix those two variables up, which results in this: Bugreport 158236
The other one was pointed out on IRC today, stupid logic mixup with the same code in the else-part as in the if-part of an if-else. No wonder that you can’t turn off the warnings in QMake projects in KDevelop3.
I only catched the last one “by accident”, because I usually read the IRC backlog when I wasn’t sitting at the PC for a while. This one probably wouldn’t have ended in bugzilla as apparently some people think its not worthwhile to file bugreports against KDevelop3.
Thats however not true, especially if you’re not using one of the unmaintained parts. But even then, no bugreport is always worse than a bugreport that gets closed as wontfix (or fixed in 4.0 which is not yet usable on a wide scale). Obviously the problem here is to know which parts are unmaintained. So here’s a (probably incomplete) list:
fortran, java, php, python (this one will come back for 4.1), sql, csharp, bash, pascal, kdevdesigner (short note: use the normal Qt designer, you loose almost nothing and gain a lot of stability), valgrind, fileselector (known to be pretty buggy), distribution packaging, texttools, clearcase, perforce.
I’m not saying that bugs (especially crashes and the like) against these components will simply rot, I’m just saying its unlikely that they’ll get much attention as we simply don’t have many active developers and need to work on KDevelop4.
As a recent thread on kde-devel showed that nearly nobody knows about this, I thought I’d blog again about Sublime. Alexander already wrote two parts, here and here
and it was even featured in a commit-digest article. Obviously thats still not enough :(
So to put it short: If you want an IDEAl like user interface, that is dockwidgets (note: not necessarily QDockWidget) and a central editor area, then I invite you to have a look at
Sublime Sublime. Its a Ui library thats solely based on Qt and kdelibs, even though its currently part of the KDevelop Development Platform. Its not yet finished, but it already supports quite some stuff that KDevelop3 had, including buttons for toolviews, automatic hiding of them, maximizing a toolview and “always show” option. The API is also prepared to support different Area’s (Eclipse calls this perspectives), so you can have different views into your application (for IDE’s this can be used to have a Debug, Code, Test and Design Area).
Once there’s another two apps using Sublime (and the Area stuff is implemented) we can even think about moving it to kdelibs, making it easier for apps that don’t need kdevplatform to use it.
So finally the dot story is out, there’s going to be a KDevelop Hackathon in April in Munich. There’s even a “free-for-all” (as space allows) weekend to get to know us, or finally try to talk us into implementing your greatest feature wish for KDevelop :)
KDevelop “oldtimer” Harald Fernengel pulled this one off and so far Andras (quanta developer) and myself have their tickets booked. Alexander and Vladimir are also almost set, just need their Visa and hopefully Aleix exam plans allow him to come as well.
I’m rather excited, this will be the first time I’m meeting other KDE hackers – besides the handful of people at froglogic. Especially interesting to see how much fun we can have hacking on KDevelop4 full time :)
So if I’ve got you interested read the article on the dot for further information.
I’ve been working on this since christmas IIRC. A cache for all card games in kdegames (thats mostly two right now, but who knows what future will bring us). The idea is simply to unify some of the code that both lskat and kpat used to cache svg rendered card decks. Both simply put the resulting image as png into your $HOME to load from there. Both also had code to load png themes which need a mapping of “new style” element names – which are used as id’s in the svg’s – and the old style numbering scheme used in png decks.
I had hoped that moving the caching to KPixmapCache, which uses 1 large file for the caching instead of multiple files , would’ve speed up the rendering on size changes. But as far as I could measure with my stop watch it didn’t help much – if at all. However the new card cache did help to move common code into a central place in libkdegames, which reduces maintainence “cost” (in terms of time spent) and also allows to write new card games more easily.
I’ve more plans for such unifications, specially for handling the deck selection and finding out some information about cards.
The cache-code hasn’t yet been comitted, I still need to port lskat and get some review from the games people. Also there are one or two outstanding issues to be resolved.
And to get back to the topic: What took so long is figuring out how all the geometry calculations work, so I find the right spots to place CardCache::setSize() calls. For kpat it wasn’t quite obvious and me being geometry-wise challenged didn’t help either. I really can’t think this stuff, I have to write those formulas and calculations down and run it through a few example numbers. :(