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.
Wednesday, June 25, 2008
Thursday, June 19, 2008
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.
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.
Wednesday, May 14, 2008
New 0.9.26 features. Part 2. ImageList effects
I think that almost nobody knows that internally the LCL TCustomImageList contains an array of 32 bit (rgb + alpha) data. In this array the imagelist stores images in the best quality. When it is needed the imagelist use this array to create a widget set imagelist (at this moment this is only the case for the win32 widget set) with the best possible quality. Any time we can access the 32 bit image data and we can do any manipulation with it. If you ever worked with image data you should know that 32 bit data is one the easiest formats for manipulations.
But what manipulations do applications (controls) usually need? The most often used manipulation is the transform from multi-color to gray image. It is used for example in menus and bitbtns (a button with an image). The next two often used manipulations are image highlighting and shadowing, which are also used in menus and buttons.
So I added TCustomImageList.Draw(... ADrawEffect: TGraphicsDrawEffect) and TCustomImageList.GetBitmap(... AEffect: TGraphicsDrawEffect).
But what manipulations do applications (controls) usually need? The most often used manipulation is the transform from multi-color to gray image. It is used for example in menus and bitbtns (a button with an image). The next two often used manipulations are image highlighting and shadowing, which are also used in menus and buttons.
So I added TCustomImageList.Draw(... ADrawEffect: TGraphicsDrawEffect) and TCustomImageList.GetBitmap(... AEffect: TGraphicsDrawEffect).
At this picture you can see all effects currently supported by the imagelist. And this is the description:
Of course, these imagelist methods can be useful not only for menus and buttons - you can use them for your own controls and other needs too. And we hope you will do that. :-)
- Normal - no effect. You get an original image without any transform.
- Disabled - gray image. Red = Green = Blue. We get every component value by the following formula: (Red + Green + Blue) / 3.
- Highlighted - a bit shining image. To achieve shining we alphablend the original image with white.
- Shadowed - opposite of highlighted. To achieve shadowing we alphablend the original image with black.
- 1Bit - this effect is used for drawing bitbtn glyphs in windows applications with no theme support. Windows just cannot draw gray images - they can use only 3 colors on a button: clBtnFace (transparent), clBtnShadow and clBtnHighlight. To support disabled bitmap drawing on such buttons we have added this special effect. We are using a special formula to achieve sharp edges in order to save all image details.
Of course, these imagelist methods can be useful not only for menus and buttons - you can use them for your own controls and other needs too. And we hope you will do that. :-)
Sunday, February 10, 2008
GTK2 planned not before Lazarus 1.2?
Sometimes people ask: Why don't the Lazarus developers want to fix the gtk2 bug before Lazarus 1.0?
The Lazarus developers have limited resources, so in order to have Lazarus 1.0 sooner rather than later, some decisions were made to reduce the work load (scope) for Lazarus 1.0. Some of this is mentioned on the wiki.
Basically, this means we think that no new features are needed for Lazarus 1.0. That doesn't mean that there will be no new features until then, but that we won't delay the release of Lazarus 1.0 because of it.
The gtk2 interface could be regarded as a feature too, because in most cases the gtk1 interface works just fine or better (except it looks dated). I must admit it is getting more troublesome recently, because some distroes now ship with gtk2 only. Currently the gtk widgetset is more stable and has less bugs with Lazarus than gtk2. Until that situation has changed gtk1 will remain the default. As soon as gtk2 is better (i.e. less bugs and more stable) than gtk1, it will come the default. But this is no priority for the Lazarus team, it rather focuses on other bugs.
Fortunately Lazarus is open source and with your contributions you can steer the path of Lazarus. For example Andrew Haines and Ales Katona understood that and have contributed a lot of gtk2 patches, trying to improve the gtk2 widgetset, so that it become the default for Lazarus 1.0. If a couple of other people start helping, I have no doubt that Lazarus 1.0 will eventually be with gtk2.
The Lazarus developers have limited resources, so in order to have Lazarus 1.0 sooner rather than later, some decisions were made to reduce the work load (scope) for Lazarus 1.0. Some of this is mentioned on the wiki.
Basically, this means we think that no new features are needed for Lazarus 1.0. That doesn't mean that there will be no new features until then, but that we won't delay the release of Lazarus 1.0 because of it.
The gtk2 interface could be regarded as a feature too, because in most cases the gtk1 interface works just fine or better (except it looks dated). I must admit it is getting more troublesome recently, because some distroes now ship with gtk2 only. Currently the gtk widgetset is more stable and has less bugs with Lazarus than gtk2. Until that situation has changed gtk1 will remain the default. As soon as gtk2 is better (i.e. less bugs and more stable) than gtk1, it will come the default. But this is no priority for the Lazarus team, it rather focuses on other bugs.
Fortunately Lazarus is open source and with your contributions you can steer the path of Lazarus. For example Andrew Haines and Ales Katona understood that and have contributed a lot of gtk2 patches, trying to improve the gtk2 widgetset, so that it become the default for Lazarus 1.0. If a couple of other people start helping, I have no doubt that Lazarus 1.0 will eventually be with gtk2.
New 0.9.26 features. Part 1. SendMessage and PostMessage
If you ever wrote some big application or component, I am sure you met the problem of postponed execution of some code. Delphi programmers usually used 2 solutions: timers and Windows message system abilities. This article is about message system approach. Note that Lazarus has a third solution: Application.QueueAsyncCall.
I suppose you already know something about the Windows message system. And you are familiar with SendMessage and PostMessage commands. They are used to deliver messages to controls. SendMessage sends message dirrectly to control window procedure. PostMessage adds message to the message queue, so control will get it only after processing all other pending messages.
Group of message numbers from 0 to WM_USER are used by Windows itself. So if you want to use message system in personal purpose you should use message numbers >= WM_USER.
Lets return to Lazarus where you want to indirectly perform some actions. Very usual task is when you need to destroy some control (your form for example) in event handler. Ofcource your application crash if you call Free in event handler - so you need to call Free somehow after event handler. But how? Call PostMessage in event handler and process posted message in message handler.
Delphi example:
If you used similar constructions in Delphi, you should know that they did not work in Lazarus. In the win32 widgetset code all WM_USER messages were blocked for some reasons:
- other widgetsets had no support for PostMessage and SendMessage
- few WM_USER messages were used by Windows and cause errors in LCL
After releasing 0.9.24 we reevaluated our decision since gtk and qt supported PostMessage and SendMessage. Then an implementation for Carbon appeared. Of course it would be a joke to block messages under Windows when all other widgetsets (where messages are aliens) support them. Now you can use PostMessage and SendMessage with few limitations:
- use Message numbers >= LM_USER
- sending messages outside application does not work (you cannot send message to another application)
And the last - if you need example - look at lazarus\examples\messages.
I suppose you already know something about the Windows message system. And you are familiar with SendMessage and PostMessage commands. They are used to deliver messages to controls. SendMessage sends message dirrectly to control window procedure. PostMessage adds message to the message queue, so control will get it only after processing all other pending messages.
Group of message numbers from 0 to WM_USER are used by Windows itself. So if you want to use message system in personal purpose you should use message numbers >= WM_USER.
Lets return to Lazarus where you want to indirectly perform some actions. Very usual task is when you need to destroy some control (your form for example) in event handler. Ofcource your application crash if you call Free in event handler - so you need to call Free somehow after event handler. But how? Call PostMessage in event handler and process posted message in message handler.
Delphi example:
const
MY_MESSAGE = WM_USER + 1; // <-- your message number
type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject); // <-- some event handler
private
procedure MyMsgHandler(var Message: TMessage); message MY_MESSAGE; // <-- message handler
end;
...
procedure TForm1.Button1Click(Sender: TObject);
begin
... //code before
PostMessage(Handle, MY_MESSAGE, 1, 0); // <-- here you post message to message queue
... // code after
end;
procedure TForm1.MyMsgHandler(var Message: TMessage);
begin
Free;
end;
If you used similar constructions in Delphi, you should know that they did not work in Lazarus. In the win32 widgetset code all WM_USER messages were blocked for some reasons:
- other widgetsets had no support for PostMessage and SendMessage
- few WM_USER messages were used by Windows and cause errors in LCL
After releasing 0.9.24 we reevaluated our decision since gtk and qt supported PostMessage and SendMessage. Then an implementation for Carbon appeared. Of course it would be a joke to block messages under Windows when all other widgetsets (where messages are aliens) support them. Now you can use PostMessage and SendMessage with few limitations:
- use Message numbers >= LM_USER
- sending messages outside application does not work (you cannot send message to another application)
And the last - if you need example - look at lazarus\examples\messages.
Friday, December 28, 2007
Lazarus fixes branch
While working on Lazarus 0.9.23, which took more than 6 months, Giuliano Colla proposed to create a stable branch. Lazarus development goes very rapid with about 100 commits each week and with each daily update, there is a reasonable chance that something got broken. This is not desirable for people that need to do production work with Lazarus.
The idea was welcomed, although I had some doubts about the feasibility, especially the man power needed. Lazarus development goes rapid and there is still a lot to do, so the current Lazarus developers can better spend their time on new development than on maintaining a stable branch. So, we offered Giuliano to maintain it him self and we would support him.
After the Lazarus 0.9.24 release in November, I created the fixes_0_9_24 branch and set the version number to 0.9.24.1. Windows snapshots using fpc 2.2.0 and the fixes branch are created on a daily basis from ftp. Giuliano would send me a list of revision numbers to be merged and I would apply thoses merges to the fixes branch. After a couple of merges, the branch became 'super'-stable, because there were no changes. A lot of changes are related and Giuliano wanted to test them before applying. This takes a lot of time. Also, it is sometimes not trivial to see the dependencies between the different revisions, espescially if a revisions contains new functionality, that you don't want to merge and a simple fix that is needed when you want to merge a later bug fix revision.
So we are still struggling to find a good strategy for maintaining the fixes branch. In the last week, I took a different approach. I looked at the list of revisions and merged the new component bar images, splash screen and most the bug fixes I made in Lazarus 0.9.25. Almost 200 revisions were merged from trunk to the fixes branch, so things might have been broken, but I have good hopes that 0.9.24.1 is at least as good as 0.9.24.
There are still about 500 revisions in trunk not (yet) merged:
I encourage everybody to test the fixes branch and give feedback on the Lazarus mailing lists. If the fixes branch proves succesfull (stable updates without occassional breakage), I am considering to put snapshots of it in the Lazarus-Testing Ubuntu repository.
The idea was welcomed, although I had some doubts about the feasibility, especially the man power needed. Lazarus development goes rapid and there is still a lot to do, so the current Lazarus developers can better spend their time on new development than on maintaining a stable branch. So, we offered Giuliano to maintain it him self and we would support him.
After the Lazarus 0.9.24 release in November, I created the fixes_0_9_24 branch and set the version number to 0.9.24.1. Windows snapshots using fpc 2.2.0 and the fixes branch are created on a daily basis from ftp. Giuliano would send me a list of revision numbers to be merged and I would apply thoses merges to the fixes branch. After a couple of merges, the branch became 'super'-stable, because there were no changes. A lot of changes are related and Giuliano wanted to test them before applying. This takes a lot of time. Also, it is sometimes not trivial to see the dependencies between the different revisions, espescially if a revisions contains new functionality, that you don't want to merge and a simple fix that is needed when you want to merge a later bug fix revision.
So we are still struggling to find a good strategy for maintaining the fixes branch. In the last week, I took a different approach. I looked at the list of revisions and merged the new component bar images, splash screen and most the bug fixes I made in Lazarus 0.9.25. Almost 200 revisions were merged from trunk to the fixes branch, so things might have been broken, but I have good hopes that 0.9.24.1 is at least as good as 0.9.24.
There are still about 500 revisions in trunk not (yet) merged:
- Documentation hints
- Handle rewrite
- New project options and environment options dialog
- A number of bug fixes for other widget sets than win32 (my only expertise).
- Improvements to images in the toolbar of the IDE
- Several improvements to the Lazarus IDE dialogs
I encourage everybody to test the fixes branch and give feedback on the Lazarus mailing lists. If the fixes branch proves succesfull (stable updates without occassional breakage), I am considering to put snapshots of it in the Lazarus-Testing Ubuntu repository.
Monday, November 5, 2007
Lazarus 0.9.24 tagged
This afternoon I tagged Lazarus 0.9.24. The coming days we will build all the windows installers, rpms, debs and dmgs for the suported OS-es and CPU's.
As part of the release testing, I created an ubuntu lazarus-testing repository at http://www.hu.freepascal.org/lazarus/dists/lazarus-testing/. Currently it still contains Lazarus 0.9.22 and FPC 2.0.4, but as soon as the Lazarus 0.9.24 and debs are ready they will be put there, until the Lazarus 0.9.24 release can be announced. After the announcement, they will be available in the lazarus-stable repository too. For more information about how to get debs from the Lazarus testing repostitory, see the wiki.
Please, let us know if you have problems using the testing repository and during the upgrade from 0.9.22 to 0.9.24.
As part of the release testing, I created an ubuntu lazarus-testing repository at http://www.hu.freepascal.org/lazarus/dists/lazarus-testing/. Currently it still contains Lazarus 0.9.22 and FPC 2.0.4, but as soon as the Lazarus 0.9.24 and debs are ready they will be put there, until the Lazarus 0.9.24 release can be announced. After the announcement, they will be available in the lazarus-stable repository too. For more information about how to get debs from the Lazarus testing repostitory, see the wiki.
Please, let us know if you have problems using the testing repository and during the upgrade from 0.9.22 to 0.9.24.
Subscribe to:
Posts (Atom)