Openismus Blogs

Daniel Elstner: Bjarne Stroupstrup on C++0x

Thu, 18 Mar 2010 12:09:54 +0000

I’m just back from Aalto University School of Science and Technology in Espoo, Finland, where I attended Bjarne Stroustrup’s roadshow talk on C++0x. In the talk, Stroustrup provided a very nice overview of the features in the C++ standard and how they fit into the evolution of the C++ programming language.

Bjarne Stroustrup made the impression of a down-to-earth guy with a very healthy attitude about C++ features and their development. I was excited to learn that the C++0x draft standard had just been declared final the week before. That means the content of the standard is de-facto finished now, and it will be formalized as an ISO standard in about one year. There sure are quite a number of nice goodies in C++0x, I can’t wait to get my hands dirty on code using it.

For the C++ groupies among us, I took photographs of all presentation slides and of course also of Bjarne Stroustrup himself.

Mathias Hasselmann: QML Hype

Thu, 18 Mar 2010 10:24:35 +0000

So yesterday I've skipped the chance to watch some "exciting" QML demos in Helsinki. This was quite surprising to some of my KDE rooted team mates. They didn't understand how I could not show the slightest sign of excitement.

Well, but actually I wonder for months: What's actually the fancy and awesome, the brilliant new, the exciting part of QML? It doesn't seem to be rocket science. It's nothing new. Declarative UIs are done for ages. To name some very few implementations there are Windows and PM/Shell RC files, Glade, GtkBuilder. You want to mix declarations with managed code? XUL and XAML have visited that land. You want to use JavaScript for your UIs? Flash, XUL, Dynamic HTML and Web Widgets, GObject Introspection.

So what am I missing except that Qt finally catches up to its competition? It's a welcome addition, but why should I be overly excited and die of excitement?

Daniel Borgmann: ubuntu-theme-tweak

Mon, 15 Mar 2010 19:44:11 +0000

One thing that I often missed in GNOME development is an easy way to apply glow and shadow effects to any kind of element. The most obvious kind of this is the lack of a built-in method to render text shadows. Selectively used in almost every single designer’s mockup, the lack of it in actual implementations has been one reason why the result is rarely as satisfying as it could be.

While some people have stated the opinion that they do not like text shadows, and they can easily be overused, this is not an excuse to make it harder than a single line of code (or CSS!) to implement them. Creating text twice is not a good solution. Despite the awkwardness of the implementation, it is also inefficient, and the reason why this approach was discarded for Maemo 5.

To give a few examples of the importance of text shadows (and glow) in modern UI design:

(Click to enlarge)

WebKit got this covered, why haven’t we? This should be well supported throughout the platform. Where and when to actually use it should not at all be a question that depends on technical issues.

Text shadows are only the tip of the iceberg though. In particular shadows and glow effects are extremely powerful and flexible assets in any GUI designer’s toolkit. We should have utility functions easily available for these effects, as well as the obvious rounded borders and multi-step gradients.

GNOME Shell is certainly on the right track, with their fairly flexible CSS styling, but many of these elements are still missing. This leads to issues like Bug 581067. If the designer wants a glow, she should be getting a glow. Something as elemental as this just shouldn’t require any significant programming effort. I am confident that GNOME Shell will get there, it’s just something to keep in mind (i.e. once the effect is implemented once, make it easily available via CSS).

Classy Gradients

Another common eye-sore is the way we utilise gradients. A rule of thumb should be: Unless the gradient is used to indicate an obviously rounded surface, the gradient should not actually be visible to the naked eye. Gradients are excellent to add sophistication to an otherwise flat surface by simulating the natural distribution of light, but gradients in itself are by and large just not an attractive design element.

Consider the new Ubuntu theme. The gradient in the panel is pretty good. Oddly enough the gradient in the titlebars is much different. While in itself it is still acceptable (due to the slight illusion of glossiness), the added menubar completely ruins it. Of course that is ultimately a symptom of the larger issue that is the separation between window frame and application (hopefully soon solved by client side decorations), but there is certainly an argument for rather not doing something than to do it badly. Also unnecessarily exaggerated is the gradient of the title button tray.

The straight-forward application of the concepts above would result in something like this:

(Yes, it’s far from perfect, but I hope it illustrates some points. I also forgot to colour the title and menu text)

What I mainly hoped to accomplish with this is to create some discussion about how we can make these things easier to do for designers and developers, and where to add these capabilities in the stack (Cairo? Pango? A graphic styles library? Gtk?). I would want to work on this.

