Vote for Lazarus

Thank you, people from the Lazarus community! For the first time of our project history Lazarus has been nominated for SourceForge's Community Choice Award in the category "Best Tool or Utility for Developers".

Grab your chance to let others know how much you like Lazarus by voting for Lazarus. Spread the news and don't forget to vote, this time to make us winners.

Changes with Button Glyphs

If you ever worked with the Lazarus IDE under windows (or just compiled an LCL application for windows) you were probably sickened by the glyphs on the dialog buttons since it is not native for windows. But on linux all is vice versa - most of the buttons have glyphs (and for example gtk and qt suggest an appropriate API to query "stock" images for buttons with various actions like save, open, apply, cancel, ...).

Therefore I needed a solution which can satisfy both windows and linux users. I started from the TBitBtn class which represents a button control with an image inside it. What I have added is a new property "GlyphShowMode" with 4 states:

• gsmAlways
• gsmNever
• gsmApplication
• gsmSystem

It is clear what the gsmAlways and gsmNever states are for: gsmAlways - to show the glyph always and this is how it worked before, gsmNever - to show the glyph never. Well, you may ask: What do I need the gsmNever state for, if I can use a TButton instead?. And I would answer: TBitBtn is not just a button with an image. It also has a Kind property which is very useful to set the ModalResult and Caption of a button :) But let's return to the other modes. gsmSystem can be used to show glyph depending on current OS - on MS Windows glyph will not be shown and on other system it will. And the last mode which is also default for this property - gsmApplication. In this mode TBitBtn (well, not exactly TBitBtn but TButtonGlyph) will look at the Application object for its value.

So, you can control the visibility of all button glyphs using the Application object. How? There are 2 ways: at run time by changing the Application.ShowButtonGlyphs property or at design time by changing the same property for the TApplicationProperties component. TShowButtonGlyphs is an enumeration too with following elements similar to TGlyphShowMode:

• sbgAlways
• sbgNever
• sbgSystem

The default value for the ShowButtonGlyphs property is sbgAlways and not sbgSystem as one may expect. The reason is compatibility with old applications. Developers don't like surprises after a development tool upgrade and the loss of images is not a nice surprise. Anyway, it is not difficult to change the behavior of your application.

One more thing - glyphs are always visible when you are designing your forms. The glyph visibility mode is applied to the controls only at run time (when you start your application).

And now with regards to the Lazarus IDE. After this change the IDE on windows does not show glyphs on buttons by default, but if you really liked them, you can ask IDE to return them. You need to open the IDE options dialog and select Desktop settings:

No updates on the 0.9.26 fixes branch

I have decided to stop merging revisions from Lazarus trunk to the fixes_0_9_26 branch. There are two reasons:

1. The differences between trunk and the fixes branch have become too many, over a thounds revisions. It is difficult to oversee their relations and dependencies, so I cannot guarantee the quality of the fixes branch just by looking at the patches and revision logs.


2. I want to focus on the 0.9.28 release rather than maintaining 0.9.26.3 and working on a 0.9.26.4 release.

That said, it doesn't mean 0.9.28 is almost ready, a lot of work still needs to be done. The list of issues with that we want to fix before the 0.9.28 release contains about 50 items.

So, from now on nobody from the current Lazarus team maintains the 0.9.26.3 branch. If somebody from the community is using the Lazarus fixes branch on a daily basis and want to extend its life, then that is possible. The new maintainer would supply me a list of revisions to be merged and tests the fixes branch. I would do the actual merging and keep the snapshots of the fixes branch alive. If you are interested, you can contact me and we can work out the details.

fpsvnsync, thanks for your services

Since March 2007, the Lazarus SVN repository has been mirrored on SourceForge. Mirroring it on SourceForge is nice, sometimes people have trouble reaching svn.freepascal.org. And the svn commits count for the SourceForge ranking. Because SourceForge did not allow changing the revprops like author and date, I could not use the official tool called svnsync to create such a mirror. I submitted a tracker item at SourceForge to allow changing revprops, but two years nothing happened. So I wrote a watered down version of svnsync which would do almost the same as svnsync and named it fpsvnsync.

Last week I browsed the SourceForge site status and found an announcement about enabling revprops. This is good news, fpsvnsync does it job, but it needs both trees checked out and it is not as efficient as svnsync itself, because it starts a svn process several times for each changed file.

Last Monday I made a svndump of the Lazarus repository to get all those names and dates (which fpsvnsync cannot / could not set correctly) right. For your information, is a 700 MB file after bzip2-ing. I imported it on SourceForge using the svn migration page. Then I had a surprise when started svnsync init:

svnsync init https://lazarus.svn.sourceforge.net/svnroot/lazarus \
http://svn.freepascal.org/svn/lazarus
svnsync: Cannot initialize a repository with content in it

It only works on empty repositories. Three hours of import wasted.

So I imported an empty repository and called svn init on that repository. Using svnsync sync would be an option to make the mirror up to date, but importing more than 19000 revision this way didn't seem to be a wise choice. So I imported the 700 MB dump again, but without clearing the existing one. But still the svnsync utility didn't want to work. I had to set the svn:sync-last-merged-rev property manually, svnsync keeps this revprop for its administrative puproses at revision 0:

svn propset svn:sync-last-merged-rev --revprop -r0 19091 \
https://lazarus.svn.sourceforge.net/svnroot/lazarus

I updated my crontab to call svnsync every three minutes and the Lazarus svn mirror at SourceForge has been updated nicely after.

Next Lazarus release: 0.9.26.2

More than three months (and 1500 revisions) have passed since the latest Lazarus release, so it is time for a new release. Lazarus trunk has now gtk2 as default widget set on Linux and is not yet in a releasable state. Further, gtk2 on newer Linux distros, requires fpc 2.2.4, which has not been released yet. The first release candidate is expected in the coming week(s). So I don't expect the final fpc 2.2.4 release before March. Waiting for fpc 2.2.4 would mean waiting for the next Lazarus release till April or May.

Fortunately, selected revisions from trunk have been merged to the fixes 0.9.26 branch, which actually has become more than just fixes, also 'stable', finished features from 0.9.27 have been merged, such as the use frames and the project icon.

This release can been regarded as an experiment with time based releases. Trunk releases usually have been scheduled to follow a fpc release or some finished feature and bug fixes. The exact timing of such releases was hard to predict. I tried to keep the fixes 0.9.26 branch always in a releasable state, so for example the switch to gtk2 has not been merged, because that depends on a fpc release.

I think the challenge with this release is the testing. The fixes branch is (almost?) not used by the Lazarus developers and I doubt that Lazarus snapshot users use 0.9.26.1 snapshots as much 0.9.27 snapshots. I want to ask you to try these 0.9.26.1 snapshots and report any regressions compared to the 0.9.26 release.

If everything goes well, we have a 0.9.26.2 release next month. Keep an eye on the release plan.