Warning: This might be a quite boring blog entry for non-developers - no fancy screenshots and no new features... ;-)

Beside taking care to keep Dolphin simple and efficient for users, it is also very important for me to do the same for the code: It should be simple and easy to maintain for developers.

Sometimes this works quite well, but it also happens that parts of the code need to be refactored. It is quite common in commercial companies that developers don't get the chance to refactor the code: The user does not recognize it in the first sight and there is definitely a risk of having regressions.

I'm convinced that in the long-term keeping the code base clean pays off and results in less bugs and easier maintenance. Although some features like improved searching or version control support have been added for Dolphin in KDE SC 4.4, I also did some internal cleanups.

For KDE SC 4.5 I want to completely concentrate on fine-tuning the code base of Dolphin, so that some long standing bugs can be fixed in a clean manner:

Information Panel

I totally underestimated the complexity of the Information Panel before KDE SC 4.0 had been released and was never happy with the code-base. I tried to fix things from release to release (which can also be seen visually when looking at the screenshots from the Dolphin-News). Now with KDE SC 4.4 the code-base is a lot better, although there is still some work until it can be moved to kdelibs to get shared with other applications (I blogged about it already in Information Panel and Tooltips). One issue that needs definitely to be solved for KDE SC 4.5 is a non-blocking fallback solution for showing meta information even when Nepomuk and Strigi indexing are turned off (bug 193592). Also fixing the missing meta information in the properties dialog (bug 190588) is a must.

Column View

The column view has been added shortly before the feature freeze for KDE SC 4.0. I fell into the trap to assume that showing several columns cannot be much more difficult in comparison to the other views. The result was that the column view added a lot of complexity to the code and fixing column view related bugs was tricky. I cleaned up the code base for KDE SC 4.4 and am quite happy now: A lot of interfaces and workarounds could be removed, less code is needed and fixing column view bugs is straight forward. The beta releases and release candidates popped up some regressions, but they could be fixed quite fast.

Location bar ("breadcrumb")

Long before KDE SC 4.0 had been released, the location bar was only meant as prototype. It happened too fast, that we moved it to kdelibs to make it available for the file dialog... It was my fault not taking care to cleanup up the public interface of this widget before KDE SC 4.0 (honestly speaking: There really where more serious problems to solve to that time ;-)). I could not manage to do a cleanup for KDE SC 4.4, but a refactored version is already available on trunk. There are two nice "side effects" of this cleanup:

1. Dolphin can now easily remember the expansion state of detail-view trees when going back in history (I've to thank Frank Reininghaus a lot for his contributions in this area).
2. The Dolphin code could be simplified, as it is very easy now to remember history states.

There are also a lot of minor things I wanted to fix since KDE SC 4.0 already. For example in the icons view the wrapping of file names is only done nice on spaces or the minus symbol. Dots and underscores are handled like letters, which might lead to nasty wrappings like:
my_document.tx
t
instead of
my_document.
txt

The searching for Dolphin has already improved in KDE SC 4.4, but still needs a lot of work...

Things like these are what I'd like to fix in Dolphin for KDE SC 4.5, so please don't expect huge, new features :-)

BTW: I'm very happy to announce that on February the 1st I'll start working fulltime at Openismus. Most probably I'll get the chance to work with Qt for Maemo 6 (Harmattan).

The usual way in Qt, when an item view wants to render itself, is to ask the item model for everything, layout, style and the actual data. Storing view-specific layout information in the model itself means that views and models can always only exist in a 1:1 relationship. The logical conclusion: If you need to share a model between different views, you will probably have to add proxy models for each view. I wasn't satisfied with that idea, so I continued to research QStyledItemDelegates. They have the following nice properties:

1. They are owned by the view.
2. They have complete control over the cell they are assigned to (although that might not be too obvious).
3. They only get called if there's work to do, that is, nothing is wasted unless a cell becomes visible in a view.

So instead of having one proxy model per view, I can now keep the single model/multiple views approach by writing custom delegates for each view. For a tabular view, that means I want to install custom delegates per column or row (see Qlom's main window implementation).

How to change colors of a cell

Use the delegate's paint method, apply your changes to the QStyleOptionViewItem's palette and forward the paint request to the parent class. I had problems getting the correct background role, that is why I simply used the supplied painter to draw the background myself.

How to format data from the model in the view

The delegates' displayText method comes in handy. The model's data is wrapped in a QVariant already, so your custom delegate can apply all kinds of string formatting here. Just be aware that this method will never be called if the QVariant returned from the model (for the queried model index) is null.

How to replace a cell with a custom widget

For this, we abuse the fact that delegates are owned by their view. We only need to find a method that has a model index parameter, e.g., the paint method, and we are good to go! Inside that method, we query the parent() and use the item view's setIndexWidget method (perhaps check if there already is a widget at the given index, so that we don't end up re-creating widgets for every paint request).

In Qlom, the embedded widget is a simple button, so I was interested in its pressed signal. For that, I used a QSignalMapper to bind custom data (here: the model index) to the delegate's buttonPressed signal. Now the view can connect to the delegates' buttonPressed signal, unwrap the custom QObject to find the model index and display a nice message box with the exact model index of the clicked button.

Feedback and especially corrections welcome!

Okay, after checking exam dates, chatting with Olav and the Openismus crew, and having the Maemo and GNOME communities in mind I’d like to state:

Just booked a one-way flight to Brussels, not decided yet how and where to go back.

We (Openismus) recently got our GtkToolPalette widget into GTK+’s git master, to be seen in recent GTK+ 2.19 (unstable) tarballs. We haven’t had much extra time for this kind of thing, so I’m glad it’s finally done after being worked on now and then by Mathias Hasselmann, Jan Arne Petersen and Johannes Schmid. Thanks to Matthias Clasen for valuable reviewing and cleanup.

We hope that this can replace the hand-coded tool palette widgets in Glade and Gimp, as well as making this easier for new applications. It replaces EggToolPalette in libegg, where we started the work. Please take a look and report any problems. I’m already using it in a Glom branch.

Here’s the GTK+ API reference for GtkToolPalette. There’s a GtkToolPalette example in gtk-demo.

And here’s a little introductory Gtk::ToolPalette chapter I wrote for the gtkmm (C++) book. Note that gtkmm’s API reference for this is mostly empty, but fixed already in git.

The last two weeks were a bit… stressful.

First of all some Nokia-internal changes with regard to Error Management, then maemo.org Bugzilla moving to a new server. Unexpected side effect was data loss. Spent part of last Monday restoring what I still had in my bugmail. Still it leads to confusion and mistrust (”Why was my account deleted?” – “You probably created it in that data loss time frame?” – “Ah.”).

Then we had the Maemo5 PR1.1 release on Thursday (with a nice ChangeLog) and some problems on Saturday and Sunday, hence bugmail (change notifications) was not delivered.

Sharing other thoughts on broader issues that are currently on my mind:

Before writing the very first bug report (maybe even of your life) it’s recommended that reporters take a look at the How-To. Good bug reports save everybody’s time and issues get fixed faster. We should put this information on the first Bugzilla page to avoid frustration on both sides.

Also the number of incoming reports is constantly high, hence I am sometimes short with my comments (as I also have to take a look at the internal comments for public tickets, verify some reported issues in newer internal versions, keep stuff in sync, and other stuff). Depending on cultural backgrounds some of my comments might be misinterpreted as unfriendlyness.

For the high workload Ubuntu has a nice approach called 5 A Day which is asking community members to triage five bug reports a day. I’d be happy with any number though.
On a related note, for some reasons I expect more Nokians to be around in maemo.org Bugzilla after the next feature release (PR1.2) has been published. Looking forward to it.

Another problem is that many normal users don’t understand the difference between a bug report and a forum (I’ve blogged about this before, anyway). That’s predictable if you’ve never seen a bugtracker before, but if everybody wants Nokia to be more present in maemo.org Bugzilla and folks actually reading bugmail and responding, please reduce adding comments on what is helpful and avoid unneeded fullquotes or answering above the quote.
Especially if instructions how to provide further information have been posted already adding just another “I have this problem too” comment is unhelpful and creates bugmail noise in everybody’s inbox. Bug reports with hundreds of comments, mixing up issues with similar outcome but different reasons quickly become unreadable so the same questions or comments get reposted plus subscribed people tend to ignore new comments. Of course this is also a question of providing better information on how to provide logs etc – should spend time on this in the next weeks.

In general of course reading before posting is required, but people are lazy. “If this is RESOLVED FIXED, then why do I still see that issue here?” It’s explained that FIXED does not mean PUBLISHED, but we could consider renaming FIXED after having Bugzilla 3.4 in place, as it confuses many people. Red Hat for example calls an internal fix “RESOLVED ON_QA” in their Bugzilla until the fix is really available for public.

So that’s the reason why I educate people ask people to please “behave”. Sometimes I scare some people or maybe have less friends at the end of the day, sometimes people are fine with what I’m doing.
In any way it’s necessary, I just felt a need to explain my intentions in public after a bit of negative feedback in the last days.

I’m pleased to say that Peter Penz will become an Openismus employee at the start of February. I’ve known and liked Peter since I worked with him six years ago in Linz, Austria on a proprietary C++ mobile phone platform. Back then I was impressed with his skill and temperament so I’ve watched with interest as he has become a core KDE maintainer via the Dolphin file manager.

Obviously Peter will help Openismus as we gain experience with Qt for Maemo 6 (Harmattan) in addition to our continued use of GTK+ and gtkmm.

Peter will work from home in Linz, occasionally visiting the office in Berlin. I like the idea of another office in Linz though.

New York Times reports:

As the military rushes to place more spy drones over Afghanistan, the remote-controlled planes are producing so much video intelligence that analysts are finding it more and more difficult to keep up.

Yet another proof that technique cannot replace intelligence.

(Notice the wordplay.)

Erich: Not sure if Facebook is in charge. All that happens is, that people try to cheat and get cheated back. That's what happens to greedy people who consider themself smarter than they really are.

December’s long season of presents is over and Liam is now two years old.

He’s recently started the famous language explosion, learning several new words each day. He’s obviously aware that he speaks two languages, now learning to say both words instead of preferring the first one he’d learned. He still prefers hand gestures where he has learned them first, seeing no need to learn words for them too.

For the past couple of months Liam has spent the mornings in the crèche over the road. That’s why I’m online again every morning. It’s great for him to learn some independence and spend time with the same kids every day. Leaving him there in tears has been heart-breaking every morning for weeks, but now he’s happy to go there and is nonchalant about us leaving.

I was worried when he suddenly learned more German at the crèche, but that has settled down now. Still, I make an extra effort with plenty of English books and music and some DVDs of gentle British children’s TV from the 70s, such as The Wombles and Ivor the Engine.

The language explosion was accompanied by a sudden increase in general understanding and concentration. Now he happily listens as I read all of a Dr Seuss book to him and seems to understand narrative instead of just wanting to identify objects. His imaginative play is more complicated, with detailed routines.

