Tuesday, April 20, 2010

Using multiply Editor-Windows

During development a programmer encounters many different tasks. Some of them require you to work locally on the implementation of a single method. Code completion and hints can provide you with anything you need to know about other methods or objects that you access.

Other work requires you to frequently work on many different places in your code. Refactoring is a good example:
  • Comparing different methods side by side to find duplication.
  • Extracting functionality and moving it to a new location. Viewing both locations at the same time.
  • Changing the interface of your class, viewing interface and implementation next to each other

Multiply Windows

Lazarus can now open as many Source-Editor-Windows as you want, and you can freely move files between them.

Each Window offers you the same functionality as the current Source-Editor-Window. Each window can hold one or more files, accessible through editor-tabs.


You can move a file by using the context menu and selecting "Move to new Window".
Once you have more than one Window open, you can also choose "Move to other Window".

Or you can drag and drop the editor tabs between the windows. If you prefer using the keyboard, you can assign your own key-shortcuts.

If you often have a window with just one tab open, you may find it helpful to hide the tab header and get more space for the editor. An option to do so can be found on the misc editor options.

Editing the same file in multiply Windows.

Sometimes it is not enough to view two different units side by side. Sometimes you need to see different parts of the same unit.

Lazarus can do that too. You can open as many editors for the same file as you want.
Choose "Copy to new Window" from the context menu. Or once you have several windows open drag and drop while pressing the CTRL key.

How it works:

Lazarus will keep one single instance of the file open. This instance is shared by all the editors that you opened for this file.
If you type in one editor, the changes are always made in all open editors at the same time.

Actions like saving or reverting your code always act on the file. It does not matter in which of the opened editors you trigger them, they will affect all the editors that display the file.


Other actions are done per editor. For example you can select a different block of text in each editor, and the selection(s) will be kept while you can edit the text in an other editor.

Limitations

Lazarus only allows you one copy of a file per window. You can not have two tabs with the same file in the same Window. But you can open as many windows as you like, each having one copy of the file.

Undo information is combined for all editors of a file.
For example: Modify a file in one editor, then do further modifications in another editor. Now go back to the first editor. If you press undo in the first editor, it will first undo the changes of the other editor, before undoing the changes you applied in this editor.

This is necessary to avoid conflicts. If you had inserted text in the first editor and then deleted this text in the 2nd editor, it would be impossible for the first editor to undo the insert, because the inserted text is no longer there.

A word about adding more windows to Lazarus.

Many people feel that the Lazarus IDE already has to many Windows, and efforts should be made to reduce the amount. So why adding even more Windows?

Very simple. Using multiply Windows did offer the highest amount of flexibility for now. Having to implement all this with splitters inside a single window would have added serious amounts of extra work or more likely cut-backs on the flexibility of this feature.

Once Lazarus will have docking, the Source-Editor-Windows will benefit from this as well.
On top of that there is of course room to think about specific optimizations, such as splitting a single tab, for two views of the same file. When and if this will be done, remains to be seen.

Thursday, April 15, 2010

Delphi Converter

The converter has improved during past few months. The main focus has been in Delphi project conversion. Delphi package conversion should get most of the same improvements automatically but it is not tested much.

I think Delphi converter is a very important piece of Lazarus because new people coming from Delphi often want to try it. They get their first impression of Lazarus from it.
When I started to learn Lazarus last year, it was one of the first things to test. Then it failed to convert most projects. Its quality was not equal to the rest of Lazarus.

On February 2010 I got write access to SVN trunk converter directory. I made the converter code more object oriented. Using object member variables instead of function parameters made it easier to extend the code later. I refactored the code heavily, actually more than really necessary, partly to organize it better and partly to learn what it does.

The initial dialog shows there are three possible targets for the conversion:
* "Lazarus/LCL" -- One way conversion.
* "Lazarus/LCL for Windows only" -- Does not remove or convert windows specific unit names.
* "Both Lazarus/LCL and Delphi" -- Tries to maintain the code compatible with both Delphi and Lazarus using conditional compilation.



Source file conversion


Initially the main goal was to reduce messageboxes and other notifications. Converting a big Delphi project was not realistic because there were so many messages. Now useless questions are removed and notifications go to IDE messagewindow.



