Pinderkent

Google's relatively new Web browser, Chrome, has generated a lot of interest since its initial release in September of 2008. It has managed to generate this even without native Linux and Mac OS X, although such ports are now in development.

Unfortunately, if this article from OSNews is correct, it appears that the developers at Google have opted to use GTK+ for the UI. The OSNews article does a good job of asking the obvious question: why not just use Qt for the Windows, Linux and Mac OS X versions of Chrome? The article suggests that Google opted not to use Qt, as they want to use native toolkits only, to allow for better integration with the host platform, and to avoid the warts that tend to accompany cross-platform applications.

I think that's a sensible policy. Mac OS X applications do differ in many ways from Windows desktop applications, both of which differ in many ways from X11 desktop applications. While cross-platform applications can be written that run on all three environments, they usually do feel somewhat out of place, and awkward to work with at times. However, it's too bad that Google has opted to consider GTK+ as the "native" toolkit for their Linux port, instead of using Qt, even if they opted to use the native UI functionality of Windows and Mac OS X for those versions.

It's difficult to give quantitative measures when comparing UI toolkits. So we'll need to rely on more qualitative analysis. Thankfully, GTK+ and Qt have both been used as the basis for a large number of popular open source applications that we can analyze.

One such way to qualitatively compare toolkits is in terms of responsiveness. And this is one area where Qt is often much better than GTK+. Qt-based applications often feel noticeably more responsive than similar GTK+-based applications. We can see this when using Kate and gedit. Kate is a text editor for KDE, while gedit is currently the official text editor of GNOME. Both are similar in terms of features and functionality, but I have always found Kate far more enjoyable to use that gedit. Gedit has a laggy feel to it, when opening menus, working with various dialogs, pasting in significant amount of text, scrolling through large files, and so forth. Kate, on the other hand, has always felt very fast; there is typically no noticeable delay between invoking a particular action, and the results of that action being available.

In relation to Chrome, a more apt comparison would be between existing browsers that use GTK+, and browsers that use Qt. Thankfully, we have several examples we can use. Epiphany is a Gecko-based browser coming from the GNOME project, and uses GTK+ for its UI. Many builds of Mozilla Firefox for Linux also use GTK+ as the underlying toolkit. On the other hand, we have Konqueror from the KDE project, and Opera, both of which use Qt.

An employment opportunity over the past six months has resulted in me making extensive use of all four of those browsers, on a variety of different PCs running various Linux distributions. After all of this use, I have to say that I've found Opera and Konqueror to offer the most pleasant Web browsing experience. While Epiphany and Firefox aren't bad browsers, they've always felt bloated. This isn't the feeling that one gets with Opera, for instance. And while we can't attribute their responsiveness solely to the underlying UI toolkit, it does help that Konqueror and Opera are both built on a solid Qt foundation. Pages appear to render faster in both, scrolling is much smoother, the browser menus and dialogs open without delay and can be manipulated without flicker, and both Konqueror and Qt feel like more polished, professional software products than Firefox and Epiphany do.

So based on my experience using other Web browsers that make use of GTK+ for the UI, I have not been very impressed. Qt-based browsers like Konqueror and Opera offer a much more enjoyable experience. Given Chrome's emphasis on providing a speedy and stable browser, Qt seems like the natural choice. The developers of Qt have put a lot of effort into making their toolkit one of the fastest out there, and this is reflected by the responsiveness of the applications that make use of Qt.

Qt also seems like a better fit for Chrome. Much of the source code for Chromium is implemented in C++. Likewise, Qt is also written in C++. But GTK+, on the other hand, is written in C, using pseudo-OO techniques. Integrating the Qt object model with that of Chromium may not be straightforward, but it likely would be cleaner than trying to integrate GTK+'s object model.

In terms of licensing, the recent announcement from Nokia that Qt 4.5, expected for March, would be available under the terms of the LGPL should make it much more appealing. Chromium already makes use of LGPL'ed software, including the essential WebKit. So while the licensing of Qt may have been a valid concern in the past, this no longer seems to be the issue it might have been.

One benefit that Opera has offered for some time now are Linux binaries that are statically linked against Qt 3. Although this can bring in the various problems associated with static linking, it does greatly reduce dependency-related problems. The user doesn't have to install Qt 3 themselves, whether from source or via the package manager of their distribution of choice. Assuming the licensing could be worked out, it would be helpful if static binaries of Chrome for Linux were available, to make installation more straightforward.