We’ve had a little snow in Munich this week. Liam learned to walk in last year’s snow. I hope he remembers enjoying this year’s.

For the Miniature project I sometimes need to iterate over all graphics items in a QGraphicsScene, or more precisely, all items of a specific parent item, the chess board itself. For that, I use the QGraphicsItem::childItems() API. However, when used with STL-style iterators you have to be careful, since value types of that form can easily break the iterator idiom:

for (QList<QGraphicsItem *>::iterator iter = parent_item->childItems().begin();
     iter != parent_item->childItems().end();
     ++iter)
{
    (*iter)->doSth(); // Ooops! Invalid iterator deref'ing! 
}

The value-type list that is returned by parent_item->childItems() has not been bound to a variable explicitly, so it is bound to an anonymous variable instead. The compiler will not complain here although the code is borken, from a C++ point of view. Worse yet, "(*iter)->doSth();" might work often enough for you to not see the crashes right away, depending on the compiled code and how the architecture handles memory.

Eventually though it will crash, and according to Murphy this will happen right after the big release. Valgrind of course would have complained about the illegal memory access right away (when run through that part of your code), because the list that we queried in the loop header is invalidated as soon as we enter the loop body, leaving us with an iterator that points into the void. This is C++-specific, in other languages even anonymous variables are only ever cleaned up after leaving the current block context, but in C++ their life time is only guaranteed for the scope of the current expression.

There is one fix and one workaround to that problem. First the fix: let QGraphicsItem::childItems() return a reference to a list member instead, or simply expose the begin/end iterators for the internal data structure directly. Assuming this is not possible, we are left with the workaround - bind the returned list to a variable explicitly, before the iterator is used:

QList<QGraphicsItem *> children = parent_item->childItems();
for (QList<QGraphicsItem *>::iterator iter = children.begin();
     iter != children.end();
     ++iter)
{
    (*iter)->doSth(); // Fine!
}

This of course prolongs the life time of the returned list unnecessarily. We only needed it inside the loop, but now it won't be cleaned up until the flow of control leaves the surrounding block context. To finally get the desired behaviour we could limit the surrounding block context:

{
    QList<QGraphicsItem *> children = parent_item->childItems();
    for (QList<QGraphicsItem *>::iterator iter = children.begin();
         iter != children.end();
         ++iter)
    {
        (*iter)->doSth(); // Fine!
    }
}

Perhaps a cleaner way is to move the loop code in a function of its own instead, although that might not always be feasible, depending on the code inside the loop body.

Another issue might be the need to dynamically cast QGraphicsItems (QGI) to the desired type, once you implemented your custom QGraphicsItem type. This wouldn't be too bad if there wasn't this horrible mix of QGraphicsObjects and QGraphicsItems in Qt 4.6 - some items inherit from QObject (QGraphicsSvgItem), others don't (QGraphicsPixmapItem). So now you also have to decide between dynamic_casts and qobject_casts, how nice ... not! Honestly, it would be easier here to simply forget about qobject_casts, but that might break in subtle ways.

These two issues were enough for me to avoid the QGI::childItems() API whenever possible. One possible replacement can be provided by signals and slots [1]: First, add a slot representing the loop body to your custom QGI type. Second, connect a signal to the instances of your QGI type that would have been iterated in the loop, that is, have a custom signal representing the loop iteration. Then, instead of iterating over the children of the parent item you simply emit the custom signal which triggers the "loop body" execution for each connected custom QGI instance.

[1] requires QObject inheritance for your custom QGraphicsItem type

This morning my calendar told me there’s a new year available, so I created some quick & dirty statistics for my favorite bug databases:

• maemo.org Bugzilla 2009 stats
• GNOME Bugzilla 2009 stats

Like last year my private soundtrack for 2009 in alphabetic order. (Warning: Explicit lyrics and/or video content.)

Röyksopp and The Dø to mention separately, because both albums are just marvelous. Quite unfair to pick just one song here.

Miou Miou – À l’été de la Saint-Martin ‘68 / School of Seven Bells – Connjur / Depeche Mode – Everything counts (Oliver Huntemann & Stephan Bodzin Dub remix) / Paul Kalkbrenner – Gebrünn Gebrünn (Berlin Calling Edit) / N.A.S.A. ft. Kanye West, Santogold, Lykke Li – Gifted / Dear Reader – Great white bear / Unkle – Heaven / Dragonette – I go around (Midnight Juggernauts remix) / Black Eyed Peas – I got a feeling / Yarn:moor – It’s blooming / London Elektricity – Just one second / Friendly Fires ft. Au Revoir Simone – Paris (Aeroplane Remix) / Lady GaGa – Pokerface / Metric – Sick muse / Lady Sovereign: So Human / IAMX – Spit It Out (Designer Drugs Remix) / Hell – U can dance / David Guetta ft. Kelly Rowland – When love takes over / 2raumwohnung – Wir werden sehen (Paul Kalkbrenner Remix)

Long time no update on the Cleanup part of GNOME 3, hence if somebody wants to spend the Christmas days with hacking a bit on boring stuff, here’s the ToDo list!

• Killing libgnomeui: gnome-panel
• Killing libglade: gdm (patch available awaiting review), gnome-media (initial patch exists, but help and feedback needed!), sound-juicer (patch available awaiting review), mono
• Killing libgnome: tomboy
• Killing libgnomecanvas: Evolution
• Killing Bonobo: Currently blocked by gnome-panel, the new A11Y infrastructure (which is on a good way), and for gconf by the proposed desktop wide move to dconf/GSettings for 2.31.
• Killing GlibDeprecatedSymbols and GtkDeprecatedSymbols: Moving target…
• Cleaning up GTK Includes
• Use GSEAL: Moving target as per pending sealings and missing accessor functions. Maintainers: Please do take a look at your module(s) by compiling with -DGSEAL_ENABLE!

And in the extended basket:

Killing libsexy: vino

Killing HAL: See the open dependencies of the meta bug

Killing XULRunner in favor of WebKit: yelp

So, what did I forget in this quickly written list?

Nice to see more and more modules getting Introspection Support.

Worth to consider: XDG config folder implementation.

Also I’d like to give a big “Thanks” to Javier Jardon for working like mad by both filing bugs and providing patches in these fields, especially when it comes to GTK+.

Being not subscribed to GNOME’s foundation-list mailing list (and having no intention to subscribe to it), I tried to catch up a bit with the controversy of the last days. I might have missed stuff of course.

Trying to summarize:

Initially, Lucas brought up complaints received about content posted on Planet GNOME which triggered a discussion whether there should be rules on appropriate content, whether an annual reminder should be sent to blog authors aggregated to Planet GNOME (telling them that they can remove themselves if they don’t feel fine with it anymore), and whether GNOME has “lost” people because of reasons that could have been avoided.
RMS joined the discussion and Philip disagreed with him. RMS then wrote that people should not post about closed source on Planet GNOME and defined his “most minimal support for the free software movement” . Because of the obvious disagreement, Philip consequently proposed “to have a vote on GNOME’s membership to the GNU project”. Dave warned that such a vote “could cause a lot of harm & discord for the GNOME community” which was answered by Philip.

So far my summary.

Other folks may find other postings more important than the ones I’ve picked – feel free to read the entire thread yourself to get your own opinion.

Now some questions come up here:

• How is “membership to the GNU project” defined? Was “FSF membership” meant here maybe? Is there a public document?
• Is KDE nowadays such a “member to the GNU project” too? If not, why not? Did KDE try or consider applying for it? Links to potential past KDE discussions appreciated.
• Wikipedia states that “the Linux kernel is not part of the GNU project” which leads to the question: How important is it for the GNOME community to have GNOME being a member to the GNU project? (As a sidenote, the term “GNOME” being an acronym is obsolete, just to avoid a useless discussion about potential project name changes).
• I wonder if members of the FSF’s board of directors agree with Richard Stallman’s opinion that Planet GNOME “should not invite people to talk about their proprietary software projects just because they are also GNOME contributors”. As clearly written, “Planet GNOME is a window into the world, work and lives of GNOME hackers and contributors” which also covers activities outside of GNOME, may it be philosophy, hunting, music, non-free software or anything else, as long as blog authors have some relation to GNOME. For technical news there is always GNOME News.
• Which influence do FSF members have on FSF decisions? For example the Windows7 campaign got some bad feedback within parts of free software communities. How transparently are decisions made in the FSF, e.g. deciding about such campaigns? Who is involved? Are there public archives (URLs)?

Sorry if answers exist out there and I have been too lazy to search or have not found them yet.

With regard to my current personal opinion (which may of course change as I’m willing to learn), having read Richard M. Stallman’s recent posts on the foundation mailinglist, he remains a fascistic extremist to me, painting black & white, ignoring reality (with a bad impact on free software user experience if you cannot interact properly with closed source products that obviously do exist out there) and trying to exclude folks from the GNOME community (because they also work on VMWare stuff) because he knows better what’s good for the GNOME community.

RMS has done great work in the 80es and 90es that I really appreciate, but I prefer to forget about his last years (a bit similar to Michael Jackson actually), especially his GCDS keynote in 2009 (yes, I have to come up with this again, because it’s part of the picture). RMS was a non-funny comedian with jokes that can easily be interpreted as sexistic (to me they definitely were, though that most probably was not his intention), trying desperately to auction a GNU puppet by behaving like on a children’s birthday. Okay, one can probably discuss humor here. At least it was not my type of humor. If GNOME ever invites RMS again to a conference, I prefer to stay away and not go there. It’s simply not the community that I want to be part of and proud of.

I always tell myself that RMS does not speak on behalf of the entire FSF, as the FSF has good intentions. But good intentions don’t count if the actual acting and outcome is bad. Plus organizations normally are reflected quite well by the leaders that were elected to represent them.

So yes, the discussion might be definitely less heated if the request to not post about closed source on Planet GNOME had been posted by a different person than RMS, as he himself is controversial enough already. Plus for many people, FSF = RMS.

A general note at the end: “Freedom” to me is also the personal freedom to tolerate and even to use non-free software from time to time, without having a big issue if it fits my needs way better. (For potential “Then help the free software to become better!” comments: I talk about the present here, not about the future.)
And I have enough friends working on closed software. They are awesome people. They just have a different concept that I totally accept because I’m not in a position to say “My concept is the only right one and superior to any other concept”. I prefer to let history decide on that instead.

Before a feature is added in Dolphin, it is checked whether the feature is mandatory for Dolphin’s target user group. If this is not the case, it does not mean that the feature cannot be added; first it must be clarified whether the feature might be non-intrusive and adds a value for users outside the primary target user group. Non-intrusive is mainly related to the user interface. A feature that adds a lot of clutter to the main menu, context menus or toolbar might harm the target user group. In this case the feature will not be added.

