Brad Hards: thanks!

I met up with Brad Hards who was in Sydney yesterday. It's really great to meet someone in person that until now, I had only known on the internet (the only other person I've met in this way was Bart Oldeman from DOSEMU).

We had a very short meeting but he gave me some of his "old" hardware: a P4 3GHz HT machine and a P3 1GHz laptop, both with loads of disk space and importantly, RAM (1GB and 512MB respectively). This is truly impressive stuff that will dramatically improve my productivity:

With the hardware I was using before (and will still be using for a few days until I get the new stuff setup), a 2 line change to kdelibs/kdeui meant that I had to wait several minutes for cmake/make to rediscover libkdeui's dependencies, compile and install (and yes, I am compiling in the kdeui/ directory only), while the computer was thrashing due to the lack of RAM (224MB), worsened by a slow hard disk (10MB/s maximum sequential read). Not to mention the lack of disk space (7.6MB remaining).

So this new hardware is really, really nice stuff and super appreciated - less time waiting, more time coding. Thanks Brad!

I hope Scott Wheeler's Adopt-a-Geek program will restart at some point so that other KDE developers can benefit from such generous donations as well.

An interesting suggestion that Brad made was that perhaps some of us KDE devels in Australia (e.g. also Seb Ruiz, Hamish Rodda) could get together to do a state-of-KDE-4 talk at linux.conf.au in Sydney 2007. I think that would be a great idea so stay tuned :)

Why are languages so hard to learn?

I don't mean programming languages which seem trivial to pick up once one has seen a few. After all, one of my lecturers once said "anyone can program - even I can program".

So I mean natural languages. I've primarily used English since an early age. Since then, I've seriously tried to learn French, Mandarin, Japanese and now Mandarin again i.e. I spent a couple of years on each.

However, I usually only get as far as the basics like "My name is ...", "I live at ..." and "My grandmother is ... years old". After that, I get swamped in too much vocab and cannot remember anything. Did I start at too old an age? I hear that people in Europe learn a lot of languages at an early age (e.g. German, French, Italian and English) and they're very good at it.

What is it that makes natural languages so hard to learn compared to programming languages? Most programming languages are Turing complete after all! Even C++ templates at compiletime but that's another story...

So the only things I can remember now are:

je ne parle francais pas [I'm missing the circumflex under the 'c', sorry]
wakarimasen
我不知道

Any tips on how to pick up a language in the shortest possible time? I only need to be able to participate in conversations and read.

On dodging questions again

About my blog entry on How to dodge questions,
Timothy Warner writes:

'Clarence recommends a three-step approach for dodging a 'stumper' question
...
Clarence Dang's recommendation to "stall for time"'

Nono, you got me wrong there. I definitely do not endorse the three-step "Change, Stall, Intimidate" approach I describe. I simply wrote about it because I hate watching people use it.

In reply to aseigo on toolbars

Regarding my blog entry that the new KToolBar default of "Text Under Icons" takes too much space, Aaron Seigo writes:

"the problem is not bigger toolbar buttons, which are good for usability in many ways ... the real problem is that we cram so many (often stupid) things into our toolbars ...

"so when 'mail' appears in a painting program's toolbar (kolourpaint) one really ought to say themselves, 'wait a minute! this isn't an email program!"

I agree it could be solved by a more careful selection of toolbar actions. But the problem is that I didn't decide on the existing ones like "mail" - kdelibs did. The only ones I added were the zoom actions. Sure I could override the KDE defaults with noMerge="1" like I did with the "View" menu but this something that should really be solved on the kdelibs level.

Back to the question of which ones should go. Here's my personal preference:



6 actions - measuring that up with "Text Under Icons", it's actually smaller than the KDE 3 KolourPaint with "Icons Only". This is great but how do I know that the majority of people agree with my personal opinion? I would fight tooth and nail to keep the undo/redo and zoom actions, at least, but maybe everyone else in the world really does email their doodles all the time?

I agree in principle with bigger icons but the text just adds to the visual clutter after one learns what the buttons are. If we have fewer buttons, won't tooltips be sufficient?

KolourPaint paint engine experiment works

Today was one of those days where I started out thinking "I should really do some real [thesis] work today ... but half an hour of KDE hacking first can't hurt ..." Naturally, it is now almost midnight and the only thing I have done is KDE hacking. Maybe KDE programming has a secret ingredient that makes it addictive - NiKotine?

Anyway, given the sweeping Qt4 changes in the painting classes, I was extremely worried that it would not be possible to port the KolourPaint backend such that it would a) still perform OK b) support both XRENDER and non-XRENDER. In the meantime, I was fighting a battle to simply get KolourPaint compiling given the pace of kdelibs changes (see my previous blog entry's comments for an example). But today, I finally managed to hack around the last few important QPixmap/QPainter bugs and can demonstrate some 100% working tools: the Rectangle, Rounded Rectangle, Ellipse, Line, Connected Lines, Curve and Polygon:



[Note: if you appreciate abstract art and can see some deep meaning in the picture that I did not intend, feel free to contact me for licensing terms :)]

