Older blog entries for pfremy (starting at number 20)

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.

diff is unintuitive

diff is a tool you use without even thinking about it. Given its age, you assume it to be robust and to use the best algorithm. However, reading the documentation about python diff library, I discover that it produces unintuitive set of changes.

Let me show you.

This is a1.c :

if (a) {
	// x
} else {
	// y

This is b1.c:

if (a) {
	// z

if (a) { // x } else { // y }

How would you intuitively go from a1.c to b1.c ? Obviously, one has added a new statement "if (a) { // z }" in before the existing one.

However, if you pass it through diff, you will get:

--- a1.c 2003-04-29 13:28:15.000000000 +0200 +++ b1.c 2003-04-29 13:28:30.000000000 +0200 @@ -1,5 +1,9 @@

if (a) { + // z +} + +if (a) { // x } else { // y

According to diff, you have modified the inside of the then statement of the test by adding some content, which contains half of the new then statement, an end of statement and a new test.

Both results are correct. But one is more intuitive to the programmer than the other.

The diff library of python would produce the intuitive result. How come ?. The algorithm of the diff python library is to find repeatedly the Longest Common Subsequence (LCS) of both files, until all the common parts have been found. When there is no LCS left, everything remaining are differences. The common code "if (a) { // x } else { // y }" gets identified as common and the rest gets identified properly as difference.

The algorithm of diff is different. Basically, it scans the file as a stream for common lines. When it encounters a difference, it looks forward to find the next common lines. Everything in the middle is a difference. This is why diff has hooked the first "if (a) {" as common to both file and had included in its difference everything until the next common line.

So, don't trust your tools blindly. Although they may be old and respected and robust, someone can still do better. Anyone wants to rewrite to diff so that it produces the most intuitive result ? Given the importance of diffing in producing software, producing more intuitive diff is an issue.

Philippe Fremy

Qt and murrayc
I read your flame/debate with Guillaume.

You are at least obviously wrong about one thing. You stated multiple time that Trolltech would prevent you from porting Qt to windows or MacOs X.

Qt is released under GPL so there is no way Trolltech can prevent you from doing anything with it. You can twist the code the way you want as long as you stay GPL. And in fact, Qt is being ported on windows and Trolltech is aware of it. See: kde-cygwin.sf.net

Right now, the project require cygwin and X11 server. But there are plans to port Qt to native win32. I remember a project one year ago where a Mac hacker said he had the GPL Qt running on MacOs X in one day, and was planning to port it on MacOs 9 since it was so easy. Seems like he did not do it.

So you could prefectely wrap Qt using libsig++ instead of their signal/slot system :-)

Another thing that many people seem to miss is that Qt is GPL but if Trolltech does not release a new version in two years, it becomes BSD-licensed (see the FreeQt foundation) so you can use it in any kind of commercial close-source product . You get the same protection against 'what happens if the company goes bankrupt' as for any open source project.

A final point: I agree that you have no true development list for Qt as for other project. But their direct support is very good and they even provided it to me although I had no license (at that time). Some of my feature-requests have been taken into account and many of KDE's requests/problems are dealt with by Qt.

So the development is not as open as you could with but it does not prevent you from benefitting of the result. In fact, I would be ready to trade some openness of many open source projects for more stability/quality (with the source still fully available and modifiable of course).

Random thought
One thing cool with C code (and probably an advantage of native Gtk over Qt) is that compiles fast. Damn fast in comparison of C++ code. Add ccache power to that, you it compiles at the speed of printf.

You should really have a look at KPart and its internals. All the problems you describe have been faced and solved by KDE.

I understand the component activation is quite tricky, espcially if you plan to have two components displayed in a widget. Get in contact with David Faure and Simon Haussman (or simply kde-core-devel) to see if they can provide you some insights.

Slashdot interview
Scott Tape said in the Slashdot Interview:

In my experience, programmers like to write code. Period. They don't like to write documentation, they don't like to write system tests, and they don't like to write unit tests. Programmers are also optimists--how else could they tackle building these enormously complex systems and think they had any chance of working? Programmers like instant gratification (who doesn't?). They enjoy coming up with a solution to a problem and seeing that solution implemented immediately.

Because programmers are optimists, that is reflected in their unit tests. Time and time again I've seen developer-written tests that demonstrate the feature works -- because the tests reflect the thinking of the developer about how the feature will be used. They rarely do a good job of testing corner cases, limits, or "unusual" situations (like running out of memory or other finite resources). </blockquote>

While all the remarks are good, the conclusion that programmers will not enjoy test first methodology is wrong. To my surprise, I have enjoyed it a lot. Here are some arguments :

  • Programmers like to write code : programmers write even more code with test first methodology
  • Programmers enjoy solving technical challenges : building a system so that it can be fully tested is a technical challenge wich makes the test system as interesting to write as the code for the sytem.
  • Programmers enjoy instant gratification : having one's test run successfully is instant gratification and programmers enjoy it a lot. It may sound silly but I enjoy seeing my
     Result 37 / 37 successful test, 100% test pass
    . And I like seeing the number of test (== feature) moving forward. Means I am actually doing some measurable progress in my application
  • writing tests is boring : it is boring if you write them once the application is ready. If you write them before your code, it gets interesting because it is equivalent to writing code. At some point, writing the test gets more interesting than the code, because the code "just runs the test, you know, not very exciting".
  • corner case are not tested : in test first, it is recommended to test the corner case before the normal case. That way, they are a lot easier to deal with, and you are not tempted to skip them. Having plenty of tests already working also helps in building tests for corner cases. When it is just about calling 3 tests in a row and adding 10 lines of code, corner case testing is a lot more common.
  • Geeks like to achieve good work : Having the system running many tests successfully is rewarding. You know that your system is fully working and tested. It will be easy to maintain and extend. If you modify it, just runs the tests to check that it is still working. This is really reassuring.

11 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!