Also, what is our answer for rich application UIs? When Webkit beats us in capabilities for desktop application UIs, something is clearly amiss.

Peter Penz: Git

Thu, 11 Mar 2010 17:24:46 +0000

The question which version control system is "the best", is often the base for endless discussions. I'm quite pragmatic in this regard: I've used Rational Clearcase during the last 9 years and worked with CVS and Subversion during the last 4 years. From my experience the acceptance of a version control system depends a lot on how it matches to the software development workflow of a company/community.

Personally I prefer the straight forward approach of Subversion over the (technically) powerful Clearcase. Still Subversion is cumbersome when working with temporary development branches and I was curious when I heard about the concepts used in Git. After reading about Git I thought that it unites the benefits of Clearcase and Subversion without introducing any drawbacks.

At Openismus I got the chance to work with Git on a real project. The first impression was ambivalent: On one hand Git is extremely powerful, fast and does not limit the developer how to work with branches or doing merges. On the other hand the learning curve is higher than expected and it requires a different mind set in comparison to centralized version control systems. Because of the huge amount of new possibilities a ruleset for projects using git is highly recommended. Git reminds me to C++: You can do wonderful things with it in a clever way, but it's very easy to shoot oneself in the foot.

I still need to learn a lot about Git, but after a few weeks of working with it I already prefer it over Subversion a lot. More and more projects switch to Git, so this does seem to be a common experience.

Murray Cumming: What our Trainees Learn

Tue, 09 Mar 2010 14:46:44 +0000

After our successful year of training at Openismus, I thought I’d publish the rough bullet-point list that we used. Whoever we choose for the following year will repeat much the same process, with in-depth critique and a dose of reality.

These were our overall aims:

Familiarity with the programming languages, toolkits, and tools, beyond the average.
Good quality habits – documentation, ChangeLogs/commit-messages, bug filing, simple code.
Good communication – politeness, precision, knowing who/where to contact, tracking progress and following up.

And this is the stuff that we checked off along the way:

Knowledge of C

Respect for memory. True understanding of pointers.
- Understanding of the many ways to use * and & and [], declaring and dereferencing.
- Understanding of state (Such as a widget’s data, or a user_data struct, or a C++ class’s member variables.)
- Understanding function pointers, including their weird syntax, made easier by use of typedefs.
Basic understanding of object-orientation – Write functions that have a namespaced prefix and that take a first self/this parameter.
- Write init and free functions where appropriate.
- Don’t use a prefix that is used by an existing library.
Use of enums (or defines if necessary, or static constants if appropriate) instead of magic numbers/strings.
Breaking code up into small blocks, separated by empty lines, with pseudo-code comments above each block. In small functions, of course.
Initializing local variables, even if you don’t think it’s necessary.
The GTK+ coding style, which is common for C.

Knowledge of GTK+

Familiarity with GTK+, to the level of implementing new widgets.

Reference-counting: Conventions and special cases (gstreamer and tinymail use a different convention, for instance).
Child widgets don’t really use reference-counting. They are destroyed by parents regardless.
Glade and GtkBuilder
Implement a new widget, doing some custom drawing and/or containing some child widgets. Make sure that you understand what the various construct/init/finalize/destroy/etc vfuncs do.

Other C stuff and basic tools

Tools: gdb, valgrind, svn, git, diff, patch.
Writing ChangeLog entries or commit messages (mentioning files and functions, and what changed in them and why).
autotools
gtk-doc syntax, and knowing what developers need to see in the documentation. Mention the what, when, why, how, and “see also”.
Familiarity with Clutter, to the level of implementing new actors. See the Openismus Clutter tutorial.
Fix some GNOME bugs, submitting patches. Maybe work with the gnome-love group.

Communication

Join the relevant GTK+, GNOME, Maemo, and Qt mailing lists.
Add Openismus employees to your GNOME bugzilla Users To Watch list. Someone will watch yours too.
Be repeatedly told to file bugs and patches, and to follow up on them. File bugs about documentation too.

Familiarity with C++ – at least the parts used by gtkmm and Qt

This takes more time than anything else, but its doable with motivation and mentoring from our experts.