A good example of a feature that is non-intrusive is the embedded terminal in Dolphin. It only requires one entry inside a sub menu, but adds great value for a lot of people that are not in the scope of Dolphin’s target user group.

Another kind of non-intrusive feature will be available for Dolphin in KDE SC 4.4: version control support. In KDE 4.4 at least a plugin for Subversion is given:


The version state emblems and additional entries in the context menu will only be shown if a directory is under version control, so this feature fulfills the requirements for being non-intrusive. The plugin still has a lot of rough edges and has mainly been written for testing the plugin interface. Still I use it regularly and it fulfills most of my needs.

It is possible for developers to write other version control plugins for Git, Mercurial or whatever, just by following the instructions given in the plugin interface. In KDE SC 4.5 it is planned to embed the plugins as part of the kdevplatform package, but this has not been finally decided yet. The benefit to offer the plugins as part of kdevplatform will be, that the existing infrastructure for version control integration can be reused by the plugins.

Big thanks go to Nuno Pinheiro, who created icons for the version control states!

Great to see the interest on Maemo in the last weeks. As expected, traffic in the forum, in Bugzilla and in Brainstorm has increased impressively.
Discussions have been taking place (with regard to Bugzilla for example here or here) how to make infrastructure work out better for users, with some good proposals. I am also impressed by the patience and friendlyness towards new folks not searching for already existing threads or bug reports, partially pushing the limits of english grammar and punctuation, or towards folks having wrong expectations (Symbian is a completely different codebase than Maemo, hence talking about “regressions” is technically speaking wrong. If you want all of the Symbian functionality and lose some of the Maemo functionality, just get a Symbian device if it makes you happier). On a related note, I’m also trying to keep Bugzilla a technically focused place and make clear that it’s not a forum (”WTF???” comments are counterproductive noise if you want developers to read maemo.org Bugzilla mail, really).

Two issues that have been on my mind lately:

• I am afraid of Nokia doing the same mistake for Maemo5 that was done for Maemo4 – evolving and supporting a platform just for a few minor updates which is bad for the ecosystem around. “Maemo hasn’t had a chance yet to gain real long-term stability. The life-cycle of a Maemo version is too short for that, and there is no continuity between versions.” If 3rd party developers are unsure whether to write their new great application in GTK (abandoned for Maemo6) or Qt (not yet ready for Maemo5) they in doubt don’t write it at all and might support a different platform instead.
• Also, there must be improvements with regard to contributing (patches or even co-maintenance of modules). It’s too unclear where to find which codebase. Garage? Stage? Gitorious? Is it free or closed? Glad to know that Stskeeps is working on it as part of the maemo.org Sprints (ID: 9.11-04).

Open source community expectations are about taking (Give me the code!) but also about giving back (Let me provide patches in Bugzilla and have maintainers review them!).
Tarballs are available in the repositories, but hackers normally prefer the fresh code instead.

Photo by brentdanley, CC licensed

I’m proudly announcing the first maemo.org Bugday:

Tuesday, Dec 15th, 18:00-03:00 UTC
in #maemo-bugs on Freenode IRC

This is a nice way to get involved if you are a fan of the Maemo platform and the N900, but cannot or do not want to write code for example.

Bugdays are about hanging out together on IRC, triaging/discussing some reports in maemo.org Bugzilla, and introducing new people into triaging. No technical knowledge needed, no obligations. So, step by and say hello to the Bugsquad.

And now to some other bits and pieces:

• We’ve become stricter with regard to having non-trivial enhancement requests filed in Brainstorm instead of Bugzilla. To avoid reporter frustration, a note about Brainstorm when entering a bug report will be displayed in Bugzilla soon (Karsten is looking into this).
• New shiny Bugsquad logo by wazd (see above). Thanks!
• Published and updated version of my small maemo.org Greasemonkey triage helper script. Happy to share this.

As Andre mentioned, me being back part-time to the technical side of Bugzilla and taking hacking work off his hands already paid off — some minor, yet much needed Bugzilla tweaks finally went live. While Andre can keep fully concentrating on the growing number of community bug reports, due to a growing community.

The first task turned out to also require quite some cleaning-up, fixing and Perl compatibility coding, to get the maintenance branch back into working state. Once I won the fight with SVN, the requested changes were done quickly.

Currently I’m wading through SVN again (trunk this time), making heads and tails of some confusing commits, chasing missing templates and skins, to get a clean, almost vanilla Bugzilla 3.4 up and running, while maintaining our precious customizations. A whole lot of CSS fun is lurking right behind the corner — Bugzilla with the new maemo.org style!

Warning: the following blog post has a rant-to-usefulness ratio of 3:1.

Last week I needed to perform some data formatting on Qt list view. From reading the documentation alone I could not find a satisfying answer. When asking on IRC the answer was to use proxy models. This would have worked, but having two models for one view can create all kind of correspondence problems (think of sorting etc.). And there is this interesting bugreport, complaining that there is no easy way to format data. Status: rejected! So formatting should be a responsibility of the view? Wow, who would have thought ... however, if proxy models are a no-go we are left with ... custom delegates.

(cut some nonsense about MVC)

In the Qt world, a delegate is reponsible for 3 tasks:

• editing contents displayed in a view (possibly by creating new editor widgets on the fly),
• updating the model with the modified contents,
• rendering the contents in a view.

Somehow, that's two tasks too many, for something that is not a controller. That's where I prefersLet's take a look at GTK+ cell renderers: they only perform one task, and that's exactly what their names suggests(correction: actually, they are responsible for editing and updating as well, should have read more). A text cell renderer renders text, a pixbuf cell renderer renders pixbufs, and so on. Simple but tremendously flexible.

So how can I inject this flexibility into delegates? The QItemDelegate won't be very useful unless you want to use a QPainter for everything. But there is this styled item delegate, added with version 4.4 of Qt. And if we look at the roles & accepted types table we can see how this - together with displayText - could translate nicely into Qt "cell renderers". So we create custom styled delegates for each data type we need to display in our view: text delegates, pixmap^Wdecoration delegates ... Once we have defined a set of custom delegate classes we then request the view to use them on a per-row or on a per-column basis. A proof of concept can be found here.

EDIT: Had to correct some nonsense, this post was too much of a rant and I wasn't thinking clearly. What I originally wanted to express was that with QStyledItemDelegate we can have something very similar to GtkCellRenderer and use them both in a very similar way, too. I think the Qt documentation could have been easier to follow with straight and simple formatting data example, hence my rant. Sorry =/

I’ve been trying to use gnuplot instead of Gd::Chart in my massif_grapher script, mostly just so it can generate zoomable postscript or SVG output.

I first tried using the Chart::Gnuplot perl API, but after a very helpful email conversation with its maintainer Ka-Wai Mak, we found that it cannot yet be used to create gnuplot’s “rowstacked” histograms. So now my gnuplot branch of massif_brancher uses gnuplot directly. However, there are still some problems that I can’t solve easily:

• The x axis has a label for each item, which makes it cluttered, with overlapping text. I think this cannot be changed while using xtics(1) in the “using” statement, but that’s voodoo to me and I can’t find some version of the using statement that doesn’t use xtics.
• When using massif_grapher’s –detailed option, for instance with the example .out file, there are 60 stacked columns of data. The legend (key) is then so big that it pushes the graph off the page. I’ve asked about this on the gnuplot mailing list, but I am inpatient.

Actually, I wish I could do these stacked (or “cumulative” in Gd::Chart terms) graphs for regular line graphs, instead of just as items on a histogram, in case the snapshot times are not at regular intervals.

Glom has lots of code, lots of functionality and lots of UI. It’s easy to break things when making changes to the code. So Armin set up some initial Glom LDTP python scripts to check for regressions. These scripts try to actually use the UI and then check that the application worked as expected.

I’m sure I had that working once, but it doesn’t work for me now. I wish it did because it would be incredibly useful to me. Note that I build Glom in jhbuild, so I need LDTP to work there. To simplify things, I build LDTP in jhbuild too. I’m trying this on Ubuntu Jaunty and Ubuntu Karmic. Armin has a similar environment and it does work for him.

The problem is that the waittillguiexist() [1] function calls just timeout instead of recognizing that the first window has appeared. I definitely have accessibility support enabled, and Accerciser does show the window properly. I’ve asked the LDTP developers but they haven’t been able to help me.

[1] Yes, I hate that function name. I wish that the API and documentation had received proper feedback from native English speakers. It’s rather embarrassing to look at so far.

As I’m quite busy with the normal “Triaging and Syncing” business already (as seen above, a first increase of bug reports happened right after Maemo Summit in week 41, but I expect way busier times ahead) Karsten concentrates on technical stuff. It’s good to have him back as now stuff gets done that unfortunately was on the backburner.
First pay-offs (small, but definitely worth to mention, not only for the sake of transparency) that were done because I could “outsource” this to Karsten:

Having users/customers reporting a bug in order to improve a product is great (always keep in mind that they do not need to spend the time on that). However the freetext input makes this sometimes complicated: A “Steps to reproduce: Connect to foo.” is vague when there are several ways offered by the UI to connect to foo and only one of these ways triggers the bug. Also, some testers (me, for example) love to simply follow braindead exact instructions without the need to think a lot.
Hence Bugzilla now asks reporters to use an ordered list to provide exact steps. Yes, it is helpful.
Also, when it comes to reproducibility of issues an answer like “Sometimes, but not too often” is always a bit vague and does not tell how often the reporter had tried (once? five times?). Now we ask for numbers like “maybe 3 out of 10 times”.

Closing valid enhancement requests as INVALID just because they are better suited for maemo.org Brainstorm always sounded a bit rude. We now have a MOVED resolution plus a nice one-click-button-and-done implemented.

And third, we have a link to the Bugsquad on the maemo.org Bugzilla frontpage now.

More news to come.

Thanks to Mathias, Miniature is now suitable for debian packaging. He also uploaded a first test balloon which at least allows you to move pieces around. Feedback is of course more than welcome.

Personally I wish the board's cell size could have been made bigger, but 60x60 pixels is already the upper limit. It is now up to us - the Miniature team - to come up with clever techniques to make the board handling as finger-friendly as possible.

If I compare the number of files on my current hard disk with the number of files I had 10 years ago, I'm quite amazed. How to deal with this increased number of files is topic of a lot discussions. Tagging, searching, filtering, relations, virtual folders... - terms, where from a KDE-developer's point of view Nepomuk comes to mind, which provides already all the technical base. Still there is the task to integrate Nepomuk into applications, so that users out there are able to benefit from this great technology.

It's a small step only, but at least one step further: During the last week I've integrated Addam Kidder's GSoC 2009 work into Dolphin. I know that some people don't see searching and filtering as "the solution" to deal with the increased number of files and I agree. Nepomuk offers a lot more, still the searching and filtering is a basic feature, that I personally require quite often during my workflow. The current state of the code is far from finished, still the basics are there now. As soon as the search-bar at the top gets focused, the search configurations pop up below as shown here:


Searching for files having the tag "Tree" is very simple. Selecting "Equal to" and the corresponding tag in the combo-boxes beside "Tag:" has the following result:


One goal of the interface was to minimize the number of clicks that are required to specify a search query. That's the reason why per default at least three (hopefully) commonly used search criterions are visible. For sure it is possible to create very complex queries with more criterions too:


Still I think users will use such complex search queries quite rarely. I had some discussions with Sebastian Trüg and Alessandro Sivieri regarding the faceted panel, that exists as prototype currently. The discussion convinced me that a common workflow for users might be:

• Fill the search-bar with some keywords and trigger the searching.

• Only if the number of returned files is too high, start a filtering step by step on those files.

This might sound obvious, but has implications on the user interface:

1. The number of clicks to activate a filter must be minimized.
2. It should still be powerful: The kind of filters should not be limited.
3. Doing filtering step by step means that the user interface may not get hidden after triggering the first filter.

Especially the combination of point 1 and 2 have requires doing some compromises. Limiting the number of clicks requires more screen space. As there is only a limited screen space, the number of shown filters must be decreased. Finding a balanced solution is quite tricky.

I'm also unsure which data the breadcrumb should show: Visualizing a string like "nepomuksearch:/+lastModified2009-11-13 +rating8 +tag:Peter" to the user is something where I doubt Apple would do. Any suggestions would be welcome.

That's also one purpose to write this blog entry: Please let me know your daily problems when trying to search and filter files from your hard disk. I hope that I can integrate your input until KDE 4.4... Thanks!

After an interesting ride internal, I’m back to open and hacking Bugzilla — at least for a couple weeks — helping Andre with technical and coding stuff for maemo.org Bugzilla, as the increasing amount of incoming bug reports takes more and more time. It’s very nice to see the same old guys still around.

My priority tasks are first some quick, much needed tweaks to the current version. Then on to new lands, getting Bugzilla 3.4 in shape for maemo.org. Stay tuned.

Today at work, David King kindly informed me that there was some new Qt package in extras-devel. This could only mean one thing - I immediately fired up my scratchbox environment and installed the packages, trying to confirm that this new version would run with Qlom. And in fact, it was surprisingly painless. Thanks to autotroll, a simple QT_PATH env variable did all the magic, hooray!

Both of us were impressed with the UI improvements. It's certainly a big step forward regarding the Hildonisation of Qt on Maemo5. The application menues look correct now. Button sizes, colors, animations, etc - it all comes together nicely, finally.

There are still some widgets that need more work, but for a tech preview this is a pleasant surprise.

On another note, the timing for the Miniature project could not have been much better. We immediately switched to Qt 4.6, and it even runs on the N900. It feels good to know that we can stop using hacks and that we can start to do (most) things properly, staying as cross-platform as possible. Needless to say, Quim was happy, too.

Valgrind’s massif tool tracks how much memory an application uses over time, allowing you to see leaks. Previous versions produced pretty graphs. For instance, see the graph in this out-dated GNOME tutorial about massif.

However, massif’s behaviour has changed and those graphs are no longer generally appropriate. But they were nice. So I hacked a copy of the current ms_print perl code, producing massif_grapher. Forgive me for my perl code.

I used perl’s GD::Graph module. It worked but it’s a little eccentric. The image size is hard-coded and needs to be increased in the code when Gd::Graph complains that the vertical or horizontal space is too small, if you have too many data points.

massif_grapher.pl outputs a massif_pretty.png file:

• There’s a simple graph (the default) that just shows the stack and heap allocations, splitting the heap up into useful and extra (allocated as an optimization) . It doesn’t mention any functions. See this example.
• And there’s a detailed graph (via –detailed) that tries to show the old-style cumulative graph, with color for each allocating function. See this example. I won’t put it directly in my blog because their’s some obviously weird stuff happening at the top. Also, the legend needs to be reversed so it’s easier to associate the functions with the blocks on the graph. Patches welcome. You’ll get weird results if you don’t specify–detailed-freq=1 to massif.

Time will tell if this is useful.

Other useful massif tools:

• Eclipse Linux Tools’ valgrind support: Scroll down to see the video for their massif support. This allows you to jump right to the code. Useful if you are using Eclipse.
• massiftool: A Qt-based application for navigating massif snapshot data.

After collecting some feedback, the GNOME Release Team has finally decided on the release date for GNOME 3.0: It will be September 2010.
To take a look again at the GNOME 3 plan that was released in April 2009: Click here.

New module decisions for GNOME 2.30 were also made of course.

How it begun

When I read Quim's thread about the idea for a better Maemo chess app I knew I wanted to join the project. To me, it's all about the device and the sparkling Hildon UX. I really want a good chess app, for myself! I want to play chess online, everywhere! And I want to analyze games as (OK, maybe after =p) they happen. No more "I'll check this position later" (we all know this rarely happens).

So I finally started last friday. At this point, Quim and Andreas had already created a beautiful, content-rich wiki page. It took a while for me to digest it all, and I added information where appropiate.

Kick-starting the development

Andreas had registered a garage project, but we eventually decided to use gitorious for our repository. Gitorious' UI definitely improved over the recent months, and the possibility to have teams working on a single project - also known as not-so-extreme-dvcs-development - makes gitorious a better choice than github, at the moment.

Saturday night (what better things to do than coding some Qt - my soul will be forever lost) I had a first running example (see screenshot). Currently, Miniature can move between positions, using next/prev menu navigation (we don't need this functionality per se, but it's perhaps a good demonstration that the simple approach I took works).

So no matter the toolkit, no matter the outdated packages or the endless confusion I had with the various Qt repos at gitorious - this project is really fun! Hopefully we get to make a 0.1 release soon.

Dolphin for KDE 4.4 will provide a refactored information panel and refactored tooltips. The goals of the refactoring have been:

• Show the same data in the information panel and the tooltips. Up to now the information panel did not provide any information about the permissions or the owner of a file. The tooltips have shown this kind of information already, but they did not provide informations like rating, comments or tags.

• Prevent a possible blocking of the user interface, even when a slow Nepomuk backend or a buggy Strigi analyzer is installed. Although in KDE 4.3 some improvements had been done already, there have been still problems in this regard especially for tooltips.

• Improve the layout of the information. The rating, comment and tags information are not handled in a special manner anymore.

• Simplify the interface for editing tags and comments.

Although there is still a lot of finetuning necessary until KDE 4.4, it is obvious already that the tooltips...


... show the same information as the information panel:


Originally it was planned to move the refactored widget to kdelibs, so that applications like Mailody, Gwenview and Okular can show the informations in a similar way. However there have been some usecases especially in combination with Gwenview, where the interface of widget was not sufficient yet. So we decided to leave the widget in Dolphin for KDE 4.4, but I'm confident that we find a good solution until KDE 4.5.

I have finally got Glom packaged for Maemo 5. It is currently in extras-devel and is installable from the Application Manager. This took quite a bit of work, which I put down to not knowing enough auto-fu. However, the Debian packages are now /opt-ified, and the DBus .service file and .desktop file are installed to the correct locations on Maemo, which gives working application launcher icons. The process for doing this is not particularly well-documented (the best documentation is from Diablo), so here is a quick list of what the average (moderately complex desktop application) Debian package would need in order to be modified for Maemo:

• Maemo-optify support. This involves running maemo-optify just before dh_builddeb is run, and adding maemo-optify to the package's Build-Depends. For CDBS packages, this can be performed in the binary-install target. Glom produces several binary packages from a single source package, and maemo-optify is run for each binary package to be optified. There are alternatives to running maemo-optify, but it was something that I wanted to try out, and it worked.
• DBus .service file and .desktop file modifications. This involves adding a X-Osso-Service line to the .desktop file, e.g. X-Osso-Service=org.maemo.glom. Then, a DBus .service file must be created, with the same service identifier, e.g. Name=org.maemo.glom. The paths for installation of these files can be obtained via pkg-config from osso-af-settings (do not forget to add it to the Build-Depends of the package). My changes to Glom are in git (and a patch in the Glom package). The application must respond to DBus events if it is started in this way, and the simplest way to do this is to pass the DBus service name as a parameter to osso_initialize(), from libosso.
• Maemo-specific MIME-type modifications. Assuming that an application already installs MIME-type information and desktop files, and updates the databases correctly, there is one modification that can make things nicer on Maemo. There is an additional category that can be added to the MIME-type description. The change is safely ignored on non-Maemo-platforms.
  
• Atypically, Glom links to libgettextpo (most packages that use gettext for translations do not need to do this), and the package list on an N900 and in the SDK/package autobuilder is different, such that the required package does not exist on the N900. Rather than packaging gettext or libgettextpo for the N900, I decided to statically link to the library on Maemo only. This neatly solves the problem, and only increases the binary size by a few kB.
  

It has now been ten months since our move, and the tanks are finally starting to look presentable. Over the last couple of months I have also been getting in touch with various specialist breeders and importers across Germany, as all three of my display tanks were very bare up until very recently, as we concentrated on acquiring new furniture. After many emails, I have finally managed to find a friendly marine importer who had one of my favourite corals in stock: Duncanopsammia axifuga. It is probably one of the easiest corals I have ever kept, being undemanding in the lighting department and very hardy, requiring only the occasional feeding on a regular basis.

Our freshwater aquariums have also been looking up, with the addition of gravel and décor to both. The Lake Malawi Mbuna travelled well compared to the South American fish, and the yellow Lab (Labidochromis caeruleus) fry were especially resilient. As I am very limited on space, I have been raising them in my Rift Lake themed display tank which, unfortunately, means that I now have to find new homes for them.
The planted aquarium took the longest to recover, as many of the plants suffered during transport. It took a long time to find a suitable substrate so the plants were left to float at the top of the tank for many months after the move. I have had to put this tank at the top of the list for restocking because I keep keyhole cichlids (Cleithracara maronii), who are renowned for being extremely shy to the point where the sight of a neon tetra can send them into hiding, let alone a big, scary person walking into the room. Therefore, they require dither fish: any peaceful, small, schooling species which will indicate that there is no danger while they are out and about.
As for the quarantine tank, for the last four months, Jan Arne and Bev have been borowing it to try out fishkeeping; I think they are both addicted now.

First of all, C++ for web apps doesn't necessarily make it easier to write them. Compared to other solutions (let's say Django) you'll end up writing a lot more code. And you have to be very very careful with memory leaks.

But that isn't the point. The main advantage of this framework is how close it is to desktop applications. Porting your Qt desktop application to the web is certainly easier with Wt than with any other solution, as you keep most of the widget API and also the signal and slots paradigm (which should allow to port the app reusing the same business logic as on the desktop).

Also, this is the first time I could attach a powerful debugger, namely gdb, to a web app and debug it is as if it were a normal desktop app. Together with the compiler-guaranteed type safety this is a huge improvement for code robustness.

