First milestone of Yzis got finally released.

For those who forget, yzis is a vi editor, like gvim but with brighter future.

It is not so bad for a first release: we have text and KDE frontend, unit tests, syntax highlighting, undo/redo, KDE component support and copy/paste.

It will take us a lot of time to fix the details however.

Trolltech interview
After month of battling, first with the audio transcription, then with the english correction, and finally with the french translation, my Trolltech interview finally gets published: English version and French version

Yzis
I am the first one to say that there is no more stupid project than writing a source editor. There are plenty, they work good enough, you should better focus on something more useful. Even more stupid would be to rewrite one major editor like Emacs or GVim. Despite that, I am now engaged in Yzis, the rewriting of a vi-like editor.

The problem we had with gvim is that when doing KVim, we found many limitations in the way graphics are handled in gvim. It prevented us to make a good kpart component for KDE. Working with the source was a nightmare and the author was not willing to ease the task for us: only bugfixing and nothing else are accepted in gvim.

So, we started yzis. So far I have contributed the test suite and the undo code. Despite gvim being very advanced, I am confident that we can eventually bring a better editor. The key of success for yzis vs gvim:

• object oriented code (yes, this is C++) that cleanly separate features: gvim is coded in C, a big part of it with pre-ansi syntax.
• documentation in the header file: gvim has no such things as header-file
• easy-access: it is very easy to add a new command to yzis already, and it will only get easier
• strong test suite to allow easy maintainability and no regression: this is where gvim fails. Currently, Bram does not want to touch gvim too much because he is afraid of breaking anything. We won't have this problem. One of my coworker says that a good test suite is more valuable than code. With the test suite, you can write the code again and be sure get what you want.
• seperation of vi-engine and GUI code: a problem we had with gvim is that the engine is so tied to the text frontend that it is difficult to use it in graphical environments. There is no such thing as event-loop which forced us to do twisted manipulations (sometimes eating all the CPU)

Currentely, we have two GUI: one with ncurses, and one with KDE. The one with ncurses is a bit broken because Thomas is not available those days but it should be back soon. We have basic editing capabilities and multi-file support. Undo is almost finished. We even have one tester.

On the drawbacks side, yzis (even the engine) depends on Qt because we did not want to deal with unicode problems. However, we use very little of Qt for the backend (mainly QString, QMap and QList) and it could be replaced with a std::string if one is motivated. There is no windows port yet, but I am investigating the porting of tinyQ on windows, to have at least the backend compiling.

GVim is a great editor so we will have a long way before competing with him. However, we have an easier to maintain codebase. We can not borrow code but we are probably going to implement compabilibilities features, like re-using the syntax highlighting files.

We are heading to Milestone 1 in one week. Wait and see...

Looking for an issue-tracking software.
I am looking for an issue tracking software for internal use in my company. I think our requirements can be summurized as following:

• issue can be a bug, a todo, a question or a request for enhancement. So this is not necessarily directly related to software.
• the status of the issue should be customisable or at least not too overwheelming. Bugzilla for example has too many status. Right now, we see only envision the following status: open, fixed, rejected, waiting on client.
• modifications to issues should fire a mail with the content of the modification and issue history.
• I need at least two and maximum three levels of classification for my products: product/version (two level) or product/component/version (three levels)
• Users should not have access to every products. Our clients should only see the bugs related to their products. So, I need some kind of access control on a per-product basis.
• issues have to be assignable
• It should be easy to sort and filter the issues by product, by assigned people, by version of the product.

Since we are a distributed group of people working from various places, including in the train to home, it is important to be able to deal with issues while offline. This brings two additional requirements:

• it would be nice to be able to submit issues by mail
• it would be nice to be able to follow the whole issue with only a mailer: replying to the issue will log the answer in the issue tracking software

To my surprise bugzilla is ruled out. It can only deals with software so there is no such thing as a 'question'. And it is not possible to simplify the interface and remove the 25 categories that can be assigned to a bug and the 38 ways of closing an issue. Moreover, the filtering capabilities are simply too complex to be used. In one sentence, it is not possible to turn bugzilla into a simple bug-tracking system. I deduce this from the doc and from all the websites using bugzilla. None of them has simplified it without a lot of efforts. I know that for KDE, it was not a simple task.