Earlier it was possible to comment out not-found unit names in USES section. Now that is extended. The user can either comment them out or search for a unit path during conversion. If the units are found, their path is added to project settings. If user chooses to comment them out, the same units are then commented automatically in following source files.

Used unit names can also be replaced by other unit names. Regular expression syntax for replacement is supported.


Form file conversion



The other big part of conversion is the DFM form file conversion. Some properties of Delphi components do not exist in the equivalent LCL components. They can be deleted, either automatically or interactively.
A bigger problem are Delphi components which don't exist in LCL at all. It is important to replace them with a "fall-back" LCL component, especially if they are containers and have more components inside them.
Now the components can be replaced and regular expression syntax is supported, just like for unit name replacement.



Issues


The converter is not ready yet. These are some issues and problems I must solve.

Replacement names for both units and components are hard-coded. Soon they will be stored in a XML configuration file and the user can edit them.

A complex codetools function CheckLFM is used for scanning the form file. It stops working when there are errors in source. There are often errors in a unit under conversion so this is a problem.
I must study and fix the codetools functions or even replace them with something.

Replacing a component with a "fall-back" LCL component leads to more unknown properties. It must be solved somehow.

Juha

Friday, February 12, 2010

Work on 0.9.30: changes in resource handling

One of the big changes we have in the svn trunk (you'll get it with the 0.9.30 release) is the modified resource subsystem. Since the first time I tried Lazarus I felt a big displeasure regards the resource handling. I believe you had similar feeling too if you are an old Delphi developer. The main problem was that each lfm stream (Lazarus form) must be duplicated in a .lrs file which is included in unit initialization section. What is bad in this?
  • First of all lrs needs to be stored with your project and therefore eats the free space.
  • The second bad thing is initialization section - a special routine which is called on your program start. Thus your application will run 200 routines at the start if you have 200 forms. Not very nice if you care about the speed.
  • And the last is the amount of memory required for resources and how this memory is allocated. Lrs resources are stored both in the code of your executable (which loads on start) and a TList. Thus each resource is stored twice. Moreover when you add a new resource TList code needs to reallocate the memory used for all resources it has (look at TList.Grow).
All these problems are perfectly solved by the native resource support which is finally implemented by FPC 2.4.0 Starting from 2.4.0 release of FPC it is possible to include a form resource using the {$R *.lfm} (or {$R *.dfm} if you want to include a Delphi form resource) directive. Of course we don't need to store lrs file anymore, we don't initialization section and each resource is stored once in some section of your executable.

Since this way of resource handling is more effective we decided to use it by default in Lazarus. Of course we don't deprecate or remove in anyway lrs support. You are able to choose how to store the form resources in the project options dialog.

Warning: FPC 2.4.0 has 2 small bugs which are already fixed in the svn trunk (revisions 14805 and 14824). It opens all the resource files during linking and if you have small ulimit value you may see a linker error. To workaround the problem set ulimit to a bigger value. The second problem is that your project can't contain special symbols (like spaces) in the path.

Another rework we've made regards resources are the xp manifest, version info and project icon handling. Previously we created up to 5 files to add those resources to an executable: lrs file with an icon resource, rc file which included in turn manifest, version info and project icon files. So you had a whole zoo in the project directory. Now you have only a res and an icon files. We are building the res files ourself using the new FP package fcl-res. This mean also that we don't need finally to use windres. Res file is now used for all platforms while previosly rc was used for windows only and lrs for other platforms.

Warning: you need to remove {$ifdef windows}{$R you_project.rc}{$endif} from your lpr file manually (if you have it there). Maybe we'll implement a way to detect and remove that automatically before the release.

I want to summarize what advantages we have with the new resource support:
  1. Less garbage in the project directory and smaller size.
  2. Smaller and faster executables (because of no initialization sections).
  3. Less memory usage.
  4. Unified resource handling on all platforms.
As as special bonus for component developers I can note a possibility to use one form resource for both Delphi and Lazarus which can be included by {$R *.dfm} :)

This is a resource handling revolution, isn't it?

Tuesday, June 23, 2009

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.

Wednesday, May 13, 2009

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:

Tuesday, April 21, 2009

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.

Thursday, March 26, 2009

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.