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.
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.
Announcing another maemo.org Bugday:
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. 
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.
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.
- 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.
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”.
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.
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.
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.
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.
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.
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.
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).
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?
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.
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.
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…
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 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.
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.
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.
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.
my_document.tx
t
instead of
my_document.
txt
The searching for Dolphin has already improved in KDE SC 4.4, but still needs a lot of work...
Things like these are what I'd like to fix in Dolphin for KDE SC 4.5, so please don't expect huge, new features :-)
BTW: I'm very happy to announce that on February the 1st I'll start working fulltime at Openismus. Most probably I'll get the chance to work with Qt for Maemo 6 (Harmattan).
The usual way in Qt, when an item view wants to render itself, is to ask the item model for everything, layout, style and the actual data. Storing view-specific layout information in the model itself means that views and models can always only exist in a 1:1 relationship. The logical conclusion: If you need to share a model between different views, you will probably have to add proxy models for each view. I wasn't satisfied with that idea, so I continued to research QStyledItemDelegates. They have the following nice properties:
- 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!
Okay, after checking exam dates, chatting with Olav and the Openismus crew, and having the Maemo and GNOME communities in mind I’d like to state:
Just booked a one-way flight to Brussels, not decided yet how and where to go back.
We (Openismus) recently got our GtkToolPalette widget into GTK+’s git master, to be seen in recent GTK+ 2.19 (unstable) tarballs. We haven’t had much extra time for this kind of thing, so I’m glad it’s finally done after being worked on now and then by Mathias Hasselmann, Jan Arne Petersen and Johannes Schmid. Thanks to Matthias Clasen for valuable reviewing and cleanup.
We hope that this can replace the hand-coded tool palette widgets in Glade and Gimp, as well as making this easier for new applications. It replaces EggToolPalette in libegg, where we started the work. Please take a look and report any problems. I’m already using it in a Glom branch.
Here’s the GTK+ API reference for GtkToolPalette. There’s a GtkToolPalette example in gtk-demo.
And here’s a little introductory Gtk::ToolPalette chapter I wrote for the gtkmm (C++) book. Note that gtkmm’s API reference for this is mostly empty, but fixed already in git.
The last two weeks were a bit… stressful.
First of all some Nokia-internal changes with regard to Error Management, then maemo.org Bugzilla moving to a new server. Unexpected side effect was data loss. Spent part of last Monday restoring what I still had in my bugmail. Still it leads to confusion and mistrust (“Why was my account deleted?” – “You probably created it in that data loss time frame?” – “Ah.”).
Then we had the Maemo5 PR1.1 release on Thursday (with a nice ChangeLog) and some problems on Saturday and Sunday, hence bugmail (change notifications) was not delivered.
Sharing other thoughts on broader issues that are currently on my mind:
Before writing the very first bug report (maybe even of your life) it’s recommended that reporters take a look at the How-To. Good bug reports save everybody’s time and issues get fixed faster. We should put this information on the first Bugzilla page to avoid frustration on both sides.
Also the number of incoming reports is constantly high, hence I am sometimes short with my comments (as I also have to take a look at the internal comments for public tickets, verify some reported issues in newer internal versions, keep stuff in sync, and other stuff). Depending on cultural backgrounds some of my comments might be misinterpreted as unfriendlyness.
For the high workload Ubuntu has a nice approach called 5 A Day which is asking community members to triage five bug reports a day. I’d be happy with any number though. 
On a related note, for some reasons I expect more Nokians to be around in maemo.org Bugzilla after the next feature release (PR1.2) has been published. Looking forward to it.
Another problem is that many normal users don’t understand the difference between a bug report and a forum (I’ve blogged about this before, anyway). That’s predictable if you’ve never seen a bugtracker before, but if everybody wants Nokia to be more present in maemo.org Bugzilla and folks actually reading bugmail and responding, please reduce adding comments on what is helpful and avoid unneeded fullquotes or answering above the quote.
Especially if instructions how to provide further information have been posted already adding just another “I have this problem too” comment is unhelpful and creates bugmail noise in everybody’s inbox. Bug reports with hundreds of comments, mixing up issues with similar outcome but different reasons quickly become unreadable so the same questions or comments get reposted plus subscribed people tend to ignore new comments. Of course this is also a question of providing better information on how to provide logs etc – should spend time on this in the next weeks.
In general of course reading before posting is required, but people are lazy. “If this is RESOLVED FIXED, then why do I still see that issue here?” It’s explained that FIXED does not mean PUBLISHED, but we could consider renaming FIXED after having Bugzilla 3.4 in place, as it confuses many people. Red Hat for example calls an internal fix “RESOLVED ON_QA” in their Bugzilla until the fix is really available for public.
So that’s the reason why I educate people ask people to please “behave”. Sometimes I scare some people or maybe have less friends at the end of the day, sometimes people are fine with what I’m doing.
In any way it’s necessary, I just felt a need to explain my intentions in public after a bit of negative feedback in the last days.
I’m pleased to say that Peter Penz will become an Openismus employee at the start of February. I’ve known and liked Peter since I worked with him six years ago in Linz, Austria on a proprietary C++ mobile phone platform. Back then I was impressed with his skill and temperament so I’ve watched with interest as he has become a core KDE maintainer via the Dolphin file manager.
Obviously Peter will help Openismus as we gain experience with Qt for Maemo 6 (Harmattan) in addition to our continued use of GTK+ and gtkmm.
Peter will work from home in Linz, occasionally visiting the office in Berlin. I like the idea of another office in Linz though.
As the military rushes to place more spy drones over Afghanistan, the remote-controlled planes are producing so much video intelligence that analysts are finding it more and more difficult to keep up.
Yet another proof that technique cannot replace intelligence.
(Notice the wordplay.)
Erich: Not sure if Facebook is in charge. All that happens is, that people try to cheat and get cheated back. That's what happens to greedy people who consider themself smarter than they really are.
December’s long season of presents is over and Liam is now two years old.
He’s recently started the famous language explosion, learning several new words each day. He’s obviously aware that he speaks two languages, now learning to say both words instead of preferring the first one he’d learned. He still prefers hand gestures where he has learned them first, seeing no need to learn words for them too.
For the past couple of months Liam has spent the mornings in the crèche over the road. That’s why I’m online again every morning. It’s great for him to learn some independence and spend time with the same kids every day. Leaving him there in tears has been heart-breaking every morning for weeks, but now he’s happy to go there and is nonchalant about us leaving.
I was worried when he suddenly learned more German at the crèche, but that has settled down now. Still, I make an extra effort with plenty of English books and music and some DVDs of gentle British children’s TV from the 70s, such as The Wombles and Ivor the Engine.
The language explosion was accompanied by a sudden increase in general understanding and concentration. Now he happily listens as I read all of a Dr Seuss book to him and seems to understand narrative instead of just wanting to identify objects. His imaginative play is more complicated, with detailed routines.
We’ve had a little snow in Munich this week. Liam learned to walk in last year’s snow. I hope he remembers enjoying this year’s.
For the Miniature project I sometimes need to iterate over all graphics items in a QGraphicsScene, or more precisely, all items of a specific parent item, the chess board itself. For that, I use the QGraphicsItem::childItems() API. However, when used with STL-style iterators you have to be careful, since value types of that form can easily break the iterator idiom:
for (QList<QGraphicsItem *>::iterator iter = parent_item->childItems().begin();
iter != parent_item->childItems().end();
++iter)
{
(*iter)->doSth(); // Ooops! Invalid iterator deref'ing!
}
The value-type list that is returned by parent_item->childItems() has not been bound to a variable explicitly, so it is bound to an anonymous variable instead. The compiler will not complain here although the code is borken, from a C++ point of view. Worse yet, "(*iter)->doSth();" might work often enough for you to not see the crashes right away, depending on the compiled code and how the architecture handles memory.
Eventually though it will crash, and according to Murphy this will happen right after the big release. Valgrind of course would have complained about the illegal memory access right away (when run through that part of your code), because the list that we queried in the loop header is invalidated as soon as we enter the loop body, leaving us with an iterator that points into the void. This is C++-specific, in other languages even anonymous variables are only ever cleaned up after leaving the current block context, but in C++ their life time is only guaranteed for the scope of the current expression.
There is one fix and one workaround to that problem. First the fix: let QGraphicsItem::childItems() return a reference to a list member instead, or simply expose the begin/end iterators for the internal data structure directly. Assuming this is not possible, we are left with the workaround - bind the returned list to a variable explicitly, before the iterator is used:
QList<QGraphicsItem *> children = parent_item->childItems();
for (QList<QGraphicsItem *>::iterator iter = children.begin();
iter != children.end();
++iter)
{
(*iter)->doSth(); // Fine!
}
This of course prolongs the life time of the returned list unnecessarily. We only needed it inside the loop, but now it won't be cleaned up until the flow of control leaves the surrounding block context. To finally get the desired behaviour we could limit the surrounding block context:
{
QList<QGraphicsItem *> children = parent_item->childItems();
for (QList<QGraphicsItem *>::iterator iter = children.begin();
iter != children.end();
++iter)
{
(*iter)->doSth(); // Fine!
}
}
Perhaps a cleaner way is to move the loop code in a function of its own instead, although that might not always be feasible, depending on the code inside the loop body.
Another issue might be the need to dynamically cast QGraphicsItems (QGI) to the desired type, once you implemented your custom QGraphicsItem type. This wouldn't be too bad if there wasn't this horrible mix of QGraphicsObjects and QGraphicsItems in Qt 4.6 - some items inherit from QObject (QGraphicsSvgItem), others don't (QGraphicsPixmapItem). So now you also have to decide between dynamic_casts and qobject_casts, how nice ... not! Honestly, it would be easier here to simply forget about qobject_casts, but that might break in subtle ways.
These two issues were enough for me to avoid the QGI::childItems() API whenever possible. One possible replacement can be provided by signals and slots [1]: First, add a slot representing the loop body to your custom QGI type. Second, connect a signal to the instances of your QGI type that would have been iterated in the loop, that is, have a custom signal representing the loop iteration. Then, instead of iterating over the children of the parent item you simply emit the custom signal which triggers the "loop body" execution for each connected custom QGI instance.
[1] requires QObject inheritance for your custom QGraphicsItem type
This morning my calendar told me there’s a new year available, so I created some quick & dirty statistics for my favorite bug databases:
Like last year my private soundtrack for 2009 in alphabetic order. (Warning: Explicit lyrics and/or video content.)
Röyksopp and The Dø to mention separately, because both albums are just marvelous. Quite unfair to pick just one song here.
Miou Miou – À l’été de la Saint-Martin ‘68 / School of Seven Bells – Connjur / Depeche Mode – Everything counts (Oliver Huntemann & Stephan Bodzin Dub remix) / Paul Kalkbrenner – Gebrünn Gebrünn (Berlin Calling Edit) / N.A.S.A. ft. Kanye West, Santogold, Lykke Li – Gifted / Dear Reader – Great white bear / Unkle – Heaven / Dragonette – I go around (Midnight Juggernauts remix) / Black Eyed Peas – I got a feeling / Yarn:moor – It’s blooming / London Elektricity – Just one second / Friendly Fires ft. Au Revoir Simone – Paris (Aeroplane Remix) / Lady GaGa – Pokerface / Metric – Sick muse / Lady Sovereign: So Human / IAMX – Spit It Out (Designer Drugs Remix) / Hell – U can dance / David Guetta ft. Kelly Rowland – When love takes over / 2raumwohnung – Wir werden sehen (Paul Kalkbrenner Remix)
Long time no update on the Cleanup part of GNOME 3, hence if somebody wants to spend the Christmas days with hacking a bit on boring stuff, here’s the ToDo list!
- Killing libgnomeui: gnome-panel
- Killing libglade: gdm (patch available awaiting review), gnome-media (initial patch exists, but help and feedback needed!), sound-juicer (patch available awaiting review), mono
- Killing libgnome: tomboy
- Killing libgnomecanvas: Evolution
- Killing Bonobo: Currently blocked by gnome-panel, the new A11Y infrastructure (which is on a good way), and for gconf by the proposed desktop wide move to dconf/GSettings for 2.31.
- Killing GlibDeprecatedSymbols and GtkDeprecatedSymbols: Moving target…
- Cleaning up GTK Includes
- Use GSEAL: Moving target as per pending sealings and missing accessor functions. Maintainers: Please do take a look at your module(s) by compiling with -DGSEAL_ENABLE!
And in the extended basket:
So, what did I forget in this quickly written list?
Nice to see more and more modules getting Introspection Support.
Worth to consider: XDG config folder implementation.
Also I’d like to give a big “Thanks” to Javier Jardon for working like mad by both filing bugs and providing patches in these fields, especially when it comes to GTK+.
Being not subscribed to GNOME’s foundation-list mailing list (and having no intention to subscribe to it), I tried to catch up a bit with the controversy of the last days. I might have missed stuff of course.
Trying to summarize:
Initially, Lucas brought up complaints received about content posted on Planet GNOME which triggered a discussion whether there should be rules on appropriate content, whether an annual reminder should be sent to blog authors aggregated to Planet GNOME (telling them that they can remove themselves if they don’t feel fine with it anymore), and whether GNOME has “lost” people because of reasons that could have been avoided.
RMS joined the discussion and Philip disagreed with him. RMS then wrote that people should not post about closed source on Planet GNOME and defined his “most minimal support for the free software movement” . Because of the obvious disagreement, Philip consequently proposed “to have a vote on GNOME’s membership to the GNU project”. Dave warned that such a vote “could cause a lot of harm & discord for the GNOME community” which was answered by Philip.
So far my summary.
Other folks may find other postings more important than the ones I’ve picked – feel free to read the entire thread yourself to get your own opinion.
Now some questions come up here:
- How is “membership to the GNU project” defined? Was “FSF membership” meant here maybe? Is there a public document?
- Is KDE nowadays such a “member to the GNU project” too? If not, why not? Did KDE try or consider applying for it? Links to potential past KDE discussions appreciated.
- Wikipedia states that “the Linux kernel is not part of the GNU project” which leads to the question: How important is it for the GNOME community to have GNOME being a member to the GNU project? (As a sidenote, the term “GNOME” being an acronym is obsolete, just to avoid a useless discussion about potential project name changes).
- I wonder if members of the FSF’s board of directors agree with Richard Stallman’s opinion that Planet GNOME “should not invite people to talk about their proprietary software projects just because they are also GNOME contributors”. As clearly written, “Planet GNOME is a window into the world, work and lives of GNOME hackers and contributors” which also covers activities outside of GNOME, may it be philosophy, hunting, music, non-free software or anything else, as long as blog authors have some relation to GNOME. For technical news there is always GNOME News.
- Which influence do FSF members have on FSF decisions? For example the Windows7 campaign got some bad feedback within parts of free software communities. How transparently are decisions made in the FSF, e.g. deciding about such campaigns? Who is involved? Are there public archives (URLs)?
Sorry if answers exist out there and I have been too lazy to search or have not found them yet.
With regard to my current personal opinion (which may of course change as I’m willing to learn), having read Richard M. Stallman’s recent posts on the foundation mailinglist, he remains a fascistic extremist to me, painting black & white, ignoring reality (with a bad impact on free software user experience if you cannot interact properly with closed source products that obviously do exist out there) and trying to exclude folks from the GNOME community (because they also work on VMWare stuff) because he knows better what’s good for the GNOME community.
RMS has done great work in the 80es and 90es that I really appreciate, but I prefer to forget about his last years (a bit similar to Michael Jackson actually), especially his GCDS keynote in 2009 (yes, I have to come up with this again, because it’s part of the picture). RMS was a non-funny comedian with jokes that can easily be interpreted as sexistic (to me they definitely were, though that most probably was not his intention), trying desperately to auction a GNU puppet by behaving like on a children’s birthday. Okay, one can probably discuss humor here. At least it was not my type of humor. If GNOME ever invites RMS again to a conference, I prefer to stay away and not go there. It’s simply not the community that I want to be part of and proud of.
I always tell myself that RMS does not speak on behalf of the entire FSF, as the FSF has good intentions. But good intentions don’t count if the actual acting and outcome is bad. Plus organizations normally are reflected quite well by the leaders that were elected to represent them.
So yes, the discussion might be definitely less heated if the request to not post about closed source on Planet GNOME had been posted by a different person than RMS, as he himself is controversial enough already. Plus for many people, FSF = RMS.
A general note at the end: “Freedom” to me is also the personal freedom to tolerate and even to use non-free software from time to time, without having a big issue if it fits my needs way better. (For potential “Then help the free software to become better!” comments: I talk about the present here, not about the future.)
And I have enough friends working on closed software. They are awesome people. They just have a different concept that I totally accept because I’m not in a position to say “My concept is the only right one and superior to any other concept”. I prefer to let history decide on that instead.
A good example of a feature that is non-intrusive is the embedded terminal in Dolphin. It only requires one entry inside a sub menu, but adds great value for a lot of people that are not in the scope of Dolphin’s target user group.
Another kind of non-intrusive feature will be available for Dolphin in KDE SC 4.4: version control support. In KDE 4.4 at least a plugin for Subversion is given:
The version state emblems and additional entries in the context menu will only be shown if a directory is under version control, so this feature fulfills the requirements for being non-intrusive. The plugin still has a lot of rough edges and has mainly been written for testing the plugin interface. Still I use it regularly and it fulfills most of my needs.
It is possible for developers to write other version control plugins for Git, Mercurial or whatever, just by following the instructions given in the plugin interface. In KDE SC 4.5 it is planned to embed the plugins as part of the kdevplatform package, but this has not been finally decided yet. The benefit to offer the plugins as part of kdevplatform will be, that the existing infrastructure for version control integration can be reused by the plugins.
Big thanks go to Nuno Pinheiro, who created icons for the version control states!
Great to see the interest on Maemo in the last weeks. As expected, traffic in the forum, in Bugzilla and in Brainstorm has increased impressively.
Discussions have been taking place (with regard to Bugzilla for example here or here) how to make infrastructure work out better for users, with some good proposals. I am also impressed by the patience and friendlyness towards new folks not searching for already existing threads or bug reports, partially pushing the limits of english grammar and punctuation, or towards folks having wrong expectations (Symbian is a completely different codebase than Maemo, hence talking about “regressions” is technically speaking wrong. If you want all of the Symbian functionality and lose some of the Maemo functionality, just get a Symbian device if it makes you happier). On a related note, I’m also trying to keep Bugzilla a technically focused place and make clear that it’s not a forum (“WTF???” comments are counterproductive noise if you want developers to read maemo.org Bugzilla mail, really).
Two issues that have been on my mind lately:
- I am afraid of Nokia doing the same mistake for Maemo5 that was done for Maemo4 – evolving and supporting a platform just for a few minor updates which is bad for the ecosystem around. “Maemo hasn’t had a chance yet to gain real long-term stability. The life-cycle of a Maemo version is too short for that, and there is no continuity between versions.” If 3rd party developers are unsure whether to write their new great application in GTK (abandoned for Maemo6) or Qt (not yet ready for Maemo5) they in doubt don’t write it at all and might support a different platform instead.
- Also, there must be improvements with regard to contributing (patches or even co-maintenance of modules). It’s too unclear where to find which codebase. Garage? Stage? Gitorious? Is it free or closed? Glad to know that Stskeeps is working on it as part of the maemo.org Sprints (ID: 9.11-04).
Open source community expectations are about taking (Give me the code!) but also about giving back (Let me provide patches in Bugzilla and have maintainers review them!).
Tarballs are available in the repositories, but hackers normally prefer the fresh code instead.
I’m proudly announcing the first maemo.org Bugday:
in #maemo-bugs on Freenode IRC
This is a nice way to get involved if you are a fan of the Maemo platform and the N900, but cannot or do not want to write code for example.
Bugdays are about hanging out together on IRC, triaging/discussing some reports in maemo.org Bugzilla, and introducing new people into triaging. No technical knowledge needed, no obligations. So, step by and say hello to the Bugsquad.
And now to some other bits and pieces:
- We’ve become stricter with regard to having non-trivial enhancement requests filed in Brainstorm instead of Bugzilla. To avoid reporter frustration, a note about Brainstorm when entering a bug report will be displayed in Bugzilla soon (Karsten is looking into this).
- New shiny Bugsquad logo by wazd (see above). Thanks!
- Published and updated version of my small maemo.org Greasemonkey triage helper script. Happy to share this.
As Andre mentioned, me being back part-time to the technical side of Bugzilla and taking hacking work off his hands already paid off — some minor, yet much needed Bugzilla tweaks finally went live. While Andre can keep fully concentrating on the growing number of community bug reports, due to a growing community.
The first task turned out to also require quite some cleaning-up, fixing and Perl compatibility coding, to get the maintenance branch back into working state. Once I won the fight with SVN, the requested changes were done quickly. 
Currently I’m wading through SVN again (trunk this time), making heads and tails of some confusing commits, chasing missing templates and skins, to get a clean, almost vanilla Bugzilla 3.4 up and running, while maintaining our precious customizations. A whole lot of CSS fun is lurking right behind the corner — Bugzilla with the new maemo.org style!
Warning: the following blog post has a rant-to-usefulness ratio of 3:1.
Last week I needed to perform some data formatting on Qt list view. From reading the documentation alone I could not find a satisfying answer. When asking on IRC the answer was to use proxy models. This would have worked, but having two models for one view can create all kind of correspondence problems (think of sorting etc.). And there is this interesting bugreport, complaining that there is no easy way to format data. Status: rejected! So formatting should be a responsibility of the view? Wow, who would have thought ... however, if proxy models are a no-go we are left with ... custom delegates.
(cut some nonsense about MVC)
In the Qt world, a delegate is reponsible for 3 tasks:
- editing contents displayed in a view (possibly by creating new editor widgets on the fly),
- updating the model with the modified contents,
- rendering the contents in a view.
Somehow, that's two tasks too many, for something that is not a controller. That's where I prefersLet's take a look at GTK+ cell renderers: they only perform one task, and that's exactly what their names suggests(correction: actually, they are responsible for editing and updating as well, should have read more). A text cell renderer renders text, a pixbuf cell renderer renders pixbufs, and so on. Simple but tremendously flexible.
So how can I inject this flexibility into delegates? The QItemDelegate won't be very useful unless you want to use a QPainter for everything. But there is this styled item delegate, added with version 4.4 of Qt. And if we look at the roles & accepted types table we can see how this - together with displayText - could translate nicely into Qt "cell renderers". So we create custom styled delegates for each data type we need to display in our view: text delegates, pixmap^Wdecoration delegates ... Once we have defined a set of custom delegate classes we then request the view to use them on a per-row or on a per-column basis. A proof of concept can be found here.
EDIT: Had to correct some nonsense, this post was too much of a rant and I wasn't thinking clearly. What I originally wanted to express was that with QStyledItemDelegate we can have something very similar to GtkCellRenderer and use them both in a very similar way, too. I think the Qt documentation could have been easier to follow with straight and simple formatting data example, hence my rant. Sorry =/
I’ve been trying to use gnuplot instead of Gd::Chart in my massif_grapher script, mostly just so it can generate zoomable postscript or SVG output.
I first tried using the Chart::Gnuplot perl API, but after a very helpful email conversation with its maintainer Ka-Wai Mak, we found that it cannot yet be used to create gnuplot’s “rowstacked” histograms. So now my gnuplot branch of massif_brancher uses gnuplot directly. However, there are still some problems that I can’t solve easily:
- The x axis has a label for each item, which makes it cluttered, with overlapping text. I think this cannot be changed while using xtics(1) in the “using” statement, but that’s voodoo to me and I can’t find some version of the using statement that doesn’t use xtics.
- When using massif_grapher’s –detailed option, for instance with the example .out file, there are 60 stacked columns of data. The legend (key) is then so big that it pushes the graph off the page. I’ve asked about this on the gnuplot mailing list, but I am inpatient.
Actually, I wish I could do these stacked (or “cumulative” in Gd::Chart terms) graphs for regular line graphs, instead of just as items on a histogram, in case the snapshot times are not at regular intervals.
Glom has lots of code, lots of functionality and lots of UI. It’s easy to break things when making changes to the code. So Armin set up some initial Glom LDTP python scripts to check for regressions. These scripts try to actually use the UI and then check that the application worked as expected.
I’m sure I had that working once, but it doesn’t work for me now. I wish it did because it would be incredibly useful to me. Note that I build Glom in jhbuild, so I need LDTP to work there. To simplify things, I build LDTP in jhbuild too. I’m trying this on Ubuntu Jaunty and Ubuntu Karmic. Armin has a similar environment and it does work for him.
The problem is that the waittillguiexist() [1] function calls just timeout instead of recognizing that the first window has appeared. I definitely have accessibility support enabled, and Accerciser does show the window properly. I’ve asked the LDTP developers but they haven’t been able to help me.
[1] Yes, I hate that function name. I wish that the API and documentation had received proper feedback from native English speakers. It’s rather embarrassing to look at so far.
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.
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.
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.
I'm also unsure which data the breadcrumb should show: Visualizing a string like "nepomuksearch:/+lastModified2009-11-13 +rating8 +tag:Peter" to the user is something where I doubt Apple would do. Any suggestions would be welcome.
That's also one purpose to write this blog entry: Please let me know your daily problems when trying to search and filter files from your hard disk. I hope that I can integrate your input until KDE 4.4... Thanks!
After an interesting ride internal, I’m back to open and hacking Bugzilla — at least for a couple weeks — helping Andre with technical and coding stuff for maemo.org Bugzilla, as the increasing amount of incoming bug reports takes more and more time. It’s very nice to see the same old guys still around.
My priority tasks are first some quick, much needed tweaks to the current version. Then on to new lands, getting Bugzilla 3.4 in shape for maemo.org. Stay tuned.
Today at work, David King kindly informed me that there was some new Qt package in extras-devel. This could only mean one thing - I immediately fired up my scratchbox environment and installed the packages, trying to confirm that this new version would run with Qlom. And in fact, it was surprisingly painless. Thanks to autotroll, a simple QT_PATH env variable did all the magic, hooray!
Both of us were impressed with the UI improvements. It's certainly a big step forward regarding the Hildonisation of Qt on Maemo5. The application menues look correct now. Button sizes, colors, animations, etc - it all comes together nicely, finally.
There are still some widgets that need more work, but for a tech preview this is a pleasant surprise.
Valgrind’s massif tool tracks how much memory an application uses over time, allowing you to see leaks. Previous versions produced pretty graphs. For instance, see the graph in this out-dated GNOME tutorial about massif.
However, massif’s behaviour has changed and those graphs are no longer generally appropriate. But they were nice. So I hacked a copy of the current ms_print perl code, producing massif_grapher. Forgive me for my perl code.
I used perl’s GD::Graph module. It worked but it’s a little eccentric. The image size is hard-coded and needs to be increased in the code when Gd::Graph complains that the vertical or horizontal space is too small, if you have too many data points.
massif_grapher.pl outputs a massif_pretty.png file:
- There’s a simple graph (the default) that just shows the stack and heap allocations, splitting the heap up into useful and extra (allocated as an optimization) . It doesn’t mention any functions. See this example.
- And there’s a detailed graph (via –detailed) that tries to show the old-style cumulative graph, with color for each allocating function. See this example. I won’t put it directly in my blog because their’s some obviously weird stuff happening at the top. Also, the legend needs to be reversed so it’s easier to associate the functions with the blocks on the graph. Patches welcome. You’ll get weird results if you don’t specify–detailed-freq=1 to massif.
Time will tell if this is useful.
Other useful massif tools:
- Eclipse Linux Tools’ valgrind support: Scroll down to see the video for their massif support. This allows you to jump right to the code. Useful if you are using Eclipse.
- massiftool: A Qt-based application for navigating massif snapshot data.
After collecting some feedback, the GNOME Release Team has finally decided on the release date for GNOME 3.0: It will be September 2010.
To take a look again at the GNOME 3 plan that was released in April 2009: Click here.
New module decisions for GNOME 2.30 were also made of course.
How it begun
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.
- Show the same data in the information panel and the tooltips. Up to now the information panel did not provide any information about the permissions or the owner of a file. The tooltips have shown this kind of information already, but they did not provide informations like rating, comments or tags.
- Prevent a possible blocking of the user interface, even when a slow Nepomuk backend or a buggy Strigi analyzer is installed. Although in KDE 4.3 some improvements had been done already, there have been still problems in this regard especially for tooltips.
- Improve the layout of the information. The rating, comment and tags information are not handled in a special manner anymore.
- Simplify the interface for editing tags and comments.
Although there is still a lot of finetuning necessary until KDE 4.4, it is obvious already that the tooltips...
... show the same information as the information panel:
Originally it was planned to move the refactored widget to kdelibs, so that applications like Mailody, Gwenview and Okular can show the informations in a similar way. However there have been some usecases especially in combination with Gwenview, where the interface of widget was not sufficient yet. So we decided to leave the widget in Dolphin for KDE 4.4, but I'm confident that we find a good solution until KDE 4.5.
I have finally got Glom packaged for Maemo 5. It is currently in extras-devel and is installable from the Application Manager. This took quite a bit of work, which I put down to not knowing enough auto-fu. However, the Debian packages are now /opt-ified, and the DBus .service file and .desktop file are installed to the correct locations on Maemo, which gives working application launcher icons. The process for doing this is not particularly well-documented (the best documentation is from Diablo), so here is a quick list of what the average (moderately complex desktop application) Debian package would need in order to be modified for Maemo:- Maemo-optify support. This involves running maemo-optify just before dh_builddeb is run, and adding maemo-optify to the package's Build-Depends. For CDBS packages, this can be performed in the binary-install target. Glom produces several binary packages from a single source package, and maemo-optify is run for each binary package to be optified. There are alternatives to running maemo-optify, but it was something that I wanted to try out, and it worked.
- DBus .service file and .desktop file modifications. This involves adding a X-Osso-Service line to the .desktop file, e.g. X-Osso-Service=org.maemo.glom. Then, a DBus .service file must be created, with the same service identifier, e.g. Name=org.maemo.glom. The paths for installation of these files can be obtained via pkg-config from osso-af-settings (do not forget to add it to the Build-Depends of the package). My changes to Glom are in git (and a patch in the Glom package). The application must respond to DBus events if it is started in this way, and the simplest way to do this is to pass the DBus service name as a parameter to osso_initialize(), from libosso.
- Maemo-specific MIME-type modifications. Assuming that an application already installs MIME-type information and desktop files, and updates the databases correctly, there is one modification that can make things nicer on Maemo. There is an additional category that can be added to the MIME-type description. The change is safely ignored on non-Maemo-platforms.
- Atypically, Glom links to libgettextpo (most packages that use gettext for translations do not need to do this), and the package list on an N900 and in the SDK/package autobuilder is different, such that the required package does not exist on the N900. Rather than packaging gettext or libgettextpo for the N900, I decided to statically link to the library on Maemo only. This neatly solves the problem, and only increases the binary size by a few kB.
It has now been ten months since our move, and the tanks are finally starting to look presentable. Over the last couple of months I have also been getting in touch with various specialist breeders and importers across Germany, as all three of my display tanks were very bare up until very recently, as we concentrated on acquiring new furniture. After many emails, I have finally managed to find a friendly marine importer who had one of my favourite corals in stock: Duncanopsammia axifuga. It is probably one of the easiest corals I have ever kept, being undemanding in the lighting department and very hardy, requiring only the occasional feeding on a regular basis.Our freshwater aquariums have also been looking up, with the addition of gravel and décor to both. The Lake Malawi Mbuna travelled well compared to the South American fish, and the yellow Lab (Labidochromis caeruleus) fry were especially resilient. As I am very limited on space, I have been raising them in my Rift Lake themed display tank which, unfortunately, means that I now have to find new homes for them.
The planted aquarium took the longest to recover, as many of the plants suffered during transport. It took a long time to find a suitable substrate so the plants were left to float at the top of the tank for many months after the move. I have had to put this tank at the top of the list for restocking because I keep keyhole cichlids (Cleithracara maronii), who are renowned for being extremely shy to the point where the sight of a neon tetra can send them into hiding, let alone a big, scary person walking into the room. Therefore, they require dither fish: any peaceful, small, schooling species which will indicate that there is no danger while they are out and about.
As for the quarantine tank, for the last four months, Jan Arne and Bev have been borowing it to try out fishkeeping; I think they are both addicted now.
First of all, C++ for web apps doesn't necessarily make it easier to write them. Compared to other solutions (let's say Django) you'll end up writing a lot more code. And you have to be very very careful with memory leaks.
But that isn't the point. The main advantage of this framework is how close it is to desktop applications. Porting your Qt desktop application to the web is certainly easier with Wt than with any other solution, as you keep most of the widget API and also the signal and slots paradigm (which should allow to port the app reusing the same business logic as on the desktop).
Also, this is the first time I could attach a powerful debugger, namely gdb, to a web app and debug it is as if it were a normal desktop app. Together with the compiler-guaranteed type safety this is a huge improvement for code robustness.
A toolkit that actually uses C++
There are also some distinct advantages of this toolkit over Qt itself:
- no MOC preprocessing (unless you integrate it with your Qt libraries, of course),
- boost::signals & boost::bind wrapped in an easy-to-use WSignal, keeping most of the boost API accessible for the user. Which means: the compiler can check whether your signal connections will work!
- boost::any instead of QVariant: another big advantage. Boost::any is type-inferred using template voodoo so again, the compiler can check its correct usage for you. Getting values out sadly requires a (static) cast it seems.
Installation
The fastest way is to simply get the source from the git repo and to follow the instructions:
- (enter your jhbuild shell if your project happens to use any GNOME stuff)
- enter the cloned git repo
- "$ mkdir build"
- "$ cd build #dont ignore this, it helps later on!"
- "$ cmake -i ../ #interactive mode asks lots of stupid things but also various path settings!"
- "$ make"
- "$ make install"
For your own projects make sure to link against all the needed Wt libs: libwt (core), libwtext (if you want to use anything from Wt::Ext, see below), libwthttp (if you want to build apps with inbuilt web server, quite helpful). If you happen to use autotools then you might want to include AC_CHECK_LIB macros into your configure.ac. I had troubles finding non-name-mangled function names, but "$ readelf --dynamic --symbols /path/to/lib/lib.so | grep -v _Z | tail" should help.
ExtJS
Wt wrappes a highly advanced (in terms of bringing desktop UX to the web) Javascript framework - ExtJs. Sadly, it is also big (roughly 80kb have to travel to the client first) and very buggy. It would seem that you could use ExtJS and make it use jQuery instead, perhaps that's worth a try. For now I disabled ExtJS in my little project, since I couldn't debug some of its issues. The Wt-native widgets seem to be quite solid in comparison (even if they look a bit boring).
The installation instructions that come with Wt don't tell you how to install ExtJS, so here is what I found out:
- download ExtJS framework (you probably want version 3),
- copy it into your chosen wt webroot (let's say "/var/www/wt/"), consult your CMakeCache.txt,
- extract the zip archive,
- THEN copy /var/www/wt/ext/adapter/ext/ext-base.js to /var/www/wt/ext/ (the error message when starting the web server gave that hint away),
- make sure your project is linked against the libwtext library.
Until this week I was not familiar with qmake and CMake because I am a fairly satisfied user of autotools. I have not forgotten how strange it was when I first learned it, when there was no decent documentation, but things are much better now. I feel at home with it and I like how other systems and distros expect the standard “configure;make all install” steps. I am definitely biased against the use of other build systems.
However, these days I have to deal with code that uses qmake and CMake and I can’t just be stubbornly ignorant. So I tried an experiment. I created branches of a little (but real-world) project that uses Qt and an extra library via pkg-config: qlom with qmake, and qlom with cmake. The master branch uses non-recursive autotools.
I was not impressed. Please do add comments to correct me. I’d particular like patches that make my errors crystal clear and prove that it’s all much better than I think. I am capable of admitting error and changing my mind when appropriate.
Bad Documentation. Weird Syntax
Just like autotools, neither were easy to get started with. The documentation is fragmented, unclear, and incomplete. I found qmake easier than CMake, but that’s probably just because qmake does much less. Nevertheless, CMake has a real problem with documentation and in general, as a widely-used open-source project, it deserves a better infrastructure.
They both suffer from one major problem shared by autotools: They have evolved over enough time that Google will happily return out-of-date examples and documentation, making the syntax seem more varied than it really is. I wish that autotools could force me not to use deprecated syntax. I don’t know if qmake and CMake can.
As with autotools there’s a heavy dose or arbitrariness:
- File names: autotools’s configure.ac and Makefile.am seem more logical than SomeProject.pro (qmake) or CMakeLists.txt (CMake)
- Syntax: m4 (used by autotools) is a crappy language, but at least it’s a mature one that’s used outside of autotools. I understand the wish to have no dependencies, but “invent a programming language” is always a bad design decision.
And autotools don’t require anything but make when building from a tarball. qmake and CMake seem to require that they are installed even when building from a tarball. I would have liked to see Python used because it’s easily available on all machines that would create source tarballs.
CMake’s non-case-sensitive function names and keywords are personally annoying to me, because I like code to have a consistent style.
No Respect For pkg-config
I am dismayed that CMake expects people to write code for “Find” modules for each library they might use, while having poor support for the generic pkg-config solution. A project’s list of dependencies is data, not an excuse to write code. More code means more problems.
In fact, after several days of trying, I still can’t figure out how to use pkg-config with cmake, so my glom_cmake branch is not finished yet.
Most libraries provide the simple .pc files these days. The autotools PKG_CHECK_MODULES() macro makes it very easy to check for several dependencies at once. CMake feels too much like the bad old 90s when we suffered fragile copy-paste-hacked config scripts, custom m4, macros and verbose build files with separate CFLAGS and LIBS variables for each dependency, and inconsistent release-version and API-version checking.
I understand that pkg-config is not popular on Windows or MacOS, and that those are awkward platforms to work with, but:
- The real solution to poor dependency information on Windows and MacOS is to encourage the use of pkg-config, so it can fix the problem there like it fixed the problem for Linux. That’s entirely possible for the cross-platform libraries that are typically open source. And pkg-config would be easy to port.
- The platform-specific libraries on Windows and MacOs don’t need any cross-platform support in the build system.
CMake’s use of scripts just spreads the chaos to Linux instead of keeping things simple on Linux and improving the other platforms too.
No Configure Stage
With qmake, I really miss having a proper configure stage, with the resulting config.h so my code can use ifdefs. I like seeing a list of documented build options from configure –help, which neither qmake or cmake offer.
CMake can generate a config.h, at least. However,
- There are no default checks, so you must specify the common stuff always, making the build file more verbose.
- You can’t just generate the config.h.in, as you can with autoheader when using autotools. There’s no reason to specify the defines in both CMakeFiles.txt/configure.ac and config.h.in.
- Arbitrarily, the config.h.in uses “#cmakedefine SOMETHING 1″ instead of #undef SOMETHING as in autotools (now deprecated, unnecessary) config.h.in files. For anything other than booleans, there’s an undocumented syntax such as #cmakedefine “@PACKAGE_NAME@”.
Install is an Afterthought
Both CMake and qmake require explicit extra syntax to actually install the built executable. With autotools you get this for free when using the regular bin_PROGRAMS to specify the executable name, though libraries do need more explicit instructions to install the correct headers in the correct place.
- With qmake, this typically means that paths are hard-coded in the build files. That way lies pain.
- With CMake, it’s easier, but you have to do “make -DCMAKE_INSTALL_PREFIX=/opt/mystuff” instead of autotool’s simpler ./configure –prefix=/opt/mystuff. autotools lists that option via “configure –help”.
Also, qmake and CMake have no make distcheck for making source tarball releases.
This makes sense slightly because CMake (and maybe qmake) aim to support Windows, Mac, and Linux equally, and Windows has no real convention for installation of built-from-source binaries. CMake (and maybe qmake) generate convenient Visual Studio and X-Code project files, for instance. But the end results it that Linux and Linux conventions are not fully supported, so they feel like major regressions compared to autotools.
(note: removed my nonsense with the TODO about the location of .o files.)
Summary
In summary, I think:
- qmake would only be used by Trolltech (now called Qt Development Frameworks) for their own projects, out of habit, or by users of Qt who are so unaware of other systems that they would just do whatever Qt’s developers recommend.
- CMake isn’t simpler, so it doesn’t solve autotool’s steep learning curve. It makes many thinks worse than autotools and its documentation is disconcertingly vague and incomplete. It’s cross-platform dependency checking adds complication without solving the real problem. The best CMake experience is probably with a large monolithic project rather than a large dependency tree of modules. But I like modularity and reuse.
I understand the wish to support Windows and Mac-specific build systems such as Visual Studio and X-Code. I just don’t like how qmake and cmake do that, and for me it’s not worth making things worse on Linux. Still, I’ll have to use these in some existing projects, so I’m glad that I’m more familiar with them now.
To me the empty home screen* of the N900 looked like an invitation, so I tried to fill it up with useless stuff as quickly as possible. The home screen configuration menu offers app launchers (shortcuts), bookmarks, widgets and contacts. Let's go through all four options in detail:
Shortcuts: I almost always have some tasks running in the background so launching an application would usually take three to four finger touches. Therefore the app launchers are extremely helpful to me.
Bookmarks: The idea is neat but not essential. The browser starts with a list of bookmarks anyway (how convenient).
Desktop widgets: I never believed in them, but the calendar widget might easily change this! It shows the current day and up to five upcoming events. It's a great addition to the fantastic calendar app.
Contact shortcuts: On this device, everything focuses on integrated contact management. For once, keeping your contacts up-to-date is actually useful and not just a time sink, simply because you can use them from almost everywhere. The logical conclusion follows: you can also add shortcuts to contacts on your home screen! It will show online status, avatar and nick of the chosen contact. Nice!
So what's on my current home screen?
- Calendar widget,
- two bookmarks,
- home ip widget,
- 12 app launchers (from top left to bottom right): settings, app manager, terminal, media player, photos, chess, notes (nice app, too), e-mail (ugly icon, and potentially confusing), IM (why does this look like an e-mail icon?!), browser, address book, phone (I had to disable the "launch when rotating" feature since phone calls would stall and eventually force me into device restarts. Too buggy for now),
- two contact shortcuts.
I know - it looks as if this was a Symbian smartphone (that is, ugly and horribly crowded). But I like it this way, at least for now =)
So what's on your current home screen?
*: I still think dashboard is a better name.
The source code of the Hildon Desktop for Maemo Fremantle including the hildon-deskop, libhildondesktop, hildon-home and hildon-status-menu components, which I worked on for the last year at Openismus, moved to a public git repository at maemo.gitorious.org. It is now easier to track the current developments or create your own modified version of the desktop for the N900.
My first chess computer
Years ago, when I was thoroughly fascinated by chess, I always wanted a portable chess computer. When I finally got one (a Novag Piccolo, for the odd chance someone else had the same device) I'd take it with me whenever possible. It got worn out quickly, moving the small plastic figures required more and more pressure to make the computer acknowledge my moves. For each move you first had to "touch" the figure you wanted to move. The computer would beep and show 2 LEDs (one for each row and line), for a lack of better feedback. Then you'd put the figure to its target location and "touch" it again, with the same feedback procedure for a valid move. If the move wasn't valid the error LED was lit. Perhaps this wasn't the best user interface in the world (I yearned for a self-moving Mephisto Phantom which actually was a Fidelity Phantom), but it worked for me and I was happy.
The problem with computer chess
The downside came when I realized there was a set of moves for each difficulty level that would always win. Later when Deep Blue won vs Garry Kasparov I lost interest in computer chess, because it seemed you could either have an imperfect machine that was boring to play (a certain set of moves would always win), or a nearly perfect machine that would bruteforce its way to victory. At least that's how the future looked to me in 1996.
Could computer chess ever be fun again?
With the N900 device lease programme from the Maemo Summit I think I finally got my very own special version of a Mephisto Phantom: The chess app that is installed by default moves "by itself" (duh ...), and with Hildon's finger touch paradigm I have a similar "board feeling" as with my old Novag Piccolo. And damn - this N900 surely is portable!
How to make it less fun
Now you would think that with an ARM Cortex-A8 it should be possible to play challenging but also fun games. But here comes the frustration again: gnuchess - the chess engine being used - comes without the opening book. Of course there might be valid reasons to not include the opening book/end game database:
- space consumption on the device (though the default opening book is pretty small),
- gnuchess is good enough to beat most players into submission
- a chess app should be more than an "opening book replay engine"
Only that chess engines are still too dumb to come up with meaningful opening moves on their own. Worse yet, gnuchess wasn't configured to randomize the outcome of its evaluation function. Which means: this device is still susceptible to the same strategy I used vs. my first chess computer nearly two decades ago!
Conclusion
The solution could of course be easy: Include the opening book and let gnuchess pick the worst move (even better: choose one randomly) from the lookup tables on easier difficulty levels, or limit how many moves into the game it is allowed to play "by the book". Also introduce random noise to force gnuchess into mistakes that are exploitable for casual players.
I will continue to play chess games with the N900. Let's try to improve the chess app though!
After spending three holidays in Amsterdam (rainy but still a wonderful time) we moved from our hotel to the Openismus apartment on the evening before the summit started. Great to see the friends/colleagues again, plus only 5 minutes of walking to the venue.
As my laptop had died directly after arriving in Amsterdam this was a good chance to test whether Modest is an acceptable replacement. I ran into three issues: Not possible to mark several messages at once as read, no threading view (really important if you get lots of Bugzilla mail and want to read the previous one), and no option to search for a message (and not just in the one message that you have selected).
Conference opening was nice. Jim Zemlin’s keynote (Linux Foundation) was a bit too much for me though, sounded like “Linux will have 101% market share next year because it’s better than everything”. Qole interviewing Ari Jaaksi had a good moment: Ari stated that having two bugtrackers does not make sense in the long run. Good to hear that common sense is shared.
I was content with my talk about the current situation of maemo.org bug management (boring slides here, video hopefully later).
Now that Nokia handed out 300 N900 pre-production devices to the folks at the summit, maemo.org Bugzilla has been flooded with new reports. Most of them have a good quality (seems like developers know that being exact in the initial description saves everybody’s time) but still it looks like more than we can currently perfectly(TM) handle so we need more help in the long run.
Let’s see how the next weeks go, especially when average users have found their way to maemo.org Bugzilla and start filing their issues. Keep in mind that for many it will be the first time to do this, hence let’s be friendly and explain some triaging decisions whenever it makes sense (”Thanks for reporting this. This has been already reported.” or “Thanks, but this is not a bug in the software itself. Please go to http://talk.maemo.org to receive help in this case.”).
As said, help is always welcome.
Photo by thp4, CC licensed
As expected, my Glom talk at the Maemo summit was rather under-attended while people went to the security talk next door. I had still hoped to do an entertaining talk for the video cameras, but my mind when blank and it was a bit of a shambles. The slides (or with notes that I forgot) should give you an idea of what I was trying to achieve.
Since then I have made some more simple improvements to the Maemo 5 port of Glom, as you can see in this new video (youtube or .ogv on my site), again using the Sqlite version of the simple Music Collection example.
These are the visible improvements:
- Details views now have “Add Related *” buttons in the AppMenu so you can actually add related records. Again, this uses an extra window.
- The Table name is mentioned on the title of the Details window.
These last two required me to add the ability for the designer to specify the singular form of table and relationship titles. For instance, “Album” instead of “Albums”. Actually, I guess that’s still not enough for some translations, so we may need to allow designers to specify actual phrases. - Details views now use HildonPickerButtons for ID fields instead of combo boxes. So they open a separate window to actually choose the value.
- The scrollbar is against the right edge.
- The widget spacing is more correct for Maemo 5, though there’s lots more to do, and it could be made much prettier by aligning widgets even when they are in different groups, particular because the group titles are hidden in the Maemo port.
I will stop coding on this for a while, but I think I’ve shown what’s possible. And I think I’ve shown that Glom is already (or could be) the best base for a simple database-driven application on Maemo – far preferrable to writing code and SQL.
The current code will be packaged in extras-devel soon.
Subscriptions
- André Klapper (feed)
- Daniel Borgmann (feed)
- Daniel Elstner (feed)
- David King (feed)
- Jan Arne Petersen (feed)
- Karsten Bräckelmann (feed)
- Mathias Hasselmann (feed)
- Michael Hasselmann (feed)
- Murray Cumming (feed)
- Peter Penz (feed)
Links
Last updated:
March 14, 2010 - 23:18
All times are UTC.
Powered by:
