ZOMG, I'm a blogger now :).
Entries tagged "gentoo".
It's my pleasure to announce availability of new release of a great photo and video tagging tool, KPhotoAlbum. It is available from standard place or from your favorite distribution's package database.
New killing features™:
Usability improvements:
And of course also many bug fixes and speed improvements.
Release notes:
exiv2-0.15 or higherlibkdcraw-0.1.1 or
newerHappy photo editing and browsing with KPhotoAlbum :)
As I couldn't stand being the last man on the globe who hasn't tried KDE4 yet,
I decided to launch it. I opened another session under different user, played
with it a bit, used Ctrl+Alt+F7 to switch to my original session and then the
mighty kill command to kill the startkde script.
Well, I shouldn't have done it.
I thought that transparency wasn't meant to be working under my version of
fglrx :). Click the image for the Real Screen Shot.
It's my pleasure to announce availability of new release of a great photo and video tagging tool, KPhotoAlbum. It is available from standard place or from your favorite distribution's package database.
While new features are being added to the KDE4 version, we have decided to roll out a bugfix release that fixes some issues people have reported. This is probably the last release based on KDE3 code.
Bugs fixed include numerous improvements in the KIPI Plugins interface, fullscreen fix for some Ubuntu users and usability improvements.
Happy photo editing and browsing with KPhotoAlbum :)
When trying to test all these commits that blackie did earlier today, I
realized that various libraries in extragear/graphics were
apparently moved away from their former location. As it took me almost two
hours to fully restore my working environment (thanks for hints, thiago), I
think it's worth publishing a quick howto about how to build KPhotoAlbum from SVN. In the following
text, I'll use ~/work/prog/kde for the directory that we're going
to work in and assume that /usr/kde/4.0 is where you installed
KDE4 (you will need to install various development packages for kde4 if you're
on a distribution that doesn't install them by default). If you use a
different setup, please adjust all commands/variables properly.
Please use the guide at KPhotoAlbum.org instead.
# preparation mkdir -p ~/work/prog/kde cd ~/work/prog/kde # SVN checkout svn co -N svn://anonsvn.kde.org/home/kde/trunk/KDE/kdegraphics cd kdegraphics svn up cmake libs cd .. svn co -N svn://anonsvn.kde.org/home/kde/trunk/extragear/graphics extragear-graphics cd extragear-graphics svn up cmake kphotoalbum cd ../kdegraphics # configure, build and install the libraries PKG_CONFIG_PATH=~/work/prog/kde/_out/lib/pkgconfig \ KDEHOME=~/.kde4.0 KDEDIRS=~/work/prog/kde/_out:/usr/kde/4.0 \ cmake -DCMAKE_BUILD_TYPE=relwithdebuginfo -DCMAKE_INSTALL_PREFIX=$HOME/work/prog/kde/_out . make -j2 && make install cd ../extragear-graphics/ # configure, build and install KPhotoAlbum itself PKG_CONFIG_PATH=~/work/prog/kde/_out/lib/pkgconfig \ KDEHOME=~/.kde4.0 KDEDIRS=~/work/prog/kde/_out:/usr/kde/4.0 \ cmake -DCMAKE_BUILD_TYPE=relwithdebuginfo -DCMAKE_INSTALL_PREFIX=$HOME/work/prog/kde/_out . make -j2 && make install # Yeah, this is the same command as used for building libraries
Now that you've built KPhotoAlbum, it's time to launch it:
KDEHOME=~/.kde4.0 KDEDIRS=~/work/prog/kde/_out:/usr/kde/4.0 ~/work/prog/kde/_out/bin/kphotoalbum
It should be safe to do that from any X session, including the KDE 3.5 one.
I hope that this quick howto will prevent people from fighting with .so collisions coming from kde3's libkipi and struggling with FindKipi.cmake (no, you really don't want to symlink libkipi as a "local subdirectory", even when the cmake error message make you feel like you should).
Today I finally got time to open my last cell phone bill and found something which seemed like an error. I picked up the phone, called the customer service and got greeted by an automated voice that by the way mentioned to me that "To improve the child protection on the Internet, Vodafone has decided to filter out access to suspicious or illegal sites" (rough translation of a spoken notice). This made me really surprised as this is the first action of such kind in this country, AFAIK.
When I got put through to the operator and had solved the issue I was calling about, I asked him what the recently introduced filtering is, how exactly it works and if I can have it deactivated (I for one don't like my ISP deciding what I can and what I can't read, that seems too Chinese to me). He explained that this is done to protect the safety of children on the Internet (I don't consider myself a child, and feel pretty much comfortable on the Internet, thank you), works by filtering based on a "list of illegal sites", like those offering child pornography (I don't really suspect crowds of people downloading child pornography through their cell phones and watching it on the tiny screen) or promoting racism.
In their press release, they are nicely making the whole issue sound like an optional filter that allows parents to block drugs/sex/whatever from reaching their children, while in fact this is a ridiculous attempt to filter the Internet for all customers. When I pay for GPRS access, I pay for access to the Internet as a whole, not to a subset of it (and the "subset" is a very precise word here, and I even make the customer care guy say it to me). So, it seems that even Czech republic is starting to follow the admirable leadership of certain countries to censor as much as possible :(...
As you might already know from the news item at the KPA website, I'm currently sitting behind a table in a wonderful country of Denmark. I'm not sitting there alone, though, because we're having a small KPhotoAlbum development sprint right now. Jesper, the main author, was so kind to invite us to his home, the KDE e.V. paid the flight tickets, so all we have to pay is just the barrels of beer and the T-shirts. And that's an investment a typical developer makes with pleasure :).
So far we have made just 17 commits, but there's a lot of talk going here (hi Tuomas :p). For exmaple, the SQL backend is getting closer and closer to being completely ready, the support for multiple cores is shaping up (and you won't see that annoying flickering anymore) and we even have a cute, transparent infobox which looks really sexy.
Right now, I'm working on a reworked EXIF/IPTC/XMP import/export thingy, which would essentially allow you to customize how KPhotoAlbum imports the metadata from the images, and also to store these data back to the files for increased interoperability and stuff like that. So I'll be finally able to share all the captions and tags with a friend of mine who's using XnView. This feature was already present in the 3.1.0 version, but the GUI for it was, well, not really intuitive. I'm converting it to Kross, the KDE scripting environment.
As I brought a GPS device some time ago, one can also expect some efforts for integration with Marble. There's also a whiteboard full of interesting ideas which I won't mention here.
As Henner writes, we've managed to add a new feature that some users were requesting for quite a long time -- now there's that thingy for marking several images as "belonging together".
Imagine you've taken a group photo of bunch of your friends at a pub. You weren't exactly sober, so perhaps some of these are shaky, out-of-focus or otherwise imperfect. You weren't drunk as a lord, though, so there's one of them which is pretty good. Now you don't want to erase all the other pictures, but you don't want to see them by default, either. So what you do now is to make an Image Stack of all of them and select which are bad and which one is the best one. This feature might be useful for various variants of images decoded from one RAW file or for images stitched to one big panorama as well.
It's far from complete yet (the GUI part still sucks and you can't select your order of preference, either), but it's a good start and it got done pretty fast.
Lets look at an example stack with a picture of Gunvald (Jesper's dog) on the
beach. The default view in the thumbnail view shows only the first
picture:
… expanding to

Please read Henner's post as well and let us know what you think about this feature.
Shortly after my last post, I got a bunch of mails from our users. It's great to hear that people are interested in our work, so many thanks to all the readers! Please keep the comments going. Anyway, the most frequent question was interoperability with Digikam.
At first, I'd like to mention that I'm on a KPhotoAlbum Development Sprint. Nobody of us over here is hacking on Digikam. It surely is a great piece of software, but we don't use it ourselves. That's why I have to disappoint one reader of this blog -- nope, I can't blog about new features in Digikam, sorry. But be sure to check out the KDE Planet form time to time, their development team is blogging every now and then.
Now the interoperability thingy -- we have a nice file describing what the problems are. Looking at the document, I'm afraid that both applications are using quite different approach to tagging -- in Digikam, tags are (I haven't check the Digikam sources, nor am I using it, so this might be actually wrong) apparently in a flat namespace, while in KPhotoAlbum, we use a hierarchy (a tree) of tags for features like "pictures of Anna should be recognized as pictures containing anyone of my friends as well". This is certainly not a showstopper, but quite an important issue nonetheless.
However, please don't get disappointed too early. The question is -- why should we somehow prefer interoperability with Digikam over, say, XnView? There's a lot of users out there who are using different applications on different operating systems, and we'd like to do our best to be interoperable with all of them. At the same time, we certainly aren't willing to be held back by lack of features in other applications. Therefore, we won't write any feature like "copy my database to the Digikam format", nor do we expect Digikam to be able to import our stuff. (There's nothing holding you back in writing your own converter, though -- our format is pretty simple to deal with.) What we will do, however, is adding a feature for metadata import and export. We'll use standardized stuff like Exif, IPTC and XMP, so that it should be easy for KPhotoAlbum users to provide their friends with images with embedded tags (and the other way round, of course).
Another question was a state of the KDE4 port and the SQL support. I'll leave that for another blogpost, as this one got pretty long already :).
Dear lazyweb, it's been some time since KDE 4.1 was tagged. Gentoo, which used to be one of the most bleeding-edge distribution, has apparently failed to deliver this highly expected product to its mainstream users. We already have even a KDE developer complaining about what a miserable job we did. Well, I'm not going to deny the fact that the lack of KDE 4.1 in Portage probably doesn't make users happy, but let's see what the reasons are. Perhaps I can even persuade the P. T. reader that the statement "nothing happened in the Gentoo land" is false :).
I should probably add a disclaimer that even though I'm a Gentoo developer and have a KDE SVN account as well, I don't maintain KDE packages in Gentoo, nor do I hack on core KDE code. My KDE role is limited to working on KPhotoAlbum.
First of all, one has to admit that the package manager in Gentoo has had some long-standing issues which weren't exactly easy to solve. Due to the extremely wide set of options a user might have when installing a package (I'm talking USE flags here), testing all of these options is not a trivial task. Moreover, the possibility to depend on a package being built with some specific USE flag wasn't available until recently etc.
Preparing a package for a source-based distribution is not as easy as rolling out a binary package.
I won't go into much detail as it'd be probably pretty boring for an average
reader, but a quick summary is that the KDE team went ahead and instead of
keeping using the same hacks that were employed in kde-3 ebuilds, they drafted
a new revision of EAPI, the standard that describes functions available to and
the interaction among the ebuilds, the Gentoo packages (think
about a .spec file for RPM). From user's point of view, and
especially in the short term, there are no immediate benefits, and the big
downside is that this whole process takes a lot of time. From a technical
POV, though, this is the right decision, no doubts about it.
The way of creating a new EAPI is not that easy, though. As we're talking about a standard which is going to affect Gentoo as a whole, a lot of people want to make sure there are no obvious issues with the specification. One of the results is that there's usually some talk going on on the various mailing lists, one has to work closely with package manager authors to make sure that all the cool ideas are actually implementable etc. And note that one really can't use the new EAPI in the main Portage tree until it's approved. (The good thing is that it apparently got approved during the last Council meeting, which happened such a short time ago that we don't have a summary from it yet :) )
Yep, there were personal issues involved as well. Three members of the KDE team left Gentoo, others got pretty busy with Real Life™ and other projects of their own. While we are already seeing other people stepping up and helping the KDE team, the lack of manpower is certainly a problem. Gentoo, being a non-profit distribution and what not, can't afford having a paid developer working on KDE packages. I'm sure there are other (even source-based) distributions who aren't backed up by any company, either, but you should take this into consideration before you declare Gentoo as "dying".
So, if you've managed to read the whole mess up to this point, I guess you deserve a reward of some kind. So, what about a KDE 4.1 package? What? You thought that it is not available? Oh sure it is! It isn't in the main tree (remember, you can't use unapproved EAPI in the official tree), but available through an overlay and adding it is not really such a big problem. Please go on, read the instructions and enjoy KDE 4.1 on Gentoo!
Dear lazyweb, I'm writing a simple web viewer for images maintained by KPhotoAlbum. It is not supposed to be Yet Another Web Gallery Software, this piece is going to focus on users of KPhotoAlbum who just want to share a subset of their pictures on the web. The goal is to be able to publish all images which are supposed to be on the web with just one click, and display/use all custom tags et cetera.
The problem is that I suck at HTML/CSS, and therefore I do my best in avoiding designing pages. This is kind of difficult when writing a web application, though :(.
Therefore, I'm looking for a skilled HTML/CSS coder/artist who can provide a nice template. I'm looking for something really cool and shiny like rajce.net. There's no need to deal with Lightbox-like stuff, this part of the problem has been already solved. I still need some nice HTML/CSS bits for two pages: the list of albums and the thumbnail view (links randomly picked up from the list of albums they host)
Anyone skilled in HTML/CSS stuff who's willing to be listed in bold letters as a prime contributor to the project is encouraged to sent these templates to my mail. All templates should be under a reasonable license which allows both further distribution and some customization. It shouldn't prohibit its usage by professional photographs who will use this tool as a service to their customers, but prohibiting selling modified versions of your work is of course acceptable.
If being famous among KPhotoAlbum users and all people visiting the generated galleries is not enough for you, I'm willing to buy you a beer if you come to Prague or if we meet each other. And that's a nice deal, isn't it?
Apologies to the readers who expected a technical post, this is OT and just a response to Ryan.
I can't promise that I will love you forever, but I can promise that I will stay alive, so that I can call you, so that I can need you, so that I can commune with you, so that I can embrace you.
This is my translation of a quotation from the Czech edition of Louis Evely's Amour et Mariage (Lovers in Marriage is the English title). My translation doesn't match the level of the original (it's not technical English after all), but it's a great book worth reading, really.
If you are looking for a nice dark theme for the Qt Creator, you might want to
try my adaptation of the inkpot vim
theme. Just save it as
~/.config/Nokia/qtcreator/styles/inkpot.xml and select it in the
Tools -> Options -> Text Editor -> Color Scheme.
Please note that this might need a git version of the Qt Creator. Previous
releases did not have the feature of switching between several editor themes.
Therefore, if you don't have the corresponding item in the settings dialog,
put the following into your ~/.config/Nokia/QtCreator.ini:
[TextEditor] FontFamily=Terminus Selection="#ffffff;#678db2;false;false" LineNumber="#8b8bcd;#2e2e2e;false;false" SearchResult="#000000;#ffef0b;false;false" SearchScope="#000000;#f8fafc;false;false" Parentheses="#ffff00;invalid;true;false" CurrentLine="#000000;#2d2d32;false;false" Number="#506bbd;invalid;false;false" String="#ffcd8b;#404040;false;false" Type="#ff8bff;invalid;false;false" Keyword="#808bed;invalid;false;false" Operator="#409040;invalid;true;false" Preprocessor="#409040;invalid;false;false" Label="#e76000;invalid;false;false" Comment="#cd8b00;invalid;false;false" DisabledCode="#a0a0a4;invalid;false;true" AddedLine="#00aa00;invalid;false;false" RemovedLine="#ff0000;invalid;false;false" DiffFile="#8484f3;invalid;false;false" DiffLocation="#0084ff;invalid;false;false" Text="#cfbfad;#1e1e27;false;false"
When I looked at the state of graphical IMAP e-mail clients several years ago, I was not really impressed. KMail from then-current KDE3 did not do a proper job for me (numerous IMAP bugs like its inability to work as about every other IMAP client when deleting messages, bug 26986 -- there were more issues than that, but years have left my memories washed out a bit), Thunderbird would crash for me every once a week, at least, and I just happened to like KDE applications more than Gnome stuff, so I did not spend much time looking at Evolution. Many MUAs looked like a classic generic e-mail clients designed with POP3 in mind with IMAP added late in the development cycle, while others supported wide range of IMAP features, yet lacked in the GUI part of the problem. In short, using none of these applications made me feel happy.
A programmer not feeling happy is a receipt for disaster. I was about to finish my high school, so I had plenty of time at hand. I was experimenting with Python, so that seemed like a natural implementation language, too. In the end, I started a project called trojita whose remnants could still be seen in an abandoned SVN repo.
Coding in Python was fun. I tried several different approaches to the design of my pet program, I was playing with technologies I had no experience with, I even showed my "IMAP library" at my final exam as an example of a project I made. It did not have much functionality, in fact, only the IMAP parser had been completed, but it was an educative experience nonetheless and I passed the exam.
After some time, however, I discovered Qt and C++ and felt in love. I joyfully returned to the realm of statically-typed languages and suddenly felt a lot better. I began porting my Python library to Qt/C++. It was not really a port, rather a first complete rewrite of my project. Anyway, it did not take long and the C++ version suddenly offered more functions than the old Python branch, with unit tests as a nice added bonus.
Qt's Interview architecture, the Model/View classes, seemed like a decent
implementation of the MVC patter I was poking around to use. Several months
have passed, and suddenly trojita was able to show a tree of
mailboxes stored on a remote IMAP server, listing messages contained therein
and showing message bodies. I choose to finish the program as a part of my
bachelor's thesis, and ultimately, I succeeded.
So, in a few blogposts starting with this one I'm going to introduce a new Qt IMAP e-mail client to the world. I hope I will get some attention and folks looking at the code and trying to run the application. I'd love to get some feedback on program design, code quality and general usability as well.
The code is hosted at Gitorious, and
a bachelor thesis about
Trojitá (PDF) (mirror)
which explains its design and compares it against several alternatives is
available, too. Perhaps the most interesting part is Chapter 3 which describes
the architecture of the application, and Chapter 4 in which I compare Trojitá to
several other MUAs on the market. All information about Trojitá are also
aggregated on Trojitá's homepage (any
web designer listening? :) ). Here is the obligatory screenshot:
Some highlights of Trojitá are:
The thesis was completed several months ago. Since that time, I've removed
the dependency on std::tr1::shared_ptr and switched to Qt's
QSharedPointer which in turn requires Qt-4.5 or newer. There
wasn't much more changes since then, as I enjoyed quite a long vacation, but I
guess I can tell the development is getting faster again.
It's a fairly standard CMake setup:
git clone git://gitorious.org/trojita/trojita.git cd trojita mkdir _build cd _build cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo .. make -j4 ./trojita
Please do join the #trojita channel on Freenode and tell me how you
like this application. I'm open to any suggestions and would love to hear any
feedback, too.
As you can see, this blog is a static HTML page, so you can't post any comments here. However, I'm eager to answer any questions sent to my mail, both via e-mail and in subsequent blog posts.
This weekend I had the pleasure of travelling to a beautiful city of Schlitz. After some six hours on train, I arrived to KWest GmbH, a cool company which specializes in manufacturing of embedded systems, and which is nowadays busy developing an Internet tablet for a German ISP. It turned out that the company likes Qt and free software and is not particularly happy with the availability of Qt-based IMAP clients. As it happens, I was not happy with the world of IMAP clients, either, and I chose that as a subject for my bachelor's thesis a few years ago.
After having met KWest's representatives, we came to conclusion that Trojita is indeed a suitable IMAP e-mail client for them, and that while they do have a skilled development team, it would be beneficial for both me and them to work together. We have agreed that they will focus on bringing the GUI of the application up to speed with modern standards, adding important features like address book and a decent platform integration to the mix, while I will focus on what I'm good at, that is, improving the IMAP support, especially the offline mode.
The good thing for the community is that Trojita will remain under the GPL and that I'll be able to spend much more time on its development. Given enough time, Trojita will mature, and if everything works well, we will see a nice Qt e-mail application pretty soon. As usually, both the bug tracker and all source code remains freely available without any restrictions.
I'd like to thank KWest GmbH for giving me an opportunity to work on a free software project that I'm interested in, especially to Sebastian for inviting me and to Markus for being a nice guy to work with. And if you have some spare time and are looking for a nice little city to visit, be sure to stop in Fulda and Schlitz, their city centers look as if they came straight from a fairytale.
I've spent more than 10 hours in total changing the build system of Trojitá from CMake to QMake upon a request from KWest. The process was very painful for me, so I think it's worthwhile to include some comments about what were the major obstacles.
The first step, "getting the beast to build", was actually pretty easy -- I
(KWest actually) simply created a list of all files in the tree, added them
into a single .pro file, removed the #includes for
MOC, commented out the unit tests and rebuilt the project. That was the easy
part; qmake simply built bunch of .o files and linked them
together.
Problem with unit tests is that they all define the main()
function. Therefore, as far as I know, one has to create a separate
.pro file for each unit test, use the template =
subdirs and put each test into a subdirectory. That's slightly annoying
when compared to CTest (see the Trojita's git repository for how the
CMakeLists.txt looked before we switched), but doable and
actually pretty straightforward. Now, a much bigger problem is persuading
QMake to create static libraries and using them properly and in a
cross-platform way. I care about the Unix platform, some users want to play
with Trojita on Windows, and there's that secret device KWest is building.
Trojita currently consists of several parts; we have the core IMAP stuff
(which itself consists of three or four components), the GUI layer, some
third-party modules even (like Witold Wysota's qwwsmtpclient,
the Qt's iconloader, a unifying layer for QProcess
and QSslSocket etc). The unit tests for the IMAP protocol
clearly should not care about icons at all and shall ignore GUI classes, too,
but they do need to link against the IMAP protocol implementation. A
reasonable way to express that in the build system is to create a static
library for the IMAP stuff and link it to the rest of the GUI when
building the application and to each of the unit tests when building tests.
That's where problems with QMake start to hurt.
Unlike CMake, under which the static libraries are extremely easy to
write, QMake's support and documentation for static libraries leaves much to
be desired. A reasonable request is, for example, expecting the build system
to isolate me from stuff like library placement -- I just want to tell it that
I need to link against bunch of .arelease and
debug when caring about Windows builds.
Another expectation is that QMake should relink each binary if any static
library it depends on gets rebuilt. Too bad, using QMake, you have to include
the library name in three places for this to happen: at first, you have to use
LIBS += -Lpath/to/your/lib/directory, then you got to actually
link to it by LIBS += -lnameOfTheLibrary, and finally you have to
take care of the rebuilding by PRE_TARGETDEPS +=
full/path/and/the/libIdentifier.a. Oh, and please do not forget about
CONFIG += ordered, or the PRE_TARGETDEPS won't affect much stuff
anyway. Yuck!
There's the CONFIG += create_prl and CONFIG +=
link_prl, but they did not help me. I guess they are used for
specifying dynamic libraries on which the currently processed
static library depends. They certainly did not fix my problems when I
played with them, though.
Anyway, this is what I ended up with:
src/Gui/Gui.pro:
(...) trojita_libs = Imap/Model Imap/Parser Imap/Network MSA Streams iconloader qwwsmtpclient myprefix = ../ include(../linking.pri)
tests/test_*.pro:
TARGET = test_Imap_LowLevelParser include(../tests.pri)
tests/tests.pri:
QT += core network CONFIG += qtestlib no_lflags_merge DEFINES -= QT3_SUPPORT DEPENDPATH += ../../src/ INCLUDEPATH += ../../src/ ../ TEMPLATE = app HEADERS += ../qtest_kde.h trojita_libs = Imap/Parser Imap/Model Imap/Parser Streams myprefix = ../../src/ include(../src/linking.pri) SOURCES += $$join(TARGET,,,.cpp) HEADERS += $$join(TARGET,,,.h)
src/linking.pri:
for(what, trojita_libs) {
mylib = $$replace(what,/,)
unix {
mypath = $$join(what,,$${myprefix},)
}
win32 {
CONFIG( debug, debug|release ) {
mypath = $$join(what,,$${myprefix},/debug)
} else {
mypath = $$join(what,,$${myprefix},/release)
}
}
LIBS += $$join(mypath,,-L,)
LIBS += $$join(mylib,,-l,)
PRE_TARGETDEPS += $$join(mypath,,,$$join(mylib,,/lib,.a))
}
set(libImap_SRCS
${CMAKE_CURRENT_SOURCE_DIR}/Imap/Parser/Parser.cpp
${CMAKE_CURRENT_SOURCE_DIR}/Imap/Parser/Command.cpp
...
)
...
add_library(Imap ${libImap_SRCS})
...
target_link_libraries(Imap Streams ${QT_QTGUI_LIBRARY} ${QT_QTCORE_LIBRARY})
...
target_link_libraries(trojita Imap MessageView ModelTest MSA QwwSmtpClient QtIconLoader)
That's what I call ease of use. Anyway, the QMake change just had to be done (when the customer asked if I could migrate to QMake, I said I had no preference) and it's been done now. This blog post is just a rant, and hopefully might eventually make its way to Google's results for "qmake static library".
There's always the possibility that I'm just too dumb to miss a completely
obvious way to work with static libraries in QMake. If that's indeed the case,
I sincerely apologise to QMake designers. Also, I offer one beer as a sign of
appreciation to the first person who shows me that I'm indeed missing
something from the big picture. In the meanwhile, have fun -- QMake has a lot
of nice features and I'm no longer afraid to use it, now that the static
libraries are used properly. The make test is still missing, but
I guess I can live without that for a while.