Read a full book, such as Accelerated C++, cover to cover.
Understanding of classes, constructors, inheritance, polymorphism.
Understanding of references.
Understanding of const and mutable.
Templates. And template specializations.
Use of std containers.
Familiarity with gtkmm (easy because they know GTK+ already.)
The gtkmm coding style, which is common for C++.
The doxygen/javadoc syntax.
Wrap some new GTK+ API for gtkmm.
Fix a Glom bug. For instance, there are some simple Glom gnome-love bugs.
Familiarity with Qt. Understand what moc does. Do something real-world with it’s (quasi) model/view widgets. Understand QString historical oddities.
Maybe find a bug to fix in KDE.

Optimization work

Understanding processing, memory, and IO costs.
Avoiding premature optimization while avoiding obvious performance errors.
Using Oprofile, SysProf, system tap, etc.

Debian/Ubuntu packaging

Package a new version of an existing package, such as Glom, in the Openismus PPA.
Package something new for Ubuntu.

Embedded Linux

Use of Scratchbox with Maemo.
- Port something to Maemo.
- Package it for maemo-extras.
Using a BeagleBoard:
- Set up the BeagleBoard and get something running.
- Try to install Mer.
- Putting a self-built distro on generic hardware (BeagleBoard), using Poky or OpenEmbedded.
Be aware of differences/pros/cons between Poky and OpenEmbedded.
Document how a customer might prepare and maintain a custom debian (or Ubuntu) distro for their embedded hardware project. For instance, how to install and use an autobuilder for packages.

André Klapper: maemo.org Bugday: March 16th, 18:00-03:00 UTC.

Mon, 08 Mar 2010 18:02:41 +0000

Announcing another maemo.org Bugday:

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

No specific topic set – see the wiki for some ideas.

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. Step by and say hello to the Bugsquad or become part of it.

Murray Cumming: Openismus Wants More Trainees

Fri, 05 Mar 2010 17:26:22 +0000

A little over a year ago, we hired our first batch of Openismus trainees. After an intensive year gaining knowledge and experience, I’m proud to say that David King and Michael Hasselmann have now graduated to regular work on customer projects. They’ve become solid developers in whom we have confidence, thanks to mentoring from all our other employees. Personally, creating these new development careers is one of the most worthwhile things I’ve done in my career.

So we need some more people to repeat our success. Here’s the text from the first time:

If you are smart and enthusiastic but you lack experience then we can provide the opportunity. You would work mostly on existing open source projects instead of customer projects, just to get experience with C, C++, GTK+ and Qt. Our developers would provide technical guidance and encourage you to work and communicate in a structured way, creating software that’s actually usable and useful.

This is also a great opportunity to move to Berlin – a wonderful city for young people. Munich may also be a possibility if necessary.

I’d also like to point out that we are very much an equal-opportunities employer. We get almost no applications from women or minority groups and that’s not good enough. We are a small company so every new person can make the place more like themselves.

Please send us an email telling us about yourself. Show enthusiasm and show us anything you’ve done in the open source world already. As before, I will filter out the least suitable candidates by expecting you to find the appropriate email address yourself. Unfortunately, as before, it’s unlikely that we’ll want to deal with visa paperwork if you are not already working in the EU.

Peter Penz: Packaging

Fri, 05 Mar 2010 07:43:41 +0000

Before I joined Openismus, I never created RPM- or Debian-package for my sources. After releasing an early version of the Dolphin sources at www.kde-apps.org, friendly people stepped up and created RPM- or Debian-packages for them. When Dolphin got part of KDE, the packaging anyhow was no problem anymore as it had been done by the Linux distributions.

At Openismus one of my first tasks was the prepare Debian packages for Glom and the Qt frontend Qlom. Beside preparing packages for Ubuntu Karmic, also packages for Maemo had to be created.

I always thought developing software can be tricky, but now I know that creating a package is also very challenging and requires a very focused style of working. As there are many traps for beginners, I'd like to provide some useful links that helped me to fulfill this task (beside the help of my colleagues at Openismus of course):

Debian New Maintainers' Guide: Is a must-read if you need to create a package from scratch.

Building Modified Debian Packages: Provides a good overview for the case where a source package is available, which should be updated by some patches.

Creating Debian Packages for Maemo: When creating a Debian package for Maemo, some things from the Debian New Maintainer's guide can be skipped, other additional steps are required. Beside step by step instructions to create a Maemo package from scratch, the differences to a default Debian package are explained well there.

Still there is a lot of room to fail at the beginning. There have been some traps I fell into and I'd like to summarize them as long as I can remember them:

Don't modify a decompressed version of a file that is part of the *.orig.tar.gz file, without updating the *.orig.tar.gz. This sounds (and is) obvious, but it is easy to fall into this trap when modifying e. g. a configure.ac file for testing. The result of doing such changes is that the local installation of the generated package might behave different in comparison to the official package created by a PPA.