A toolkit that actually uses C++

There are also some distinct advantages of this toolkit over Qt itself:

• no MOC preprocessing (unless you integrate it with your Qt libraries, of course),
• boost::signals & boost::bind wrapped in an easy-to-use WSignal, keeping most of the boost API accessible for the user. Which means: the compiler can check whether your signal connections will work!
• boost::any instead of QVariant: another big advantage. Boost::any is type-inferred using template voodoo so again, the compiler can check its correct usage for you. Getting values out sadly requires a (static) cast it seems.

Installation

The fastest way is to simply get the source from the git repo and to follow the instructions:

• (enter your jhbuild shell if your project happens to use any GNOME stuff)
• enter the cloned git repo
• "$ mkdir build"
• "$ cd build #dont ignore this, it helps later on!"
• "$ cmake -i ../ #interactive mode asks lots of stupid things but also various path settings!"
• "$ make"
• "$ make install"

For your own projects make sure to link against all the needed Wt libs: libwt (core), libwtext (if you want to use anything from Wt::Ext, see below), libwthttp (if you want to build apps with inbuilt web server, quite helpful). If you happen to use autotools then you might want to include AC_CHECK_LIB macros into your configure.ac. I had troubles finding non-name-mangled function names, but "$ readelf --dynamic --symbols /path/to/lib/lib.so | grep -v _Z | tail" should help.

ExtJS

Wt wrappes a highly advanced (in terms of bringing desktop UX to the web) Javascript framework - ExtJs. Sadly, it is also big (roughly 80kb have to travel to the client first) and very buggy. It would seem that you could use ExtJS and make it use jQuery instead, perhaps that's worth a try. For now I disabled ExtJS in my little project, since I couldn't debug some of its issues. The Wt-native widgets seem to be quite solid in comparison (even if they look a bit boring).

The installation instructions that come with Wt don't tell you how to install ExtJS, so here is what I found out:

• download ExtJS framework (you probably want version 3),
• copy it into your chosen wt webroot (let's say "/var/www/wt/"), consult your CMakeCache.txt,
• extract the zip archive,
• THEN copy /var/www/wt/ext/adapter/ext/ext-base.js to /var/www/wt/ext/ (the error message when starting the web server gave that hint away),
• make sure your project is linked against the libwtext library.

Until this week I was not familiar with qmake and CMake because I am a fairly satisfied user of autotools. I have not forgotten how strange it was when I first learned it, when there was no decent documentation, but things are much better now. I feel at home with it and I like how other systems and distros expect the standard “configure;make all install” steps. I am definitely biased against the use of other build systems.

However, these days I have to deal with code that uses qmake and CMake and I can’t just be stubbornly ignorant. So I tried an experiment. I created branches of a little (but real-world) project that uses Qt and an extra library via pkg-config: qlom with qmake, and qlom with cmake. The master branch uses non-recursive autotools.

I was not impressed. Please do add comments to correct me. I’d particular like patches that make my errors crystal clear and prove that it’s all much better than I think. I am capable of admitting error and changing my mind when appropriate.

Bad Documentation. Weird Syntax

Just like autotools, neither were easy to get started with. The documentation is fragmented, unclear, and incomplete. I found qmake easier than CMake, but that’s probably just because qmake does much less. Nevertheless, CMake has a real problem with documentation and in general, as a widely-used open-source project, it deserves a better infrastructure.

They both suffer from one major problem shared by autotools: They have evolved over enough time that Google will happily return out-of-date examples and documentation, making the syntax seem more varied than it really is. I wish that autotools could force me not to use deprecated syntax. I don’t know if qmake and CMake can.

As with autotools there’s a heavy dose or arbitrariness:

• File names: autotools’s configure.ac and Makefile.am seem more logical than SomeProject.pro (qmake) or CMakeLists.txt (CMake)
• Syntax: m4 (used by autotools) is a crappy language, but at least it’s a mature one that’s used outside of autotools. I understand the wish to have no dependencies, but “invent a programming language” is always a bad design decision.
  And autotools don’t require anything but make when building from a tarball. qmake and CMake seem to require that they are installed even when building from a tarball. I would have liked to see Python used because it’s easily available on all machines that would create source tarballs.
  CMake’s non-case-sensitive function names and keywords are personally annoying to me, because I like code to have a consistent style.

No Respect For pkg-config

I am dismayed that CMake expects people to write code for “Find” modules for each library they might use, while having poor support for the generic pkg-config solution. A project’s list of dependencies is data, not an excuse to write code. More code means more problems.

In fact, after several days of trying, I still can’t figure out how to use pkg-config with cmake, so my glom_cmake branch is not finished yet.

Most libraries provide the simple .pc files these days. The autotools PKG_CHECK_MODULES() macro makes it very easy to check for several dependencies at once. CMake feels too much like the bad old 90s when we suffered fragile copy-paste-hacked config scripts, custom m4, macros and verbose build files with separate CFLAGS and LIBS variables for each dependency, and inconsistent release-version and API-version checking.

I understand that pkg-config is not popular on Windows or MacOS, and that those are awkward platforms to work with, but:

• The real solution to poor dependency information on Windows and MacOS is to encourage the use of pkg-config, so it can fix the problem there like it fixed the problem for Linux. That’s entirely possible for the cross-platform libraries that are typically open source. And pkg-config would be easy to port.
• The platform-specific libraries on Windows and MacOs don’t need any cross-platform support in the build system.

CMake’s use of scripts just spreads the chaos to Linux instead of keeping things simple on Linux and improving the other platforms too.

No Configure Stage

With qmake, I really miss having a proper configure stage, with the resulting config.h so my code can use ifdefs. I like seeing a list of documented build options from configure –help, which neither qmake or cmake offer.

CMake can generate a config.h, at least. However,

• There are no default checks, so you must specify the common stuff always, making the build file more verbose.
• You can’t just generate the config.h.in, as you can with autoheader when using autotools. There’s no reason to specify the defines in both CMakeFiles.txt/configure.ac and config.h.in.
• Arbitrarily, the config.h.in uses “#cmakedefine SOMETHING 1″ instead of #undef SOMETHING as in autotools (now deprecated, unnecessary) config.h.in files. For anything other than booleans, there’s an undocumented syntax such as #cmakedefine “@PACKAGE_NAME@”.

Install is an Afterthought

Both CMake and qmake require explicit extra syntax to actually install the built executable. With autotools you get this for free when using the regular bin_PROGRAMS to specify the executable name, though libraries do need more explicit instructions to install the correct headers in the correct place.

• With qmake, this typically means that paths are hard-coded in the build files. That way lies pain.
• With CMake, it’s easier, but you have to do “make -DCMAKE_INSTALL_PREFIX=/opt/mystuff” instead of autotool’s simpler ./configure –prefix=/opt/mystuff. autotools lists that option via “configure –help”.

Also, qmake and CMake have no make distcheck for making source tarball releases.

This makes sense slightly because CMake (and maybe qmake) aim to support Windows, Mac, and Linux equally, and Windows has no real convention for installation of built-from-source binaries. CMake (and maybe qmake) generate convenient Visual Studio and X-Code project files, for instance. But the end results it that Linux and Linux conventions are not fully supported, so they feel like major regressions compared to autotools.

(note: removed my nonsense with the TODO about the location of .o files.)

Summary

In summary, I think:

• qmake would only be used by Trolltech (now called Qt Development Frameworks) for their own projects, out of habit, or by users of Qt who are so unaware of other systems that they would just do whatever Qt’s developers recommend.
• CMake isn’t simpler, so it doesn’t solve autotool’s steep learning curve. It makes many thinks worse than autotools and its documentation is disconcertingly vague and incomplete. It’s cross-platform dependency checking adds complication without solving the real problem. The best CMake experience is probably with a large monolithic project rather than a large dependency tree of modules. But I like modularity and reuse.

I understand the wish to support Windows and Mac-specific build systems such as Visual Studio and X-Code. I just don’t like how qmake and cmake do that, and for me it’s not worth making things worse on Linux. Still, I’ll have to use these in some existing projects, so I’m glad that I’m more familiar with them now.

To me the empty home screen* of the N900 looked like an invitation, so I tried to fill it up with useless stuff as quickly as possible. The home screen configuration menu offers app launchers (shortcuts), bookmarks, widgets and contacts. Let's go through all four options in detail:

• Shortcuts: I almost always have some tasks running in the background so launching an application would usually take three to four finger touches. Therefore the app launchers are extremely helpful to me.

• Bookmarks: The idea is neat but not essential. The browser starts with a list of bookmarks anyway (how convenient).

• Desktop widgets: I never believed in them, but the calendar widget might easily change this! It shows the current day and up to five upcoming events. It's a great addition to the fantastic calendar app.

• Contact shortcuts: On this device, everything focuses on integrated contact management. For once, keeping your contacts up-to-date is actually useful and not just a time sink, simply because you can use them from almost everywhere. The logical conclusion follows: you can also add shortcuts to contacts on your home screen! It will show online status, avatar and nick of the chosen contact. Nice!

So what's on my current home screen?

• Calendar widget,
• two bookmarks,
• home ip widget,
• 12 app launchers (from top left to bottom right): settings, app manager, terminal, media player, photos, chess, notes (nice app, too), e-mail (ugly icon, and potentially confusing), IM (why does this look like an e-mail icon?!), browser, address book, phone (I had to disable the "launch when rotating" feature since phone calls would stall and eventually force me into device restarts. Too buggy for now),
• two contact shortcuts.

I know - it looks as if this was a Symbian smartphone (that is, ugly and horribly crowded). But I like it this way, at least for now =)

So what's on your current home screen?

*: I still think dashboard is a better name.

The source code of the Hildon Desktop for Maemo Fremantle including the hildon-deskop, libhildondesktop, hildon-home and hildon-status-menu components, which I worked on for the last year at Openismus, moved to a public git repository at maemo.gitorious.org. It is now easier to track the current developments or create your own modified version of the desktop for the N900.

My first chess computer

Years ago, when I was thoroughly fascinated by chess, I always wanted a portable chess computer. When I finally got one (a Novag Piccolo, for the odd chance someone else had the same device) I'd take it with me whenever possible. It got worn out quickly, moving the small plastic figures required more and more pressure to make the computer acknowledge my moves. For each move you first had to "touch" the figure you wanted to move. The computer would beep and show 2 LEDs (one for each row and line), for a lack of better feedback. Then you'd put the figure to its target location and "touch" it again, with the same feedback procedure for a valid move. If the move wasn't valid the error LED was lit. Perhaps this wasn't the best user interface in the world (I yearned for a self-moving Mephisto Phantom which actually was a Fidelity Phantom), but it worked for me and I was happy.

The problem with computer chess

