Lazarus cross platform and cross widget set example

Today I read a news item on the Lazarus site about a SI_Browser, a simple DICOM viewer. I didn't know what DICOM was, but google led me to the wikipedia article about it.

At the bottom of the site, I found a familiar link about the MRIcron DICOM viewer. I knew MRIcron is built using Lazarus; Chris Rorden, the developer, has made and paid several successful bounties to support MRIcron and Lazarus.

The actual reason I write this post, is the installation page of MRIcron. MRIcron is a Lazarus application that really shows the strength of Lazarus cross platfrom and widget set support. Chris offers MRIcron in 8 differenent flavours:

• Windows (WinAPI widgetset)
• Linux
• 32-bit (QT widgetset)
• 32-bit (GTK1 widgetset)
• 32-bit (GTK2 widgetset)
• 64-bit (GTK1 widgetset)
• 64-bit (GTK2 widgetset)
• Macintosh OSX
• OSX 10.4 or later (Universal binary, Carbon widgetset)
• OSX 10.3 or earlier (PowerPC, GTK1 widgetset)

Chris, thanks for showing the power of Lazarus.

Lazarus 0.9.26 tagged

Today I tagged the 0.9.26 version of Lazarus. In the coming week we will do the release building, some testing and preparing the announcement.

Lazarus svn trunk now contains version 0.9.27 and there is a new fixes_0_9_26 branch with 0.9.26.1.

SVN and the bug tracker: a powerful team

This morning an issue was reported that using the win32 widget set,"RadioButton changes its state (becomes checked) when selected with Tab key". I could reproduce the issue easily and I remember that I had seen some code in the win32callback.inc file that sets the radiobuttons explictly using the BM_SETCHECK message. In Lazarus, I used Find in files searching in the lcl\interfaces\win32 directory, I found the piece of code rapidly, the WM_SETFOCUS handler around line 2084. The next step was to use svn annotate on the file, which returns the file with a note in which revision the lastest change has been made and by who. Then the patch and the log message are just a mouse click away:

moved checking of radiobutton to wm_setfocus, so keyboard action is handled too (issue 1171)

Now, resolving this report is easy. Either closing it as won't fix: it is as designed or revert the change of revision 8017. The hard part is to decide what is the best behavior.

Without using SVN or bugtracker, all this would depend on people's memory. I would not have remembered it after almost 3 years. The most important lesson for me, is that it showed how vital it is to put the issue number in the svn log message, otherwise you loose the track from change in source to bug report.

Lazarus 0.9.26 release preparation

The list of open issues for Lazarus 0.9.26 is getting smaller by the day. Most are fixed. Some are re-targeted to 0.9.28, if we estimate it takes too long fix them now. Some are re-targeted to 1.0.0, if closer inspection turns out the bug is not a regression.

Some issue are in the status feedback. This means that the Lazarus developers are waiting for information from the issue reporters to be able to fix the issue or for confirmation that the bug already has been fixed in the meantime. I'd like to ask people who have submitted bug to check their reports and give the necessary feedback.

Translators are requested to check the translations for new or modified strings, so we can release Lazarus with up to date translations.

FPC 2.2.2 released

FPC 2.2.2 has been released. In the coming time we will focus on fixing the regressions in Lazarus 0.9.25 and release 0.9.26. There are still about 15 issues to be fixed.

If you don't want to have nasty surprises, when Lazarus 0.9.26 is released, grab one of the snapshots and test it.

Amazing features in 0.9.26

I don't remeber any release which excited me so much like the not yet finished 0.9.26. The reason is that many great features which were once a distant dream are now ready from becoming reality. I will describe some of them bellow.

* Windows Unicode support, even in Windows 9x. This is a very strong feature, which will take Lazarus much closer to having full Unicode support in all our supported platforms, something indispensable for any modern GUI Library. This allows us to show in the same application Russian, Portuguese and Chinese, for example, regardless of the Windows locale. Having Windows 9x support with the help of some testers puts us ahead of many other GUI Toolkits that dropped Windows 9x. Extended information for users can be found here.

* Native Mac OS X version with the Carbon widgetset. Yes, no more X11, no more Gtk under Mac OS X. A native IDE instead, which can be launched form the Dock and integrates nicely into the system. Copy+Paste, Debugging, everything works in the new Mac IDE. I expect this to boost Lazarus popularity under Mac OS X. In the long term a Cocoa interface is being developed, but the Carbon IDE should be more the enough in the next 1-2 years.

* TIcon.Handle finally working. This is also a long awaited feature, and should help removing some necessary ifdefs when using TTrayIcon, which needs TIcon.Handle to work.

* A much better Windows CE interface. Lazarus 0.9.24 was the first release supporting Windows CE, but many bugs were present at the time, making it somewhat problematic to develop real applications. In Lazarus 0.9.25 we have made a great work polishing the Windows CE interface, and this new release will push it to a new level, making it ready for the development of high quality applications. For some screenshots and extended information of the work being done, take a look here

* Tons of bugfixes

The final feature, which would make Lazarus finally ready for 1.0 (just my opinion! I know others disagree) is unfortunately not in this list. It would be the retirement of the Gtk 1 widgetset, and the move to a fully unicode and modern Linux Toolkit. I have worked a lot in the Gtk 2 widgetset, trying to get it to a development level where it could substitute Gtk 1, but I got really frustrated, partly because of the low quality of the mixed gtk1/gtk2 interface code, but also because Gtk just doesn't help. Having worked with the Windows API, Qt, fpGUI, Cocoa and Gtk, I am absolutely sure that Gtk is the worse GUI toolkit I have ever seen. Yes, even worse then direct Windows API, because at least the Windows API works!

The final shot in Gtk 2 for me was the fact that the Qt 4 interface, which I started 2 years ago just to learn how the LCL worked inside, managed to become much more reliable then the Gtk 2 interface which was already being developed a long time before, and without the support of most core developers! (Paul is the only core developer doing heavy development in Qt). Unfortunately Qt is not LGPL, and we expect to support the development of proprietary applications without the need to buy licenses, so Qt cannot substitute Gtk =/ At the moment I believe that fpGUI is the widgetset with the highest changes to substitute Gtk 1. The highest obstacles are the lack of developers and fpGUI being still under development, which makes it's API not so stable, but I really believe this path may have a great future.

A small comparison of the development difficulty in each widgetset:
Implementing TTrayIcon under Windows API: 4 hours
Implementing TTrayIcon under Qt: 3 hours
Implementing TTrayIcon under Gtk 2: 2 *weeks*

Concluding, I had originally planned for 2 posts, 1 about the great new stuff in 0.9.26 and 1 ranting about Gtk, but I managed to cover both topics here =D In conclusion I think we are reaching a new milestone, a new development level, but our official Linux interface (gtk 1) is unfortunately limited and we have no good enough substitute yet.

FPC 2.2.2 RC1 released

The first release candidate of FPC 2.2.2 has been released. The Lazarus team is waiting for the release of FPC 2.2.2, because it needs it for the Unicode support for the win32 widget set. We intend to release Lazarus 0.9.26 soon after FPC 2.2.2 has been released.

People who want to test this release candidate with Lazarus, can download a Lazarus snapshot. The last week have replaced all fpc 2.2.0 based snapshots with fpc 2.2.2rc1 based snapshots.

Don't wait too long with testing, because 30 June will start the code freeze in preparation of the RC2. Hopefully this is the final release candidate for FPC 2.2.2, so we can have a FPC release before the end of July. Another release candidate will delay the release about a month. So test well, and report any regressions before the end of June.