Halfway through GUADEC
Britain as a country is very similar to Sweden, it almost feels like being home except that the language is different. It's funny how many and varied warning signs they have. There are warnings everywhere, for example "Caution! This door may close at any time!" But the warnings at the zebra crossings that tells you to look left or right are very useful. It is completely weird seeing the traffic going in the wrong direction all the time.
The food is cheap but quite bad. Chips are served with about every meal. Best food eaten so far was from a stand at the coach station that sold "Mediterranean Rolls" they tasted really great. Oh, and you don't have to pay tips! That's very much a plus. At least I don't think so, the waitresses and cashiers didn't seem pissed off when we didn't.
The best talk so far was the lightning talk with Michael Meeks and Federico Mena-Quintero. If a memory access is the distance from your nose to your brain, then a disk seek is all the way to the Middle East. Fun stuff. Havoc Pennington and Bryan Clark held their keynote about, unsurprisingly, the Online Desktop. They definitely have the right ideas, but I'm not attracted by their purple "mugshot" client.
Some developer from Beagle held a talk about metadata in which he said that Tracker was unfocused. It will be "interesting" to hear Jamie McCrackens retort in tomorrows talk. :-P Hurray for Open Source Soap Opera.
Alex Gravelys keynote was boring. If you have only one hour, plan for 30 minutes. It seemed like he would have needed at least three hours to communicate everything he wanted to say.
Some poor Eastern European developer got his lightning talk ruined by computer problems. It was fun, but sad that people where laughing seemingly at him. I'll definitely try out his git GUI front end anyway.
Carl Worth and Behdad Esfahbod held a very interesting talk about how the Cairo community has evolved. They are both very good speakers and the topic was interesting. I wanted to ask them how Cairo could be slower than the older xft toolkit. I mean, when you write new code, you usually try to make it faster than the old code you are replacing right? Unfortunately, I didn't have the guts.
Before that, there was a talk about building a modern multi-user desktop. The main thing I took home from that talk was that ConsoleKit, PolicyKit and HAL are boring.
Ari Jaaksi held a keynote about Nokia's involvement in open source. I don't like it so much I think. It's not like I can flash the firmware of their N800 and compile my own OS to run on it, is there? Besides, the device (which has been on sale for several months) had stability problems. Yes I'm biased because I work for a competing company. But retailing a product that is that easy to crash is just bad.
I only saw the end of the libgnomedb talk with Murray Cumming. It was quite interesting. But I don't understand why he didn't understand what I meant when I asked him which libraries libgnomedb was related to. Not many ideas are new in the DB field, even if implementations can contain innovations.
And the disaster of the week has been that my laptop broke. :( I thought I handled it very carefully, but there seems to be some seriously problem with the harddisk. Maybe it couldn't handle the British electricity current or something.
No GUADEC for me
Why I will never use Epiphany
gtk-doc problems
My first reaction was that gtk-doc really sucks. For example, it requires you to write docstrings like this:
You have to repeat my_function_name in the comment even though it should be extremely simple for the documentation generator to find out the name of the function the docstring is documenting.
There is apparently no way to group multiple source code definitions to one docstring. You can't write something like this and expect it to work:
And despite writing docstrings using the weird format that gtk-doc imposes, you will still have to write separate API documentation using SGML. Yay! For each c-file gtk-doc documents, it generates a file called /tmpl/someclass.sgml which contains place holders for each symbol. Here is an except of one such file:
Because gtk-doc likes to write to this file, you will have a hard time keeping it version controlled and you will have to periodically merge it with the real source code. gtk-doc therefore negates the main advantage of using a documentation generator tool which is to keep the documentation close to the source code.
I am sorry for all the complaining. gtk-doc is a decent tool and using it is better than writing all documentation is Latex, for example. But gtk-doc is not the only API documentation tool available. There is doxygen, JavaDoc, Epydoc and a whole host of other documentation generators. gtk-doc just manages to be worse then all of them.
The GtkImageView widget
The project I have been working on lately is to create a general purpose image viewer widget for GTK . For my personal project, which will be a commercial product to be sold, I needed such a widget.
After searching around a bit, I concluded that there was no such widget [ 1 ] .
So, what I have created is such a general purpouse widget named GtkImageView. I think that there is a great use for such a widget in GNOME and that it will be just as useful as the GtkSourceView widget has been.
There are quite a few programs in GNOME that display an image inside a pane which you can zoom and drag around. Atleast both gThumb , Eye of GNOME and GIMP has such widgets. But the image display widget in these three programs is implemented independently and are incompatible to each other. Each behave slightly differently from the other. Different keybindings, different zoom factor levels and different graphic adornments.
This is where GtkImageView comes into the picture. It is an attempt to unify these three different widget implementations into one that they all can use. The gains are obvious:
- less code duplication
- Less code for each project to maintain means less bugs.
- Uniform UI
- The same set of keybindings in all programs means that a user does not have to relearn each program.
- Usable by third parties
- If you today want to create an application that has a widget that can pane and zoom on an image you have to create it from scratch. You would probably look at, for example, gThumb's source and then cut and paste that. Then you would have to spend some time integrating their widget in your own programs. Time that would be better spent doing something else.
Right now, GtkImageView is almost fully coded. What remains is to upload it to bjourne.webfactional.com and make it world-readable. The following tasks are not yet done:
- API documentation needs to be written.
- There needs to be example programs.
- Patches must be written for EOG and gThumb.
- Must announce intention to the GNOME community and get buy-in from EOG and gThumb's maintainers.
- Need to upload code and publish documentation online.
| [ 1 ] | Which was wrong, as I found out later. |
Quick guide to PyGTK on Windows
- Download the Python 2.5 MSI installer. Direct link
Install it to C:\Python25 and do not forget to add C:\Python25\bin to your PATH.
- Download the PyGTK EXE installer. Direct Link
- Download the GTK EXE installer. Direct link
Install it in C:\GTK. It should automatically add C:\GTK\bin to your PATH. If it does not, do it manually.
Download the PyCairo EXE installer. Direct link.
- Download the pygobject EXE installer. Direct link.