The downside came when I realized there was a set of moves for each difficulty level that would always win. Later when Deep Blue won vs Garry Kasparov I lost interest in computer chess, because it seemed you could either have an imperfect machine that was boring to play (a certain set of moves would always win), or a nearly perfect machine that would bruteforce its way to victory. At least that's how the future looked to me in 1996.

Could computer chess ever be fun again?

With the N900 device lease programme from the Maemo Summit I think I finally got my very own special version of a Mephisto Phantom: The chess app that is installed by default moves "by itself" (duh ...), and with Hildon's finger touch paradigm I have a similar "board feeling" as with my old Novag Piccolo. And damn - this N900 surely is portable!

How to make it less fun

Now you would think that with an ARM Cortex-A8 it should be possible to play challenging but also fun games. But here comes the frustration again: gnuchess - the chess engine being used - comes without the opening book. Of course there might be valid reasons to not include the opening book/end game database:

• space consumption on the device (though the default opening book is pretty small),
• gnuchess is good enough to beat most players into submission
• a chess app should be more than an "opening book replay engine"

Only that chess engines are still too dumb to come up with meaningful opening moves on their own. Worse yet, gnuchess wasn't configured to randomize the outcome of its evaluation function. Which means: this device is still susceptible to the same strategy I used vs. my first chess computer nearly two decades ago!

Conclusion

The solution could of course be easy: Include the opening book and let gnuchess pick the worst move (even better: choose one randomly) from the lookup tables on easier difficulty levels, or limit how many moves into the game it is allowed to play "by the book". Also introduce random noise to force gnuchess into mistakes that are exploitable for casual players.

I will continue to play chess games with the N900. Let's try to improve the chess app though!

After spending three holidays in Amsterdam (rainy but still a wonderful time) we moved from our hotel to the Openismus apartment on the evening before the summit started. Great to see the friends/colleagues again, plus only 5 minutes of walking to the venue.

As my laptop had died directly after arriving in Amsterdam this was a good chance to test whether Modest is an acceptable replacement. I ran into three issues: Not possible to mark several messages at once as read, no threading view (really important if you get lots of Bugzilla mail and want to read the previous one), and no option to search for a message (and not just in the one message that you have selected).

Conference opening was nice. Jim Zemlin’s keynote (Linux Foundation) was a bit too much for me though, sounded like “Linux will have 101% market share next year because it’s better than everything”. Qole interviewing Ari Jaaksi had a good moment: Ari stated that having two bugtrackers does not make sense in the long run. Good to hear that common sense is shared.

I was content with my talk about the current situation of maemo.org bug management (boring slides here, video hopefully later).