Beside the build dependencies take care to verify the runtime dependencies. It is easy to forget this, as the local system most probably will already contain the needed packages.

Daniel Elstner: Why I hate Qt

Thu, 25 Feb 2010 17:21:27 +0000

Although I’m a GNOME and gtkmm guy, my paid work involves Qt. It’s no secret that I have a very strong antipathy towards the Qt mania to assimilate everything into their framework, the culture of their community, and their nonchalant abuse of the C++ programming language. Often, people suggest that I’m exaggerating the faults of Qt, and that there are much worse alternatives out there. Fair enough.

But today I happened onto another one of those little inanities which so often add up to a huge stinking pile. I decided to share this particular example, as I think it may help people to understand why I’m feeling so strongly about Qt.

A while ago, I filed Qt bug #5732, together with a patch to fix the problem. In addition to the fix for the central problem reported in the bug, I also provided a second patch to correct another problem I stumbled upon while I worked on the actual bug fix. The bug was acknowledged by a Qt developer and the code got fixed. They decided to fix it their own way instead of applying my patch, which is fair enough. I may not have agreed with the way it was implemented, but the problem I reported was fixed.

Today, I again looked at the Qt OpenGL code, and happened to stumble upon the OpenGL extension checks. Apparently, the extension checking had now finally been factored out into a separate class, with a more efficient implementation to avoid the numerous temporary memory allocations of the string splitting method that was used before. Of course I was curious and had a look at the code which implements the string parsing.

Here is how it looks like:

// This class can be used to match GL extensions without doing any mallocs. The

// class assumes that the GL extension string ends with a space character,

// which it should do on all conformant platforms. Create the object and pass

// in a pointer to the extension string, then call match() on each extension

// that should be matched. The match() function takes the extension name

// *without* the terminating space character as input.

class QGLExtensionMatcher

{

public:

QGLExtensionMatcher(const char *str)

: gl_extensions(str), gl_extensions_length(qstrlen(str))

{}

bool match(const char *str) {

int str_length = qstrlen(str);

const char *extensions = gl_extensions;

int extensions_length = gl_extensions_length;

while (1) {

// the total length that needs to be matched is the str_length +

// the space character that terminates the extension name

if (extensions_length < str_length + 1)

return false;

if (qstrncmp(extensions, str, str_length) == 0 && extensions[str_length] == ' ')

return true;

int split_pos = 0;

while (split_pos < extensions_length && extensions[split_pos] != ' ')

++split_pos;

++split_pos; // added for the terminating space character

extensions += split_pos;

extensions_length -= split_pos;

}

return false;

}

private:

const char *gl_extensions;

int gl_extensions_length;

};

According to the log message the piece of code just shown went through internal code review. For comparison, here is the equivalent piece of code from my original patch, which was not considered good enough to be applied:

static bool parse_extensions_string(const char* extensions, const char* name)

{

const size_t name_length = (name) ? strlen(name) : 0;

Q_ASSERT(name_length > 0);

if (extensions) {

const char* pos = extensions;

while (const char *const space = strchr(pos, ' ')) {

const size_t length = space - pos;

if (length == name_length && memcmp(pos, name, length) == 0)

return true;

pos = space + 1;

}

return (strcmp(pos, name) == 0);

}

return false;

}

So, instead of just taking the code handed to them on a silver platter, the Qt developers decided to roll their own version. Which I wouldn’t even consider a problem if it weren’t for the fact that the code that went in is longer, less readable, and generally ugly. It’s also broken, because there is not a single word in the OpenGL specification about glGetString() always returning a list terminated by a space character, contrary to what the code comment claims about “all conformant platforms”.

Michael Hasselmann: Logging facility for Miniature

Thu, 25 Feb 2010 16:46:20 +0000

On Maemo 5, log output from your app isn't always accessible to the user. This has created problems for Miniature bug reports (see bug #8124). To solve this, I created a "Game Log" screen which allows to filter the messages (by a given log level, I might want to allow combinations, too). It also has a nice fat "Copy all" button, so that the log output can be quickly attached to a bug report.

Now I "only" need to add useful log information =D

Thanks to Openismus for letting me work on this.

André Klapper: GNOME 3.0 schedule proposal published

Tue, 23 Feb 2010 21:19:46 +0000

Today the GNOME release schedule proposal for 2.31/3.0 was published. Please keep discussion streamlined on desktop-devel mailing list.

It also lists high risk areas and potential showstoppers (please note the word “potential”) as I want to communicate them clearly to users, distributions and the community. Currently I personally don’t expect everything to work out as planned, as manpower is missing in crucial areas. Distributions and the community can help minimizing such potential regressions by providing more developer manpower, or at least help in testing. Please contribute if you can.

Another issue are of course those modules that are defacto unmaintained. Peer reviews could be arranged in such cases.

Peter Penz: Profiling

Mon, 22 Feb 2010 19:19:20 +0000

Although I like Criminal Minds, this blog entry is less thrilling: it's about profiling applications like Dolphin.

When I faced a performance issue in Dolphin, I usually used valgrind in combination with callgrind to find the bottleneck (valgrind --tool=callgrind dolphin -nofork). The output can be visualized by KCacheGrind in a nice way:

One big benefit of Valgrind is that it gives 100 % coverage of user-space code. But as usual there are rarely benefits without drawbacks: As valgrind is a kind of virtual machine, that uses just-in-time compiling, the application runs around 5 times slower. This can get a problem if timers are involved in the application. Also performance issues in combination with threads are tricky to identify, because valgrind does not give a non-obtrusive performance overview of the overall system.

So I started to get familiar with OProfile during the last week. OProfile is a non-obtrusive system-wide profiler, which means that the application runs (nearly) at the same speed as without profiler. OProfile gives an overview about the workload of all processes in the system. This is very useful for Dolphin, as the overall performance of Dolphin depends also on e. g. Nepomuk and asynchronous operations to e. g. get file previews. It is possible to convert the OProfile output to a readable KCachegrind file by 'opreport -gdf | op2calltree'.

Dependent on the usecase, both tools are really helpful. The next thing on my TODO-list is to get more familiar to locate I/O bound bottlenecks: When reading the number of sub directories for 20000 directories, the bottleneck is definitely not on the CPU side (in this case neither Valgrind nor OProfile can detect the bottleneck). All in all I hope that I find the time during the KDE SC 4.5 cycle to improve the Dolphin performance in some areas with the help of these tools.

Murray Cumming: Glom 1.13/14 using boost::python

Mon, 22 Feb 2010 13:20:25 +0000

Finally Figured Out boost::python

After lots of experimentation and two previous failed attempts, Glom now uses boost::python, with very little use of the nasty Python C API remaining. This should make it easier to add Python API to easily access and set field/record/table/database details from the Python that’s used in calculated fields or button scripts.

Useful Things I Now Know about boost::python

boost::python is no fun to get started with, but it’s now far easier for me to use than the Python C API.

I’ve mentioned the awful boost::python documentation before. Here are some essential things that I figured out, which are not really documented. This is thanks to helpful people on the boost::python mailing list. Corrections welcome – there’s so much here that some of it must be wrong.

None of this is very obvious or pleasant. If anyone had their first real C++ experience with boost::python then I’d forgive them for being put off C++ for good. I love C++ so that would be unfortunate.

“Converting” between C and C++ object types

C++ to C: To get the underlying PyObject* from a boost::python::object (awful docs), when you need to use a C function:

PyObject* cobject = theobject.ptr();

To test for a boost::python::object with a null underlying PyObject*, do:

if(cppobject.ptr())

Do not do if(cppobject). That tests if the python object is actually a boolean that is PyTrue.

C to C++: To get a boost::python::object for a PyObject*, when you received one from a C function, but you then need to use the result in a C++ function, or just want the improved memory management:

If the C function gave you a reference that you should later unreference:
```
boost::python::object cppobject( (boost::python::handle<>(cobject)) );
```
(You need those extra brackets, for “interesting” compiler reasons.)
Or, if you need to take a reference.
```
boost::python::object cppobject(boost::python::borrowed(cobject));
```
(Yes. that’s horrible too. I see no reason to expose boost::python::handle in the API.)
However, you’ll need to use allow_null too to avoid exceptions if the PyObject* might be null. Well, any pointer could be null, so say hello to:
```
boost::python::object cppobject(  (boost::python::handle<>(boost::python::allow_null(cobject))) );
```
or
```
boost::python::object(boost::python::borrowed(boost::python::allow_null(cobject)));
```
(Shoot me now. No, reducing it to b::p::whatever is not a significant improvement.)
I understand that a null PyObject* may sometimes be an exceptional unexpected event, but forcing the use of a try/catch by default just for a null pointer check is annoying. Explicit functions such as wrap() and wrap_not_null() would be so much easier.
See the equivalent for gtkmm (plus calling reference() when necessary with non-widgets).