So while GTK+ will no doubt suffice as a toolkit in this case, it is too bad that Google opted not to use Qt. In many ways, Qt appears to be a better choice, and would help allow Chrome become a responsive, stable, high-quality browser for Linux. Like the OSNews article points out, a Qt-based implementation of Chrome may need to be written by the community, rather than by Google. I hope it doesn't come down to that, but it seems that Google has made up their mind and will use GTK+ for the time being. So those of us who prefer a Qt-based browser may need to just stick with Opera and Konqueror for now.

Today I saw a post that Hans-Eric made to his blog on Monday about Delphi 2009. He seemed quite pleased with it, specifically mentioning its support for anonymous methods.

The last few years haven't been particularly good for Delphi. Many people reported stability problems with Dephi 8 and Delphi 2005. Things got better with the release of Delphi 2006, but soon there arose uncertainty due to Borland's attempt to sell it off, along with some of their other software products. That wasn't entirely successful, so they spun off CodeGear, which was eventually acquired by Embarcadero. Delphi 2009, however, does seem to be bringing some comfort and certainty to the community.

Delphi 2009 includes some interesting new features. It apparently now has much better Unicode support, as well as support for generics. It also has support for anonymous methods, as pointed out by Hans-Eric. These are the sort of features that Delphi will need in order to compete with Java, C# and VB.NET.

Unfortunately, I'm not sure how much traction Delphi 2009 will gain with hobbyist or amateur developers. For such users, even the Delphi 2009 Professional edition would likely prove to be quite costly. It's difficult to justify such expenditure, especially with free IDEs like NetBeans, Eclipse, and #Develop available for some of the other popular languages. There is a trial version available, so at least it gives a way for new users to give it a try.

I would like to see Delphi more widely used. In the past I've worked with software written in Delphi, and it generally tends to have higher quality code than one often sees from applications written in VB.NET. Indeed, it sounds like Delphi is headed in the right general direction with this latest release. I hope that it can generate more interest, and become more widely used, if only just to bring slightly more diversity to the Windows software development scene.

I saw a Reddit thread today asking if anyone had ever met a J# developer. For those who may be unaware, J# is a Java-like language for .NET.

To answer the question posted to Reddit, yes, I have seen projects that use J#, and I have worked with developers who use J#. Most of the projects using J# did so in a transitionary nature. They were systems originally developed in Java, and the company had decided to move to .NET for whatever reason, but did not wish to immediately rewrite portions of their existing software infrastructure. So J# was used to allow interoperability with the new code often written in C#.

I did work very briefly with one company who was having a team in India develop some applications for them, and the Indian team chose to use J#. Like many outsourced applications, they barely worked and didn't really do what the user needed, but management didn't seem too concerned. Some of their in-house .NET developers were pretty adamant that C# should have been used instead, but management saw no reason to move away from J#. I'm not really sure what became of those applications; they may have only been used briefly. That company was pretty dysfunctional, so I've avoided working with them since.

During a conference call I participated in with the team in India, it was asked why they chose to use J#. Their response was that Java was better known than C# at that time, and it was easier for them to find a Java developer and train him to use J# than it was to find a C# developer. They also claimed to have done many other projects in J#, and that it was the best language for their developers to use. Their justification never made much sense to me at the time, given the similarity between Java and C#, and C#'s better integration with the .NET platform.

Given that J# was developed in Hyderabad, it is possible that it was easier for them to find people acquainted with the language. But for the development of new software, it did not seem like a sensible choice. This is especially true now that Microsoft has opted to retire it. Even when transitioning existing Java code to .NET, it's probably better just to go straight to C#. So the need for J# developers is arguably very small to begin with. And even if J# code does need to be maintained, an average C# or Java developer should be able to do it naturally enough given the similarities between the three languages.

It's a mistake to think that unit testing is only about preventing bugs. As such, it's also a mistake to measure the usefulness of writing unit tests in terms of the number of bugs found. Unit tests are a preventative measure, both when initially writing a piece of code for the first time, and for ensuring that future changes have not broken it in some way.

Of course, I'm not the first to point this out. But it's unfortunately a concept that is missed by many in the software development field. Many such developers have difficulty thinking about the "intangible" aspects of automated unit tests. All they're immediately aware of is the time and effort it took to implement the unit tests. But they don't realize how the act of developing the unit tests made them consider to a greater extent how their unit of code would eventually be used. In proper test-driven development, the developers would get a better sense of how their unit's API should be structured. If they're good developers, they would also have put more consideration into how corner cases would be handled. And once their unit tests are implemented, the ability to run them continuously against a changing code base becomes invaluable, especially when regressions are caught rapidly.

Such developers can easily track the number of hours it took them to write the unit tests. They can easily track the number of lines of code making up those tests. But it's harder to quantify the greater familiarity and greater understanding they gain regarding the unit under test. It's also difficult to quantify the time and expense saved by catching regressions as early as possible, often within seconds of some new or modified code being committed to the source code repository. And then there's the software developer's reputation, be that developer an individual or a large company, which can be greatly improved by providing software that is generally bug free.

Often, the benefit brought by the more intangible and abstract aspects of unit testing far outweigh whatever time and effort is put into developing the unit tests initially. Remember, if a unit test that took a few minutes to write catches even one regression, the savings can be enormous. Many times in the past I've seen days upon days of effort, in terms of debugging, patch preparation, patch testing, patch deployment and customer appeasement, needed to fix a bug that could have easily been caught with three or four assertions and perhaps eight to ten lines of unit test code.

Jonathan Giles recently wrote an article about what he thinks is needed for the next generation of Swing. Apparently Danny Coward of Sun became aware of that article and the discussion it generated, because he wrote an article discussing Sun's stance. Unfortunately, they don't seem to see the need for a replacement for Swing any time soon. Their focus seems to be on JavaFX.

In turn, Giles has written a response that discusses Coward's article. He makes a good point, stating "a Swing 2.0 brings with it reinvigorated development and a pre-release mentality to perfecting APIs, instead of simply maintaining them. Given the current state of cross-platform desktop GUI API's, I still think Swing has a great chance of being hugely popular for the foreseeable future." Indeed, he is quite correct.

It's unfortunate that so much focus has been drawn away from more traditional desktop applications, towards AJAX-based Web applications and rich Internet applications. Many of us developers are dismayed at the attention and hype that Sun has been putting towards JavaFX. The main problem is that for many applications, these Web-based technologies are just not suitable.

One example I can think of right away comes from some work I did last year with a company that was developing a specialized point-of-sale software system. They investigated these Web-based technologies, and found that they had a number of problems. One of the main problems was the delay between an operation being performed by the POS terminal operator, and the result being displayed. Even using various AJAX-based techniques proved useless for solving this problem.

Another problem was that these Web-based apps couldn't easily interface with certain specialized scanning devices that were to be connected to the terminal. That's understandable, as most RIA technologies go out of their way to isolate the app within the Web browser as much as is possible.

That development team ended up falling back on wxWidgets. They needed to develop an actual desktop application, because the Web-based technologies they tried were woefully insufficient. Given that most of their back-end systems were written in Java, I'm sort of surprised they opted to not use Java for the front-end, instead going with C++. I'll have to try and contact one of the developers there to find out why the decision was made to go with C++ over Java.

I know of a number of other companies and organizations who have considered using Web technologies for applications they needed, but ended up falling back on normal desktop apps for the reasons outlined above. Many times they needed very responsive systems to allow for more pleasant customer experiences, while in other cases the Web-based technologies just weren't capable enough for the applications that were needed. In other cases, the Web-based technologies proved more inefficient for the developers, resulting in longer development time, with more effort needed when debugging issues.

In any case, I think it's clear that Web-based applications may be suitable for many tasks, but they are by no means a suitable replacement for all desktop applications. There is still a need for a high-quality, cross-platform UI toolkit. Many have chosen to use Swing in the past, but it is now showing its age. So some of them are using C++ along with toolkits like wxWidgets instead.

Many of the new language constructs introduced with Java 5 go a long away towards improving the design and quality of the software that uses them. Enums and generics are two of the most important, and both would prove very useful throughout Swing. It's a shame that Sun put so much effort into getting them into Java, only to avoid using them in some of the more important libraries.

It's also a shame that they put so much emphasis on JavaFX. I can't say I've really felt any significant community excitement around it, whether online or with the developers I've talked to. I recall several of the people having a rather negative attitude towards JavaFX Script. Based on my limited experience with JavaFX, I'd have to agree. It feels like a step backwards, rather than something that'll make our lives easier, and make our software better.

Even though he seems to have no intention of starting a Swing 2.0 project, Giles has requested there be more discussion on the topic, to try and better determine what would be needed for such a development. And perhaps if we are lucky, Sun will come to realize the importance to many users of actual desktop applications, rather than RIAs, and the need of quality development tools and libraries, like Java and Swing rather than JavaFX Script and JavaFX.