Older blog entries for pfremy (starting at number 25)

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.


I was pointed to a Gnome blog where it is said that the KDE name has been dragged into mud by the reaction on the UserLinux list.

I agree that there have been overreactions on the UserLinux list, from some KDE people. However, I find the blog unfair in the sense that it only talks about the bad aspects of KDE, those overheated discussions on UserLinux. We took a great time to prepare a clear, argumented and constructive proposition: http://desktop.kdenews.org/strategy.html

But it seems that nobody has taken care to read it or to take it into account when they talk about KDE and UserLinux. There has also been a lot of argumented postings, not only from KDE people, whose concerns about UserLinux have still not been answered.

I think the reaction on UserLinux are strong because, like many free software developers, we are passionate at what we do and UserLinux sounded like an exciting project. However, the rules were not written in the original paper. What sounded like a community based project where choices would be dabeted and argumented turned out to be a dictatorship project. Bruce said that some part of the project would be community-based, but I have the feeling that the only community-based decision ever accepted will be the one that follow the opinion of Bruce.

I am expecting more frustration on the UserLinux list. For example, people are debating about a name, but I expect Bruce to come back and said that he never intended to change the name, so all the people who have voted can all go home.

I would love to be surprised though.

After discussing a bit on UserLinux's mailing list, it turns out that Bruce does not want to discuss any of the choices made for the distribution.

So, what started as a probably community distribution toward the enterprise turns out to be a dictatorship distribution where choices are made without any rationale. What an irony for a distribution that is based the debian, the community driven distribution.

The particular subject of discord is the fact that the distribution will be Gnome centric, to the point where KDE is not recommended (but still included). The arguments supporting a distribution based on both KDE and Gnome have been ditched away with a "the decision is already taken", without bothering to give any explanation on the choice of excluding KDE.

Forget that KDE had a very significant impact on the fact that Linux can now afford to be an enterprise desktop. Forget that in Europe, the standard is KDE and you won't sell an enterprise distro if it is not based on KDE. Forget that many ISV already have chosen Qt despite the licensing price.

UserLinux is actually BrucePersensLinux. For those that doubted it, Bruce said it clearly. Don't expect any democraty there.

KDE/Qt - Gnome/Gtk

I had this though for a long time. Although I believe Qt is superior to Gtk, there seem to be more innovative projects done using Gtk: there was no equilvalent to gimp, GnomeMeeting, AbiWord, Gnu Cash, Gnu Spread or sodipodi before they were started. And all in Gtk or Gnome. There is also the CD burning app (don't remember the name).

Apart from a few very ambitious applications, like KOffice and Konqueror, KDE seem to have tackled common applications. KMail and Konqueror for example are very good but we already had a mail client and a browser before. All vector drawing program (Karbon14, Krita) seem to have a hard time becoming usable.

However, there seem to be more and more applications that are better than the original one they were copying. Maybe it is just a subjective impression but it is mine.

5 Oct 2003 (updated 25 Apr 2006 at 11:20 UTC) »
Gnome Wrapping

I just found this link on the Gnome website, which I find very funny: http://developer.gnome.org/doc/guides/wrapper-friendly-api-guidelines/wrapper_friendly_api.html

Basically, if you want your code in Gnome to be easy to wrap, you should write C++. Maybe that is why we never had this issue in KDE.

Some more reflections about writing a wrapper for Qt/KDE or Gnome/Gtk:

  • Every language has some libraries to access C code. So wrapping C code for another language is easy. Wrapping C++ is more complicated. That's why there were so many Gnome wrappers and so few KDE wrappers
  • While producing a wrapper is quite easy for C, maintaining it is very burdensome, because every maintainer must add manually all the wrapping code. As gnome and gtk evolves, this turns out to be quite painful. This why many wrapper only do gtk and/or wrap old versions of Gtk or Gnome.
  • While producing a wrapper for C++ is initially harder, once you have done it, you can automate most of the task. That's why KDE wrappers are quite up to date, as comparisons to Gnome's. The paper also points out why it is difficult to automate the wrapping of Gtk/Gnome widgets: because the intent of the programmer is not expressed in the language. Is this member public or protected ? Macros break everything but Macro are part of the gnome type system.
  • Since KDE is written in a higher language than Gnome, there is less need to program in another easier to use language.
15 Sep 2003 (updated 25 Apr 2006 at 11:22 UTC) »
Python is so cool. It is the first time I can use it that much in a project and I really enjoy it. The big difference with C++ comes in small things, like when you almost have what you want but you need to parse a small file, or transform a small expression.

I had the sudden need of managing a .ini style file, to store keys for the card. 10 lines of RegExp and 20 lines of tests solved my problem in 15 minutes. Then few days later, I need to change the file in place. Just 10 mores lines of tests, 5 mores lines of python and I'm done. I know I would have spent a lot of time in C++ do handle this crap.

The real problem with python is that you can not dispense with the tests. I tried yesterday. Then today, my code broke on an exception. You really have to run the code through all the possible case because your program can simply stop on unexpected exceptions.

I see the defenders of Java advertising their safe exception handling. Java is probably suited for big projects does not make it for middle size or small projects. And the safer way of handling exceptions does not remove the need to write tests. So, all in all, you write the same code, but it is more painful in Java.

I made a 75 minutes interview with Eirik Eng, CEO of Trolltech. The problem is now to transcript it into text. Transcripting 5 minutes of interview takes 1 hour. So I have 15 hours of work ahead of me. I don't think I will be able to publish it anytime soon.

Anyone willing to help ? I have some 5 minutes ogg vorbis files ready to be sent.

Gnome 2.4
I read some people really enthusiasts about the fact that Gnome 2.4 is compliant with the HIG (Human Interface Guildelines), some people citing it as a core improvement. If I were them, I wouldn't insist too much on that. It means than for 4 years, Gnome was not that much compliant with its HIG, nothing to be proud of.

On the other side, KDE has always been compliant with its HIG. The only thing that was a problem is that the HIG would recommand SDI while some applications (Kate and KDevelop) use MDI. I think the SDI recommandation has been removed now.

Wonder why KDE had no problem with this ? Because 98% of the HIG compliance is achieved by the KDE Libraries. In Gnome libraries, this same number used to be very low, which means that programmers had to achieve compliance manually, all of them in their slightly incompatible way. Actually, one of the improvement of Gnome 2.4 (if I understand correctly) is that HIG compliance will be made easier because some stuff finally enter the library. It's never to late for Gnome to catch on KDE. :-0

Hopefully, there are real improvements in Gnome 2.4 but I always enjoy nitpicking.

16 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!