Using boost::python with your own wrapped C++ classes.

To get a boost::python::object for an instance of your C++ class that you’ve wrapped for Python with boost::python::class, just do:
```
boost::python::object obj(new YourWrappedClass);
```
To get a C++ instance of your wrapped class from a boost::python::object, use boost::python::extract (as also mentioned generically below):
```
boost::python::extract<MyClass*> extractor(cppobject);
if(extractor.check()) myobject = extractor;
```

Others

To get a C++ value out of a boost::python::object do, for instance:
```
boost::python::extract<std::string> extractor(cppobject);
if(extractor.check()) mystring = extractor;
```
You can do
```
mystring = boost::python::extract<std::string>(cppobject)
```
without the check() but that will throw an exception if the underlying type is not really what you expect.
boost::python likes to throw exceptions. I think it only ever throws boost::python::error_already_set, though the (Python) error is often not already set when it’s thrown. When the error is set, you’ll need to use Python C API to discover what it is.
To provide [] syntax in python for your wrapped class, you’ll need to know how the C API works. Add this voodoo to your boot::python::class declaration:
```
.def("__getitem__", &MyClass::getitem)
.def("__len__", &MyClass::len)
```
Those methods can then have signatures like this:
```
boost::python::object getitem(const boost::python::object& cppitem);
long len() const;
```

To use Python date or time values, you will need to use C Python functions. For instance:

PyObject* cobject = cppobject.ptr();
int day = PyDateTime_GET_DAY(cobject);
int month = PyDateTime_GET_MONTH(cobject);
int year = PyDateTime_GET_YEAR(cobject) );

Boost has no .pc files

boost is a complete pain as a dependency. I understand that they don’t want to freeze API or ABI, because it’s a place for gradually improving API, though I think they should just have regular stable/devel phases with parallel installs. But I can’t forgive how difficult it is to get the header and linker options to use boost libraries. There are some m4 macros out there but they are hacky and fragile, and don’t actually work for boost::python. It shouldn’t be hard to provide pkg-config .pc files, so you wouldn’t need to do any compilation or linker checks in configure at all. I hacked some m4 code together based on some existing stuff, but I couldn’t recommend it.

So distro packagers won’t enjoy this new dependency. Sorry.

André Klapper: GNOME 3.0 module proposals welcome now!

Wed, 17 Feb 2010 21:30:46 +0000

The Module proposal period for the next GNOME release has started!

If you are a maintainer of a module that you want to propose for official inclusion in GNOME: Do it now! See the wiki for the guidelines.

Murray Cumming: Openismus Website Now More Shiny

Wed, 17 Feb 2010 17:49:47 +0000

Daniel Borgmann has prettied up our Openismus website a little. The small touches make it easier on the eye. It’s no longer so adaptable to every screen size or font size, but it’s still relatively simple. It wasn’t us who broke the web, though we tried not to break it more.

Daniel would have liked to do much more impressive things, but I held him back because I like gradual iterative changes and very maintainable files. He did this without changing the content at all. We’ll see what happens next.

Jan Arne Petersen: Application Indicators

Wed, 17 Feb 2010 10:13:55 +0000

At Openismus I am currently supporting Canonical to implement Application Indicators for Ubuntu Lucid.

Application indicators are simple menus so it is easier and more consistent to interact with them than with the current notification area icons, where each icon behaves differently. Some are showing different popup menus on left and right click, others are showing or hiding some dialog/window on left click.

I started to add support for Application Indicators to gnome-power-manager, IBus and gnome-settings-daemon last week. Patches for upstream are also available (1, 2).

Daniel Borgmann: hackergotchi

Tue, 16 Feb 2010 17:54:15 +0000

Also long overdue is an updated hackergotchi:

I will also be looking for new blog software. Can somebody recommend one that is simple, modern, and standards-compliant?

Daniel Borgmann: Screenshot of Melody Theme

Tue, 16 Feb 2010 01:28:04 +0000

My official work on Maemo has ended now, so I finally had time to finish the long overdue refresh of Openismus.com.

In the end we didn’t stray much from the original, and it was difficult to please everybody, but at least it looks a lot more polished now. The site is still simple and adjusts reasonably well to different font sizes and resolutions. The plan is to update the design frequently.

N900 Themes

