KDE Blogs 

When I started reading pipitas blog about the fundraiser he's driving, my first thought was, “sure, how can I help, non-financially?". It's easy to donate time and help, and it's very appreciated. But sometimes you have to make the effort to do something more. Read More

(This entry is, of course, in relation to logs by ruurd, ruurd and mpyne) I find it troubling that after so many years, C++ still needs such detailed explanations about fundamental functionality. If this situation would have taken a few short years, we could have suspected slow social evolution from old (functional languages) to new (OOP) paradigms. But persistence, at the scale we see, seem to rather signal problems with the language itself. The current discussion is just a small sand grain falling in the timeglass that measures the evolution of my personal relationship with C++, from 100% love (1993-4) to fifty/fifty love/hate (2003-4). Read More

I call what njaard observed the wolfpack syndrom. The human being is a competitional animal (as any product of natural evolution) but with a twist. We premeditate the way we compete, we're not doing it instinctively. Read More

dataKiosk: It has been a busy week and with the release of dataKiosk 0.7 now completed I'm glad to see it is getting a little publicity on the dot. It is nice to know that others appreciate your work :) The state of the application is pretty good at this point. It still has bugs (if you come across any, please let me know) and quirks, but it is mature enough to handle a former MS Access project with over a million records between a couple dozen tables. Going forward, the focus is on making the data entry task as lighting fast as possible. Then I hope to integrate KJSEmbed for scripting the Virtual Fields and business logic. Read More

I stubled upon a post about features/usability curve. This article made be laugh; its a very good, highly recommended :) Choice quotes: "Of course you'll lose customers if you stop adding as many new features. "Or will you? "What if instead of adding new features, a company concentrated on making the service or product much easier to use? [] In a lot of markets, it's gotten so bad out there that simply being usable is enough to make a product truly remarkable." And this one: "Most of you here know that Don Norman talked about this forever in the classic The Design of Everyday Things, but why didn't the designers and manufacturers listen?" Note that just adding features is not a guarentee of making software unusable (the target link covers more then software); as always software is more complicated then that. Its more the lack of maintainance and attention to workflow that makes things hard in software. But software that just adds features tend to ignore that, so its a save bet :)

M2 was simply the internal codename for the project. So I found this one: ARRRGGH and no it's not an acronym, but I bet some people will work very very hard to find one :) The name simply came from the sound made by a sysadmin who simply screwed up something. Read More

As I said below, I just assumed maintainership of Kugar from adymo and have been working on re-integrating his local tree into koffice svn. Well, that is now complete, although there is still a whole lot of work to be done: d-pointifying the library, getting rid of the Qt-only shell, etc, etc. I also have a number of new goals for Kugar including greater control over grouping and sorting, making it easier to embed both the viewer and designer into other apps (dataKiosk and Kexi come to mind) and just general bug fixing and so on. Read More

I've got another suggestion. The best language to write the "./configure" tests in is one that developers are familiar with. I'm thinking C++. We can write the tests in C++, as long as they don't need any special libs, which seems likely. If you can compile with qmake, then that is enough. If qmake doesn't work, then the build system is terminally broken in any case. Read More

So what would the best buildsystem be, according to me? ./configure make make install In case you've been startled, read on. First of all, let's differentiate the system configuration checker (a.k.a. configure) from the builder (a.k.a. make). I don't mind if it is the same tool that does both jobs, but in my mind they are separate things. But I didn't say autoconf and make/automake. The build system has to be described by a simple file. I don't need complex rules to tell my build system that library libfoo is composed of foo.cpp, bar.cpp and baz.cpp. I would much rather see a simple NAME = VALUE based file, as much as possible. So writing a Makefile.am would be best for me. Any complex rules required by the build system (DCOP, kconfig_compiler, kdeinit, --enable-final) would be handled by a backend: a script of some sorts that would parse my simple NAME=VALUE file. This build system would produce simple, concise output when nothing is wrong, along with a progress indicator: Read More

So I made the mistake of reading my email first thing this morning and came across this gem: http://lists.trolltech.com/qt4-preview-feedback/2005-06/thread00567-0.html It made me reflect on how I have come to dislike some users of open source. Personally I am sure Mr. Rice is an nice person, and I would probably have a good time if we went out for a drink, but his email encapsulates the annoying message I hear at every LUG meeting and every Linux show I have the displeasure of attending. They want everything for free, and complain when they have to pay for anything. They fail to even appreciate what developers do out of hobby, or good will. Read More