Now that Nokia handed out 300 N900 pre-production devices to the folks at the summit, maemo.org Bugzilla has been flooded with new reports. Most of them have a good quality (seems like developers know that being exact in the initial description saves everybody’s time) but still it looks like more than we can currently perfectly(TM) handle so we need more help in the long run.
Let’s see how the next weeks go, especially when average users have found their way to maemo.org Bugzilla and start filing their issues. Keep in mind that for many it will be the first time to do this, hence let’s be friendly and explain some triaging decisions whenever it makes sense (”Thanks for reporting this. This has been already reported.” or “Thanks, but this is not a bug in the software itself. Please go to http://talk.maemo.org to receive help in this case.”).
As said, help is always welcome.

Photo by thp4, CC licensed

As expected, my Glom talk at the Maemo summit was rather under-attended while people went to the security talk next door. I had still hoped to do an entertaining talk for the video cameras, but my mind when blank and it was a bit of a shambles. The slides (or with notes that I forgot) should give you an idea of what I was trying to achieve.

Since then I have made some more simple improvements to the Maemo 5 port of Glom, as you can see in this new video (youtube or .ogv on my site), again using the Sqlite version of the simple Music Collection example.

These are the visible improvements:

• Details views now have “Add Related *” buttons in the AppMenu so you can actually add related records. Again, this uses an extra window.
• The Table name is mentioned on the title of the Details window.
  These last two required me to add the ability for the designer to specify the singular form of table and relationship titles. For instance, “Album” instead of “Albums”. Actually, I guess that’s still not enough for some translations, so we may need to allow designers to specify actual phrases.
• Details views now use HildonPickerButtons for ID fields instead of combo boxes. So they open a separate window to actually choose the value.
• The scrollbar is against the right edge.
• The widget spacing is more correct for Maemo 5, though there’s lots more to do, and it could be made much prettier by aligning widgets even when they are in different groups, particular because the group titles are hidden in the Maemo port.

I will stop coding on this for a while, but I think I’ve shown what’s possible. And I think I’ve shown that Glom is already (or could be) the best base for a simple database-driven application on Maemo – far preferrable to writing code and SQL.

The current code will be packaged in extras-devel soon.

I use Qt again these days in addition to gtkmm and the rest of the GNOME stuff. Things have improved lots since I last used it seriously, though it’s still a little eccentric.

Not long ago there was no public Qt bug tracker whatsoever, but now there almost is. And Qt now uses a public git repository for (most of) its ongoing work. And it’s LGPL now. Still, when there’s a real bug tracker (just use bugzilla, please) and real open development on a mailing list then I will be much happier. I hope they get there.

Successful Open Source Needs More Than Just a License

Regular Bugzilla’s such as GNOME’s or Maemo.org’s allow people to report problems, see previously-reported problems, and generally see how problems are dealt with. People can help other users and provide improvements to the software in a structured environment. Even without the aid of a bugmaster, the system gathers valuable information. You just register, login, and use it.

When the developers (or the bugmaster) are not responsive then bugzilla provides the necessary public pressure to fix things. When developers are responsive it makes users happy and loyal. Being open increases quality. Being closed hides lack of quality.

Qt’s public bug tracker is not open like that, even if you manage to find a link to it. I’ve only used it a little, but it’s been disappointing so far.

Bug Reporting Is Not Open

To file a bug you must:

• Click “Open a new Task” and fill in the resulting web form. So far so good.
• Receive an email saying “We have read your email but require more time to deal with it. We have assigned it the issue number …”. That email arrived immediately for my first bug. For my last bug report it took a couple of weeks.
• If you are lucky you will then get a real reply from the company. It might tell you that you are mistaken and kindly help you past your problem. But that information is just in your inbox, instead of available for the next person who has the problem. And you can’t disagree or reassign it as a documentation issue.

Even if you manage to get your bug accepted, there’s no “My bugs” list where you can track the progress of your issues. One of my email conversations just ended with a promise that it would be fixed, but no bug report was ever opened for that work to be tracked and confirmed.

Bug Reports are Read-Only

You can view some open (and accepted) bugs, but you can’t add any comments to them. So you can’t offer advice or a patch, or even give a clue about when to reproduce the problem. That’s a massive lost opportunity.

Bad Habits

Unfortunately, the early code-drop of the new Maemo 6 UI Framework and Homescreen shows the same old problem. There are promises to start “working openly” in the near future, and there’s reason to believe those promises. But why wait – in the meantime it’s under a license that forbids distribution or modification and there’s not the slightest suggestion of how people might provide feedback, as Michael Hasselmann noticed. “You’ll take it and like it” is not open development.

Maybe I should close comments on this bug report to make it clear how frustrating it can be.

During the Maemo Summit there were several talks about the upcoming Maemo 6 platform and also about the transition from GTK+/Hildon to Qt. One of them - the "(Introduction to the) Harmattan UI framework" also mentioned where to get the code for the Maemo 6 UI Framework from. So I went there and cloned the two available repos (tech preview of the framework, tech preview of the homescreen) together with the most recent Qt version that is also on that site.

But sadly, compiling the code wasn't possible for me. Apparantly because some header files were missing. The talk didn't mention a specific resource for feedback so I tried Maemo's Bugzilla. An e-mail to the git repo maintainer didn't yield any response (yet), either.

I reckon that my bug report on the Maemo bugtracker was filed against the wrong module (Qt on Fremantle), but where else should I post problems like that? Even if at this stage the above mentioned repos are probably not much more than a widget gallery it seems like a wasted opportunity to collect feedback, no?

Rejoice! Simon Singh wins leave to appeal in BCA libel case!

And now it begins!

Maemo Summit 2009

The Maemo Summit was fun and very productive. The organization was excellent, obviously thanks to a generous budget and a dedicated hard-working maemo.org team. I met several interesting new people with whom I hope to work closely in future.

I’m very glad that this was timed with important public announcements from Nokia, so people were actually allowed to talk to each other. And the generous loan of 300 pre-release N900s made our conversations realistic.

Nokia N900 running Maemo 5 (Fremantle)

This is the first chance I’ve had to actually use an N900 in daily life. I’m not quite the target customer, because I like tiny phones and I don’t have a flat-rate data plan, but for the past couple of years I’ve been using a N95 and then a N85 (a newer model than the N95), both Symbian S60 phones, just so I can use their good cameras to snap Liam and easily upload the pictures to Flickr.

The N900 is already vastly better for my simple uses:

• The Symbian UI is incredibly awkward, even when you discover the voodoo button presses to manage multi-tasking applications and remember all the hacks to make things work properly. The UI frequently stalls for a minute at at time.
• My N85 camera crashes/hangs on every 3rd or 4th picture, or when switching between camera and video mode. So I frequently have to do a reboot to take a picture. 2 fumbling minutes is not a good camera reaction time when photographing a speeding child. My N900 camera never crashes.
• The N85 lets me upload to Flickr easily, but then the uploads get stuck in an Outbox, that’s really hard to find. Repeated requested to “Upload Now” eventually get it onto Flickr, but it’s a tedious process and I often don’t notice that a photograph hasn’t really uploaded. My N900 uploads painlessly to Flickr, offering a quick way to tag the photos as I do so.
• The N85 still refuses to upload videos to Flickr, though Flickr has supported this for a year and a half.  My N900 uploads videos to Flickr as easily as photographs.
• Symbian doesn’t seem to have any general system-level concept of networks:
  Individual Symbian applications often have their own network settings, so, for instance, an application will often do one of the following:

• Ask you to choose an internet connection, though you are already connected.
• Just complain that it can’t connect at all, though you are already connected. In these cases it’s generally trying to connect to some wireless network that’s hundreds of miles away.
  This seems to be improving with each (infrequent) Symbian update – for instance the Flickr updater now seems to use the already-connected network, though it’s hard to know because of the Outbox problems mentioned above.

My N900 and its applications don’t have these network problems.

As well as solving these daily frustrations, the N900 has an amazing address book, which ends up being the main starting point for all communication. It brings all my SIM/phone, GoogleTalk, Jabber, Skype, SIP, and ovi.com chat contacts together in one list, allowing me to merge them together. Its use of the Telepathy framework means that even more backends will be added later – you can add some now though you risk breaking your phone by using unstable software. I do miss syncing contacts to ovi.com, though I feel sure that the feature will be added. This allows me to communicate easily with my friends via several methods, without using multiple fragmented applications when jumping between SMS or IM.

And those conversations (even SMS) are actually presented as individual conversations, instead of just a jumble of messages in an inbox. It’s great to see the conversation’s history when writing a new message.

I generally find that the Symbian phones don’t warn you when they are using the expensive 3G data connection , though this is again dependent on the application rather than being a system-level thing. I have not yet allowed my N900 to use the 3G connection, so I can’t say if it’s better. I anticipate that the use of a real operating system (Linux) can make this manageable. Unfortunately, network operators don’t want to help users with this. At some point they might realize that cheating customers is not a good strategy.

Less buggy, and bugs can be reported

I’ve found a few bugs – after all, this is not the final stable software. But even this pre-release is far less buggy than my awful Symbian phones. As a developer, I believe that Linux and its commonly-used tools has made this possible, though software development remains incredibly difficult for even the best people on any platform.

Best of all, I can report the bugs at bugs.maemo.org and track their progress. For Symbian, all I can do is whine on my blog. People like companies that listen to their needs instead of hiding from their customers. André will be swamped by new feedback – don’t try this without a bugmaster.

If it’s a hardware failure, why does it strike twice in a row at 6 AM? If the four NIC goes bonkers, why is that related to the sound card? If it is a bus, why does a freaking centimeter make a difference?

I don’t know.

All I do know is, that I am back online. Different four NIC, different slot, minus sound card. So what the hell is really failing here? The four NIC, the sound card, the board — or a combination thereof?

Definitely a combination. Something died, something is about to die.

I am online. For the moment.

So I am back from Maemo Summit 2009. Great people. Great show. Great talks. Great venue: Enjoyed it quite much to walk arround in the Westerpark, Marc-André loved the petting zoo.

Hotest topic, of course: The N900. Thank you Nokia for lending those devices: Feels so good to finally have one for personal use! Finally got ideas for some private N900 hacking when reflecting responses to Travis' and my talk.

Another hot topic was DRM on Harmattan. Fortunately David Greaves came to similar conclusions like I've reached so far: Maemo Security - Lockdown or Liberation. Could be I'm just a weirdo, but I seriously hope for game developers targeting Maemo: Already called Rover "My next Wii" in jokes for its nice screen and the acceleration sensor.

Well, and then there still was this disappointment about Nokia moving to Qt as their prefered UI toolkit. Actually I wonder why people see this as problem: GTK+ was created without Microsoft or IBM holding our hands, so why does everyone expect Nokia to hold our hands for Maemo? If we really care about this platform, it should be absolutely possible for us to provide a proper GTK+ based toolkit for Maemo 6. Ideally Nokia would publish Layout guides and stuff early, so that we would not have to play catchup too much after device launch. Motivation and specs. More should not be needed. Really.

Here is a quick video (youtube,or .ogv on murrayc.com) showing the initial port of Glom for Maemo 5 as I navigate through the simple Music Collection example. Remember,  viewing and navigation are just a tiny part of Glom’s functionality. More imporantly, remember that the database designer would have implemented this little system (structure and UI) with no code and no SQL.

I wanted to get this much done so I could talk more confidently about Glom during my presentation at the Maemo Summit on Sunday.

This is also a more extensive test of the maemomm C++ bindings, which David King will do a talk about on Saturday. Maemomm is somewhere between Hildon (C, GTK+, extras) and Harmattan (C++, Qt, extras) in the current sea of programming languages and toolkits.

(Sorry if some planet’s are showing HTML code here instead of the video. I don’t know why. Try the links above instead.)

This is not a complete port, of course. There are some obvious problems. For instance, the + button in the list view should be a button in the main AppMenu. And on the details views:

• The window title should show the table title, just as it does for list views.
• Combo boxes should be HildonPicker buttons.
• The “Songs” frame label has some strange new format. I must investigate if that’s now normal in Maemo 5.
• Hiding the group titles makes the lack of alignment across groups even more obvious.
• I must find out if we can use PannableArea while still allowing the widgets to be edited, instead of using a ScrolledWindow. At the least, we should use a wide scrollbar.
• The + button should go into the AppMenu. There would be one “Add *” button for each related records portal on the layout.
• The AppMenu should also have a Delete button when showing Details.
• The spacing should be fixed now that the Mameo UI guide has been published.

I should do some videos for the regular desktop version of Glom to give people an idea of what it can do.

I have been learning Qt at Openismus for a while, and recently started playing with the Maemo port. The result so far is Qlom, a Glom database viewer:


While Glom is a Gtkmm application, it has a non-UI library component called libglom, which I have used from within Qt to deal with all the Glom document-parsing. It was interesting to find out that Qt uses the Glib main loop, which made everything a lot easier. I had to use Qt built from git in order to get the Maemo theming shown above, and some widgets are still not themed correctly, but hopefully this will improve with future releases against the final SDK.

I will be presenting a talk at the Maemo Summit in Amsterdam on Saturday, at 12:00 in the N800 room. The talk is titled "Maemomm: Maemo with C++ and a Gtkmm flavour", where I will discuss the C++ bindings for Maemo Fremantle, which I have also worked on at Openismus. There will even be some comparisons with Qt…

It’s the beginning of October and one year ago I started working fulltime as maemo.org Bugmaster (after I had started together with Karsten in May 2008).
Where are we and what are the plans?

Stats

On 29 Sep 2008 there were 1076 open tickets (including Website). Now there are 658 open tickets (including Websites, excluding Extras). That of course does not mean that difference of 418 tickets has all been FIXED (some reports became WONTFIX or got closed due to lack of response of the reporters when asking for more information), but it shows that there’s activity, feedback and that reporters can expect that somebody cares about their issue.

In the last 12 months 1501 reports have been filed (including 3rd party Extras apps, without it’s only 651). That’s normal average (10/2007–09/2008: 1690; 10/2006–09/2007: 1269). Curious what the number for the next 12 months will be though.

Nokia

What has only improved a bit is getting Nokia developers to work in the community instead of with the community. Big thanks to those trying it already.
It’s the Nokia management that has to allocate developers’ time for this, and it’s the community that has to convince with arguments why it’s better for everybody (simply imagine managers and developers used to commercial closed source development, e.g. the S60 series). I won’t elaborate in this paragraph; in short: I do hope to see improvement here after Fremantle (Maemo5) launch and by having some discussions at the upcoming Maemo Summit.

Misc

• We’ve opened Bugzilla to also provide bugtracking for some 3rd party applications hosted in the maemo.org Extras repository.
• At the end of last year the structure of the products and components was reorganized to better match user expectations (”Hmm, where should I file my issue?”) plus also the organization of internal Nokia developer teams. That was a bit like trying to square the circle but I think that the compromise is pretty good.
• Additional to Stephen’s awesome weekly Maemo Bug Jars I started providing a monthly Feature Jar that only covers the enhancement requests in Bugzilla, published on the maemo.org mailing lists and in talk.maemo.org. It’s based on the votes for each request, so if you have a application-specific wishlist item that is an affair of the heart to you go vote for it in Bugzilla (if it’s platform-wide it’s better suited to file it in the maemo.org Brainstorm).

Future

• Planning the changes required for Fremantle (adding new products, changing some descriptions etc) is basically finished. Next is to add all this and set it up once the final Fremantle version is available.
• Porting the Bugzilla codebase to upstream 3.4 version – ongoing (currently working on CSS). Ferenc has been a huge help codewise so far. I owe him quite some beers.
• Regular bugdays. See next paragraph.

Bugsquad

I’ve already blogged about changes and expectations related to the N900 launch. One more thing that I’d like to add: After the N900 launch I want to start having monthly bugdays – the maemo.org Bugsquad is a great way for people that want to get involved but don’t necessarily want or know how to code. Bugsquads constantly need fresh blood as they always tend to “lose” members to the evil, evil codewriters fraction.

You

So what are your impressions and expectations with regard to maemo.org Bugzilla?

(Picture by Dženan Šehić, CC licensed)

Exactly 20 years ago the West German foreign minister announced that the thousands of East German refugees were allowed to leave the Prague Embassy to West Germany.

The video (click here if the embedded version does not work) still moves me to tears and reminds me that freedom is not made up principally of privileges, but it is made up especially of duties.

Finally, got myself a floating head. Woot! Yes, that’s me on the left (or right, depending where you actually read this).

After being physically maltreated to get some decent pictures taken to work with, getting nicened-up, re-assembled and undergoing other unspeakable treatment — it is done. Thanks a ton to the artist, a close friend of mine.

Oh, and yeah, unlike most pictures of me, I actually like my little hackergotchi.

You can find it live right next to my posts on Planet GNOME, Planet Openismus, as well as statically on my blog’s main site.

I just released Glom 1.12, roughly in-sync with GNOME’s release schedule.

Most noticeably, Glom databases no longer require a user/password to open them, at least for the default self-hosted databases. That should be much less annoying. You’ll only need to specify a user and password when you choose to share your database over the network with other Glom users.

We’ve also cleaned up libglom a bit, and David King has shown that it can be used for a simple Qt-based Glom viewer, provisionally called qlom.

I’m currently working on a Maemo 5 (Fremantle) branch of Glom, with a radically simpler UI with picker buttons and more sub-windows. I need to get that mostly done so I have something for my Handheld Glom talk at the Maemo summit in Amsterdam. I’m planning some rants for that talk – I think it will be entertaining.

Just came back from the wonderful Vypsaná fixa album release party to see that there is yet another great GNOME major release available. Go check out the improvements and changes! Made to share!

Work on GNOME 3 is ongoing, of course.

(Picture by padro82, CC licensed)

From time to time applications need custom theming rules. Especially when the project has professional UI designers involved. So how to achieve this with GTK+?

Trivial Theming

Most easy and very wrong:

if (gdk_color_parse ("pink", &color))
    gtk_widget_modify_bg (widget, GTK_STATE_NORMAL, &color);

This will break and look childish as soon as your users use a custom color scheme.

Better:

static void
style_set_cb (GtkWidget *widget,
              GtkStyle *old_style)
{
    GtkStyle *style = gtk_widget_get_style (widget);

    if (gtk_style_lookup_color (style, "SecondaryTextColor", &color))
        gtk_widget_modify_bg (widget, GTK_STATE_NORMAL, &color);
}

static void
my_widget_init (MyWidget *widget)
{
    g_signal_connect (widget, "style-set", G_CALLBACK (style_set_cb), NULL);
}

This will allow theme designers to override your color choice. Notice that you'll have to update those color overrides when the theme changes. Btw, the "style-set" signal is emitted when the widget is realized, therefore you don't have to manually invoke the callback during widget construction.

Guess it's also worth to mention that Hildon provides convenience API for simple theming requirements.

Complex Problems

So for simple requirements GTK+ (and Hildon) have reasonable API support. Things become troublesome when your designers invent rules like "this widget has a rounded border and drop shadow, but only within buttons". Obviously border and drop shadow radius should be themeable and therefore are implemented as style properties, but how to impose this rule?

You could scan the widget hierarchy when choosing default values for your style properties:

button = gtk_widget_get_ancestor (widget, GTK_TYPE_BUTTON);
gtk_widget_style_get (widget, "border-radius", &border_radius, NULL);

if (button)
    border_radius = (button ? 12 : 0);

You'll quickly notice the flawed hard coded default value. Also such things are hard to override in theme files. So it's probably better to apply a custom theming rule via gtk_rc_parse_string():

static void
my_widget_class_init (MyWidgetClass *class)
{
    ...
    gtk_rc_parse_string
        ("style 'my-widget-style-clickable' {"
         "    MyWidget::border-radius = 2"
         "}"
         "widget_class '*.<GtkButton>.MyWidget'"
         "style 'my-widget-style-clickable''");
    ...
}

Application Theme Files

Looks like a perfect solution, until you realize that this rule is applied after all rules loaded from gtkrc files!

So how to inject this rule before the user's theming rules? This was a big question to me until I've found gtk_rc_add_default_file(). Well almost: This function only adds files to the end of the search path. Therefore it suffers from the same issues as gtk_rc_parse_string(). Fortunately the API author was smart enough to also provide gtk_rc_get_default_files() and gtk_rc_set_default_files(). Those functions can be used to apply application specific theming rules, which can be overwritten by the user - drum roll please:

static void
inject_rc_file (const char *filename)
{
    char **system_rc_files, **p;
    GPtrArray *custom_rc_files;

    system_rc_files = gtk_rc_get_default_files ();
    custom_rc_files = g_ptr_array_new ();

    g_ptr_array_add (custom_rc_files, g_strdup (filename));

    for (p = system_rc_files; *p; ++p)
            g_ptr_array_add (custom_rc_files, g_strdup (*p));

    g_ptr_array_add (custom_rc_files, NULL);

    gtk_rc_set_default_files ((gpointer) custom_rc_files->pdata);
    g_strfreev ((gpointer) g_ptr_array_free (custom_rc_files, FALSE));
}

int
main (int argc,
      char **argv)
{
    ...
    inject_rc_file (PKGDATADIR "/gtkrc." PACKAGE);
    gtk_init (&argc, &argv);
    ...
}

Update: Benjamin Berg just pointed out that priorities can be assigned to styles. So the following should work fine:

gtk_rc_parse_string
    ("style 'my-widget-style-clickable' {"
     " MyWidget::border-radius = 2"
     "}"
     "widget_class '*.<GtkButton>.MyWidget'"
     "style : lowest 'my-widget-style-clickable''");

Awesome, little know feature.

Barack Obama on CNN: "We can't go back to the era where the Chinese or the Germans or other countries just are selling everything to us, we're taking out a bunch of credit card debt or home equity loans, but we're not selling anything to them".

Found this quote when searching for stories supporting Financial Times Deutschland's story about US and UK officials having tried to establish trade penalties for export nations like China, Germany and Japan during the Pittsburg G20 summit. Either that story is just wrong, or US and UK turned into communistic dictatorships when I was sleeping under some rock. On the other hand FTD is considered one of the more reliable papers. At least Reuters seems to confirm the FTD story.

So what's about "just" fixing your industries and producing desirable products again? Weren't US and UK usually the first with praising capitalism, competition, challenges? High wages cannot be the reason for your trade problems: German and Japanese industry workers are well paid.

Well, now trying to calm down again.

Just a quick note about a little-used feature of GNU Autoconf: site defaults.

Until recently, I used to have a long list of assignments to module_autogenargs['...'] in my ~/.jhbuildrc file to set up default configure options for various modules. This became unwieldy and there was always one module I forgot.

Autoconf comes to the rescue with its support for site defaults. For illustration, here is my ${prefix}/etc/config.site file:

The effect is as if I had passed --enable-silent-rules --disable-static --enable-warnings=fatal to every module’s ./autogen.sh, except that I don’t get any annoying warnings if a module doesn’t actually support a particular option. The test conditionals ensure that command-line arguments have precedence over the default values in the config.site file.

Read the manual for the gory details, if you want to. Otherwise, enjoy!

Error handling (or god forbid, exception handling) is one of the weak parts in Squeak. A great deal of course comes from its dynamically typed nature. However, the greater impact probably comes from the utter lack of guard clauses in most core librares I've seen so far: Objects will happily accept any kind of parameter and continue to wrack havoc on them until the debugger, at some later point (IF we are lucky), stops the travesty.

Let's move on to BitBlits, where the lack of parameter checking and the absence of proper initialization quickly crashes your VM. Why use BitBlits at all? Because Morphics are crap. More precisely, they feature:

1. poor performance (I guess all the redrawing with overlapping Morphic instances doesn't come for free),
2. a hideously complex class hierarchy
3. undocumented models (say, the model for PluggableListMorph)
4. a hard-to-access event loop (read: no ready-made support for signals & slots),
5. a complex API (only for the base class Morph itself "Morph methodDictionary size" returns 1165 methods, yikes).

Naturally, while using BitBlits or Forms most work is actually done by Squeak primitives, that is, external C code that is called by some Squeak wrappers. At this point proper argument checking becomes paramount, or else:

• Division by zero (3.10, win32/linux)

  | blit form |
  
  form := Form new.
  "form setExtent: 0@0 depth: 32."
  blit := (BitBlt destForm: form
                  sourceForm: nil
                  halftoneForm: nil
                  combinationRule: Form blend
                  destOrigin: 0@0
                  sourceOrigin: 0@0
                  extent: 0@0
                  clipRect: (0@0 extent: 0@0)).
  blit copyBits.
  

Note the out-commented line, which would prevent the VM crash. Appearantly the form's depth isn't initialized. The funny part starts when you replace "destForm: form" with "destForm: Object new", which triggers the proper error handling and prevents the VM crash as well.

• The magic bitmap (3.10, linux-only)

  picture := Form fromBMPFileNamed: 'bigbitmap.bmp'.
  

The comment at the top of this method reads "deprecated". Sadly, bitmaps are much faster than any compressed image format, even after the initial reading (oops?). More importantly though is that we have different behaviour (crash/no crash) depending on the platform where this is executed. Wait a moment - a VM? Platform-dependant? Actually, this is not the only example, many Form methods will not work with the Linux VM. But instead of telling you, they'll happily crash the VM, too.

(Get the magic bitmap here.)

Oh well, at least Squeak is good when it comes to runtime optimizations, like any other VM. And loop unrolling is so basic it is hardly worth to test it. Or is it?

• Let's try a simple loop, with the inner loop manually unrolled (add:to: adds arg2 to arg1 and stores the result in a member):

  MessageTally spyOn: [
      (1 to: 10000)
          do: [:unused |
  
              self add: 1 to: 1.
              self add: 2 to: 2.
              self add: 3 to: 3.
          ].
  ].
  

This executes in 4ms on my machine.

• OK, now outer loop & inner loop:

  MessageTally spyOn: [
      (1 to: 10000)
          do: [:unused |
  
              (1 to: 3)
                  do: [:idx |
  
                      self add: idx to: idx.
                  ].
          ].
  ].
  

WTF?! 17ms? Well, one quick optimization is to store the range (interval) of the inner loop like so: innerLoop := 1 to: 3.

• The code then becomes:

  | innerLoop |
  
  MessageTally spyOn: [
      innerLoop := 1 to: 3.
      (1 to: 10000)
          do: [:unused |
  
              (innerLoop)
                  do: [:idx |
  
                      self add: idx to: idx.
                  ].
          ].
  ].
  

+1 for everything (but variables) is an object, -1 for code obfuscation, +1 for getting execution time down to 12ms. But still. WTF?!? Does the code really spend 8 precious milliseconds in the loop variable handling (with other words, 67% of the execution time)?

(My personal) conclusion: Squeak fails at getting basic stuff right. The things it gets right (reflection/introspection, fast development round-trips) are fantastic! But it suffers from a big NIH syndrome so that instead of wrapping useful and established libraries you are left alone with an incomprehensible "self-documenting" class library. Also, wrapping C libraries using the foreign function interface seemingly requires recompilation of the VM ... platform independence, anyone?

I'd welcome comments correcting my perception problems with Squeak!

We got a couple of BeagleBoards at the office a while ago, and have been playing with them a lot. As low-powered Linux-running devices they are quite fun, and being a completely different architecture brings some interesting problems. However, there is lots of active development to improve the support, both from the kernel and userspace. There are several distributions and toolchains that can be used, and the setup is relatively painless.

To make it easier, we have written a guide on Getting started with the BeagleBoard, based on our experiences. We would be grateful for any comments or suggestions, enjoy!

After more than a month of infrastructure work, most of the GNOME C++ binding documentation has now been migrated to the GNOME Documentation Library. This includes the Programming with gtkmm guide and the Doxygen API reference documentation of the core C++ binding modules. Compared to the old documentation hosted on the gtkmm website, we’ve now got a bigger pipe, more bling, and less work for us!

All this would not have been possible without the help of Frédéric Péters, who did the actual integration work in the library-web module and has been very responsive to our numerous questions and tweak requests.

Leading up to the migration, the build infrastructure of the GNOME C++ bindings was completely restructured. All the copy’n'paste of build files had degenerated into an unmaintainable mess. When it became clear that we lacked the infrastructure to properly support cross-references from one documentation module to another, I began to cook up something new to replace the mess. The result of this work is the new mm-common module, which provides the shared build support files for the C++ binding modules. As a novelty, it even comes with documentation!

It is quite a bit of work to convert an existing module to use mm-common, and the transition took more time than I had expected. Despite that, the feedback was very positive, and a number of module maintainers started to convert their modules to mm-common on their own. Many thanks to David King, Fabien Parent, Jonathon Jongsma, José Alburquerque, Krzesimir Nowak and Murray Cumming for your work and feedback!

Today, Kat and I went to Meister Camera in order to watch the Leica 09/09/09 announcement. I was a bit worried that I would feel out of place with all the people that might actually be able to afford a new camera(!), but it was pretty fun. We knew what the announcement would say, with the recent leaks and vigorous forum discussion, but it was still fun to watch, with a special appearence by Seal. Afterwards, we got to play with both the M9 and the X1, which I was more excited by than the M9. An SLR-sized sensor in a compact camera body, with manual controls and a great 35 mm-equivalent lens. Still, it's a bit too expensive.

Playing with the M9 was pretty fun, and a lot of guys there seemed quite interested in how well the full-frame sensor worked with the wide-angle Tri-Elmar that I had with me. Reassuringly, it worked great, without the need for an IR filter! Testing with a 50/1.4 ASPH was really fun too, especially as it was the black paint LHSA version. Once I'd finished drooling over the ludicrously expensive limited-edition cameras and lenses (including the white M8), we decided to buy an expensive lens cap, and got chatting to a nice Leica collector from Berlin, and lots of others who were both excited and looking knowingly at their wallets. I think that I will have to settle for the lens cap, but I can still dream!