Meanwhile, Harmony, Melody and Word City were released to the Ovi Store. All three themes have been developed with a lot of effort during the time I worked with Nokia and are based on the development theme. Harmony and Melody include a background by myself, Word City includes a background by Steffen Halme. I am very happy with how these turned out, unfortunately a bug in the firmware causes the themes to reset whenever the device is restarted. This will be fixed in the next firmware, for which themes will also have to be updated.

Peter Penz: Visiting Openismus in Berlin

Mon, 15 Feb 2010 15:24:42 +0000

On February the 1st I started my new job at Openismus. Most of the time I can work at home in Austria, but last Wednesday I got the chance to meet the Openismus team at their office in Berlin. Beside my first visit of Openismus, it was also my first visit of Berlin. I was very impressed by both of them: the team and Berlin.

I got the chance to do some trials with Qt on Maemo and to get familiar with what is working well and which parts still need a lot of investigations. All developers at Openismus are Gnome people, being the only one using KDE is not always easy ;-) But maybe it helped that Dolphin does not look so much different in comparison to Nautilus - I even got a KDE-sticker from an Openismus colleague.

I'm learning a lot of new stuff currently and will have less time during the next weeks for Dolphin. However this will change after mastering the usual time that is needed to get really productive. In the end I hope that I can apply the knowledge I gathered through KDE development with Dolphin for Openismus and also that Dolphin will benefit from the new things I learn at Openismus.

André Klapper: A blast from the (German) past

Mon, 15 Feb 2010 11:59:24 +0000

Spend a day at my parents’ place this weekend and cleaned up a bit. Found this old application for Western German citizens to enter East Germany. Interesting to see all the stuff that was asked for. Also wondering why it’s also in English and French, but not Russian…

David King: FOSDEM 2010

Thu, 11 Feb 2010 18:42:09 +0000

It was my first time at FOSDEM this year, and it was pretty fun. I got to chat to people about Maemo (although there were not many Maemo-specific talks), and managed to have a good meeting with Dave Neary about my work on maemo.org developer documentation. It was good to see Zeeshan again, and staying in the same hotel as Lennart meant that I got to ~~steal his guidebook~~ pick his brain about good places to eat.

The GNOME Color Manager talk was fun, although nothing particularly new. Hopefully some cross-desktop participation can help that. Greg Kroah-Hartman's talk on writing a kernel patch was interesting, and might finally encourage me to fix my sound card driver (incorrectly-mapped output controls). I went to my first keysigning party, which was weird but fun. Michael Meeks' bootchart2 talk was excellent, and funny of course. Probably the best thing of the conference was the GNOME tshirts, with a GNOME coat of arm and monkeys. Hopefully I get the chance to go to FOSDEM again next year.

Michael Hasselmann: Testdriving the UI Extensions for Mobile on Maemo 5

Thu, 11 Feb 2010 14:00:00 +0000

Reading about Nokia's UI Extensions for Mobile (sources available) I wanted to quickly try it myself. So I looked at the provided examples, and this video is the result of what I came up with (well, of course it is FOSDEM-induced). The provided API allowed me to easily apply my previous Qt knowledge, which is a nice touch. Sources for the example in the video app can be found here and here. Happy hacking!

Update: The UI Extensions for Mobile will not compile on 64bit architectures.

Murray Cumming: In Helsinki at the weekend, Monday and Tuesday

Wed, 10 Feb 2010 12:03:47 +0000

Liam says “broombroom soon Stinky Mama Papa mit”.

That means that we will be flying in an airplane on Friday to Helsinki. I’ll be around for work stuff on Monday and Tuesday too. Most afternoons are planned out already, and evenings are generally difficult with a child, but I hope to see random Nokia/Maemo people, maybe at lunch. I shall be pinging you.

We are looking forward to seeing old friends who we don’t get a chance to see often enough.

Kat, David, Mathias, and Daniel will be around too.

David King: Going to FOSDEM

Tue, 02 Feb 2010 16:57:30 +0000

I will be attending FOSDEM this weekend as part of my work on maemo.org developer documentation. Come and talk to me about Maemo, developer documentation, wiki.maemo.org or even Maemomm. I will also be going to the keysigning event, so come along with some photo ID to get yourself into the web of trust.

Peter Penz: Internal Cleanups

Sun, 31 Jan 2010 14:07:33 +0000

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:

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).
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).

Michael Hasselmann: How to customize your view with delegates

Fri, 29 Jan 2010 16:00:00 +0000

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:

They are owned by the view.
They have complete control over the cell they are assigned to (although that might not be too obvious).
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!

André Klapper: FOSDEM, ah well, why not?

