Tag Archives: kde

For a course I did (Information Security) we had to create our own gpg key and do some signing and encrypting, well the normal stuff you seem to do with these things. As a side note, I did already did this twice some time ago but forgot the passwords of my private keys because I never used them so now I have two dangling accounts on the pgp servers *sigh*.

However, this made me have a look at KGpg which in turn made me cry. Heh, it seems in a not too good state. Having a bit of time, and being really annoyed by issues in the key server configuration page made me start hacking on it a bit. I fixed (hopefully) all issues in there. I have done this in trunk, maybe I should also back port this to 3.5 as the issues seems to be there also.

I don’t know if there is a maintainer currently and if there is I hope I didn’t pass you by. I did a quick search on bugs.kde.org but did not find any bugs related to this. Maybe I’ll take a stab to other issues I find too if I a) really start using gpg, b) have some spare time, c) find more issues (although that won’t be a constraint I think).

And last, it is not totally clear to me if there is any relation between kgpg and kleopatra, and if so what that relation is. If some kind soul could enlighten me on this….. that would be great. Continue reading →

About two weeks ago I added the postfixop check to krazy. This checks for postfix uses of ++/– usage. Initially I constrained the check to for-loops. However this lead to a huge amount of issues because also postfix usage of ++/– operators on simple types where marked as an issue. After some discussion with Eckhart Woerner and Allen Winterz I relaxed the check more so that usage on simple types is also not taken in account anymore.

Although postfix usage on simple types won’t gain you any/much I still think it’s a good thing to consequently use prefix wherever appropriate. However that has more a cosmetic reason (which I why I took it out actually) then a perfomance reason. Consider for example the next piece of code (and yes I’ve seen something like this somewhere in the KDE codebase):

QList::Iterator it = list.begin();
for( int i = someNumber(); it != list.end(); ++it, i++ )
{
...
}

I realize that it’s partly a matter of taste if you like this kind of code snippets in your code base or not. However for people who never have had some in depth programming course it might look like if it is arbitrary what you choose.

Another thing I’ve been thinking about last weeks is "What is the importance of cosmetic changes in relation to code quality". When browsing through the source of KMail while fixing issues reported by krazy I see a lot of things which make me cry. For example defining variables which are used only ~25 lines later or in 3 different context. These kind of things make my fingers itch to rewrite such parts. Well, don’t be scared, I didn’t….. if it ain’t broken don’t fix it, right? But I still can’t find a good answer on the question: is that sort of code broken? In some sense it is in my opinion. When I as a newcomer to the KMail code look into some sections I really have to read that twice or sometimes even more times to get some vague idea what is happening over there. I think that is something that can be avoided (to some extend of course, as not everything in life is as easy as we would like it to be). All this made me think that it would be a nice to have something in addition to the normal krazy checks which checks for situations where some cosmetic change might improve the readability (and therefore the quality?) of the code.

Well, leave me a comment if you have some noteworthy ideas about these topics.

p.s. KMail only served as example here, I guess there are more places which have similar issues. It’s just that I was browsing through KMails code while these thoughts came up. Continue reading →

Study has started again, which means that my attention is (slowly) shifting from KDE hacking to all kind of study related things. Which is not that bad as I have some quite interesting courses (information security, advanced c++ programming and computer vision). Normally this means for me that I don’t have time (but more, no energy) to do very much KDE hacking. However I found some task which can be done relative easily in between. Bringing down EBN  issues. I have worked out a lot of issues in KPilot already and currently I’m giving a stab at KMail.

While it might seem very dull, which it is in some sense, it is also very satisfying. Not in the first place to see the numbers going down on EBN itself . But when working on the issues you also see code transforming, becoming more uniform and in some cases more readable. I don’t know what it is but I just enjoy seeing beautiful code. (Might be due to the book Google send me this summer, and by hanging out too much with [ade] in the past).

One of the things I noted in KMail (but I’ve seen this also in KPilot) is a quite inconsistent use of header inclusion. This happens in two areas. The first is that in some header files no forward declarations are used even when that is possible (when only pointers or references of that type are declared).

So

#include <QtModule/QClass>

class MyClass {
...
QCLass *mVariable;
....
void method( const QClass& c );
...
}

The second thing is that the include lists are a real mess in some files. Sometimes even k includes and Q includes are mixed up. What I would like to see is having a preferred order for includes in each file. Let’s say: own headers, project headers, k headers, q headers and other headers. And the next thing I’d like to see would be to have the includes sorted alphabetically. These are in fact relatively small changes but I think most of the headers and cpp files can be designed to look that way. This really would make it easier for (new) developers to see in a glance which classes/methods are actually used and also to see if the class he wants to used is included already. Another little annoyance I did see was mixing up (between files): #include KMyClass and #include "kmyclass.h". I guess most of these things are not new for the readers of my blog and still we (including myself) make really a mess of things so now and then =:).
This wasn’t meant as some rant on the kmail coding style or something. Just wanted to share some thought about this in general. Please let me know if you have some useful comment on this subject. Currently there is unfortunately not a check for unneeded includes in headers in krazy, but this would be very nice. If you have perl skills please give winterz a hand on this. p.s. Even this can snoop a lot of time which should be spend on my study =:S. p.p.s. If you find issues in KMail due to EBN Fixes I did, please drop me a mail at: [b DOT broeksema AT home DOT nl] and I’ll try to fix or revert the change if necessary. p.p.p.s. The line edits in KMail will soon have that cool clear button…. Continue reading →

I finally tried out what I wanted to try for some time now. The problem (if you can call it a problem) I had is that one of the libs I worked on for my GSoC contained class that I wanted to test but that I did not want to expose to the rest of the world. As I did not have the time nor the knowledge to make that happen I just exported the classes so that the testcode could link against it.

Well that changed today and I took some time to figure this out. (Note: I’m not an expert on C++, libraries and such so if I do stupid things here, let me know). In the KPilot code we have an KPILOT_EXPORT define which looks like this:

#include <kdemacros.h>

#ifndef KPILOT_EXPORT
# if defined(MAKE_KPILOT_LIB)
/* We are building this library */
# define KPILOT_EXPORT KDE_EXPORT
# else
/* We are using this library */
# define KPILOT_EXPORT KDE_IMPORT
# endif
#endif


The way I understand this snippet is that it makes the symbol that is prefixed with it visible anyhow. But what I wanted is that the symbol is only exported when the tests are enabled. Therefore I added another define which looks like this:

#ifndef KPILOT_TEST_EXPORT
# if defined(HAVE_TESTS_ENABLED)
# define KPILOT_TEST_EXPORT KDE_EXPORT
# else
# define KPILOT_TEST_EXPORT KDE_NO_EXPORT
# endif
#endif


To make this work I added this to the CMakeLists.txt file:

string(COMPARE EQUAL ${KDE4_BUILD_TESTS} "ON" buildtests)
macro_bool_to_01(buildtests HAVE_TESTS_ENABLED)
configure_file(config-kpilot.h.cmake ${CMAKE_CURRENT_BINARY_DIR}/config-kpilot.h )


And the config-kpilot.h.cmake file got a line added that looks like:

#cmakedefine HAVE_TESTS_ENABLED

Now I can use:

class KPILOT_TEST_EXPORT IDMapperXmlSource
{
....
};

and the given class gets only global in the library when testing is enabled. I wondered why there is no such export in kdemacros.h as I found this quite a nice solution. The library won’t export symbols in release mode, which is a bit cleaner than just exporting everyting only to be able to test imo. But as said, I’m only a novice on this kind of things =:). This whole thing made wondering if there is some GUI tool to explore libraries. Continue reading →