From this screenie, it should be obvious that KDE's new toolbar default of "Text Under Icons" does not work unless one has a screen with 5,000 x 5,000 resolution. As for why the Tool Box is in such a weird place and orientation, the short version is: breakages due to KToolBar changes. I will fix this and the longstanding problem of unconfigurable icon size by creating a new KToolPalette class after LiveUi (aka. XMLGUI2) is merged into trunk as I expect the merge will break all underlying assumptions all over again. Hopefully, blackarrow / Hamish Rodda will implement the class before I do so that I won't have to do any work :)

Previously, I got KolourPaint to not suck 100% of CPU doing QPixmap -> QImage -> QPixmap translations for opaque drawing operations but transparency was still unreliable and really slow. Now, I have opaque and transparent operations working with and without XRENDER.

So now that I have the underlying infrastructure working, porting the rest of the tools should be fairly straightforward and more importantly, now appears possible. Expect a set of fully working tools real soon now.

But don't use it for anything serious yet: shortcuts don't work (must have checked out kdelibs at a bad time), attempting to save causes a crash in kdelibs (yes, my previous piece of abstract painting was much better):

ASSERT: "d" in file /home/kde4/dist/include/ksharedptr.h, line 108
Aborted

I doubt the clipboard works due to the Qt4 changes and more importantly, I have rigged up assertions such that almost any tool not in the above list will cause KolourPaint to crash as the way they play with the paint engine violates some invariants. Sorry.

Finally, given the amount of time I've wasted hacking around QPainter bugs (read my commit messages and see), I'm going to try to charge Trolltech for bug reports (hey, they charge for the toolkit). Wish me luck :)

Got kdelibs compiling

This is with:

trunk/qt-copy -r558252
trunk/KDE/kdelibs -r558279

Make sure you run the ./apply_patches script in qt-copy.
Manually apply 0119-qaction-widgetfactory.diff - K3WidgetAction from kdelibs needs the QActionWidgetFactory class. Two Hunks will fail. Replace them with this:

--- src/gui/widgets/qtoolbar.cpp        (revision 558285)
+++ src/gui/widgets/qtoolbar.cpp        (working copy)
@@ -271,7 +271,16 @@ QToolBarItem QToolBarPrivate::createItem
             item.hasCustomWidget = true;
             return item;
         }
+    }
+
+    if (action->toolBarWidgetFactory()) {
+         item.widget = action->toolBarWidgetFactory()->createToolBarWidget(q);
+         if (item.widget) {
+            item.hasCustomWidget = true;
+            return item;
+         }
     }
+
     if (action->isSeparator()) {
         item.widget = new QToolBarSeparator(q);
         QObject::connect(q, SIGNAL(orientationChanged(Qt::Orientation)),
--- src/gui/kernel/qaction.cpp  (revision 558285)
+++ src/gui/kernel/qaction.cpp  (working copy)
@@ -54,7 +54,7 @@ static QString qt_strippedText(QString s

 QActionPrivate::QActionPrivate() : group(0), enabled(1), forceDisabled(0),
                                    visible(1), forceInvisible(0), checkable(0), checked(0), separator(0), fontSet(false),
-                                   menuRole(QAction::TextHeuristicRole)
+                                   menuRole(QAction::TextHeuristicRole), factory (0)
 {
 #ifdef QT3_SUPPORT
     static int qt_static_action_id = -1;

I have no idea if this is correct but KolourPaint -r558316 runs.

If you get this message even after invoking the dbus daemon:

FATAL: Session bus not found

$DBUS_SESSION_BUS_ADDRESS and $DBUS_SESSION_BUS_PID are not set because you ran dbus using:

dbus-launch --auto-syntax

instead of:

eval `dbus-launch --auto-syntax`

as dbus-launch actually prints out the shell commands used to set those environment variables.

Lastly, changing button order and making it not configurable is a worrying trend:



I hope this is a birthday prank or something...

Xine out of memory error message

If you see this when starting xine (1.1.1):

This is xine (X11 gui) - a free video player v0.99.4.
(c) 2000-2004 The xine Team.
video_decoder: can't create new thread (Cannot allocate memory)
abort: video_decoder.c:510: _x_video_decoder_init: Aborting.

check your "ulimit -v". Xine seems to hog at least 256MB of virtual address space, even if it's not actually backing that with physical memory.

Ordinarily, I use the ulimit mechanism to automatically kill runaway processes that are sucking too much vmem (on the assumption that it is all backed with pmem). Without ulimit, Linux would be swapping so badly that I wouldn't be able to run "top" to kill the offending process.

But now, I have to up this figure just for xine...