Mon, 25 Jan 2010 14:31:45 +0000

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.

Murray Cumming: GtkToolPalette in GTK+ 2.20

Wed, 20 Jan 2010 07:46:32 +0000

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.

André Klapper: maemo.org: SNAFU ;-)

Mon, 18 Jan 2010 06:30:10 +0000

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.

Murray Cumming: Peter Penz Joining Openismus

Tue, 12 Jan 2010 11:43:20 +0000

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.

Mathias Hasselmann: Technique vs. Intelligence

Mon, 11 Jan 2010 08:36:54 +0000

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.)

Mathias Hasselmann: Re: Facebook Scam Groups

Sun, 10 Jan 2010 09:25:53 +0000

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.

Murray Cumming: Liam at Two

Thu, 07 Jan 2010 10:16:14 +0000

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.

Michael Hasselmann: Fragile API and invalid iterators

Sat, 02 Jan 2010 18:00:00 +0000

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

André Klapper: 2009 Bugzilla statistics for maemo.org and GNOME

Fri, 01 Jan 2010 20:44:47 +0000

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

André Klapper: 2009: Music.

Thu, 31 Dec 2009 03:36:28 +0000

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)

André Klapper: GNOME 3 platform cleanup

Mon, 21 Dec 2009 18:40:36 +0000

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+.

André Klapper: To GNU or not to GNU

Sun, 13 Dec 2009 15:24:00 +0000

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.

Peter Penz: Version Control Support

Sat, 12 Dec 2009 18:13:09 +0000

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!

André Klapper: Maemo: Contributing and long-term platform strategy

Wed, 09 Dec 2009 06:10:49 +0000

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

André Klapper: maemo.org Bugday: Dec 15th, 18:00-03:00 UTC

Mon, 07 Dec 2009 15:18:38 +0000

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.

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.

Karsten Bräckelmann: Bugzilla maintenance to trunk. Progress.

Mon, 30 Nov 2009 19:50:44 +0000

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!

Michael Hasselmann: About delegates and cell renderers - data formatting in Qt

Mon, 30 Nov 2009 08:00:00 +0000

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 prefers~~Let'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 =/

Murray Cumming: Trying to use gnuplot in massif_grapher

Fri, 20 Nov 2009 13:21:42 +0000

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.

Murray Cumming: LDTP in jhbuild: A Cry For Help

Thu, 19 Nov 2009 16:45:53 +0000

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.

André Klapper: maemo.org Bugzilla: Minor tweaks

Wed, 18 Nov 2009 20:24:07 +0000

Incoming reports in the last weeks

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:

Entering a new report

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”.

New “Moved to Brainstorm” answer

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.

Michael Hasselmann: First Miniature .debs sighted!

Mon, 16 Nov 2009 13:00:00 +0000

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.

Peter Penz: Searching

Sat, 14 Nov 2009 13:59:14 +0000

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:

The number of clicks to activate a filter must be minimized.
It should still be powerful: The kind of filters should not be limited.
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!

Karsten Bräckelmann: Back Open, Back to Bugzilla

Fri, 13 Nov 2009 19:31:46 +0000

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.

Michael Hasselmann: Qt 4.6 for Maemo: It works!

Wed, 11 Nov 2009 22:30:00 +0000

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.

Murray Cumming: Graphs from valgrind’s massif

Tue, 10 Nov 2009 14:18:59 +0000

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.

André Klapper: GNOME 3.0: September 2010!

Tue, 10 Nov 2009 11:16:07 +0000

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.

Michael Hasselmann: Miniature - it moves!

Mon, 09 Nov 2009 00:20:00 +0000

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.

Peter Penz: Information Panel and Tooltips

Fri, 06 Nov 2009 20:17:45 +0000

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.

David King: Packaging Glom for Maemo 5

Wed, 04 Nov 2009 20:01:01 +0000

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.

David King: Fooshies (and corals)

Sun, 01 Nov 2009 23:03:03 +0000

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.

Michael Hasselmann: Wt - a Qt-ish web toolkit written in C++

Sat, 31 Oct 2009 00:00:00 +0000

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.

Murray Cumming: Trying qmake and CMake

Wed, 28 Oct 2009 09:34:43 +0000

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.

Michael Hasselmann: Show me your home screen!

Sun, 25 Oct 2009 20:30:00 +0000

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.

Jan Arne Petersen: Fremantle Hildon Desktop

Tue, 20 Oct 2009 18:49:46 +0000

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.