Right now, I am using issue-tracker but I can not say I am over-satisfied with it. It is not possible to filter the issues, only to sort them. With 7 issues in 7 categories, I have about 50 lines to analyse without any filter. I may miss some of them or spend too much time looking for one. Issue-tracker is supposed to support issue submission by mail but the administrator guide does not say anything about how to set it up. So it is not working for me. It is theorically possible to follow an issue by mail but the same problem for submitting the issue arises. Dunno how to configure that. Another problem is that mails that are sent when you modify an issue contain only a limited information, not the whole issue history. The software is obviously not written with disconnected people in mind. Apart from that, it is quite good. It was pretty easy to set it up, it is nicely configurable, it sends email when you modify something, there is an access control list for user actions.

So, I an looking for another candidate, if possible easy to install. Any suggestions ?

Looking for DLL system
I have been looking for a very small plugin system, that should be portable between linux and windows. There is only one function inside the plugin and I have full control on who writes the plugin and how it is written. Actually, the term plugin is exagerated, I just need a portable DLL loader. I am considering writing it myself, since the dlopen and GetProcAddress stuff does not look too complicated.

But I had a look on what I could find on the net. The closest thing I found was xplc but xplc is a component framework and I just need a DLL loader. Another search lead me (to my surprise) to glib and its gmodule. I did not know glib has a plugin facility. Hey, that's something Qt has not although there was a failed attempt with qlibrary. Anyway, since I work on windows and I want free as in beer software library for this small project, I can not use Qt. GModule seems to do what I need, so I investigate further.

First, I discover that glib has no homepage. Try www.glib.org and have some fun. developer.gnome.org hosts some API documentation bug the glib tarball is not available on ftp.gnome.org (or I could not find it), and it seems that they have never heard of windows port.

I wanted to browse the source of gnome and was surprised no to see any link to bonsai or lxr. I realised later that the link was hidden by some unreadable text, because developer.gnome.org renders ugly in konqueror (uh uh).

So, no glib source code for me, nothing known about windows, no place to download it. I google more I find gimp in win32 which seem to contain what I am looking for.

However, it seems that glib depends on gettext and libiconv. I am annoyed by this because of the usually poor windows portability or any linux program. Also, installing the whole glib + gettext + libiconv just to get DLL opening seems overkill to me. Other people working on my project don't like extra dependancies.

I also find out that www.gtk.org seem to be the home of glib. Glib seem to be inside gtk whereas I thought that glib was promoted to be indepentant of gtk (at least that's what I read on freedesktop). Ok, but what about my source code ? There seem to be no bonsai/viewcvs/lxr on www.gtk.org .

Since the documentation link points to developer.gnome.org, I checked again and this time, I found the bonsai link. I can finally browse the source on the web. This is exactly what I thought: the gmodule file is very simple and can be easily integrated into a foreign application without using the whole glib framework. Hurrah! It is LGPL so there is no consequence for my (closed source) application.

This also gave me the opportunity to read more about GObject. The whole thing is quite impressive. The developers have really put out a complete object framework. I think this kind of thing is unnecessary because you can find all the facilities provided by gobject directly in C++ but it does not diminish the quality of their work. Of course, because or the limitations of C, the syntax is awful. But that's common to most glib/gtk programs.

Regarding glib, I think it really deserves its own homepage, instead of being drown under gtk stuff.

Uraeus, I think you made a very good analysis of the KDE reaction to UserLinux. Gnome has had indeed some corporate endorsement recentely, which has certainly lead to some frustration in the KDE camp. UserLinux looked like a good opportunity to have KDE more present in the business world, even as second choice. But the decision was nowhere in our hand.

Anyway, the good news is that we have taken our own way, with already code being contributed for debian installers, endorsing sponsors, wonderful work of Alex Neudorf for Gtk and OpenOffice integration into KDE. UserLinux does not look to be moving that fast :-)

So all in all, it looks quite good for KDE's future in enterprise work. And we still have the possibility of returning to UserLinux of Bruce ever changes its mind.