Profiles for Build Lazarus

The dialog opens from Tools --> Configure "Build Lazarus".
It is meant for building Lazarus or parts of it, using the given parameters.
The original dialog looked about like this.



The dialog was made by the same developers that actually use it all the time. Thus the GUI is little confusing, it's main design goal was not "ease of use".

Then some people made an effort to simplify the GUI. They didn't touch the original GUI but instead added another "Quick" tab sheet to the dialog.



The original GUI was named "Advanced" tab sheet (as seen in the first picture).
A problem was that this Quick page was not very intuitive either.
There were radiobuttons for options which is OK but then also 2 settings for LCL Interface, Target and IDE. They were never both enabled at the same time. So weird. If some Lazarus user really was so "non-advanced" that he needed this simplified page, how could he understand the difference between Target and IDE LCL Interfaces?

The worst problem however was that the Quick settings modified directly the Advanced settings, but there was no visual feedback about it. It took some time to realize it. A generally accepted GUI convention is that tabs have individual separate sheets. I remember I started using the Advanced page very soon although I was not an advanced user yet. I dare to say very few people used the Quick page.

Already a year ago I created a big patch implementing Build Profiles. It kind of extended the idea of quick selections and made it configurable. It also made the GUI more intuitive. In fact the sane GUI was my main motivation, the profiles were more like an extra bonus.
It was my first substantial patch for Lazarus and I had to study lots of code for it. At the same autumn I had started evening school (although I am not young). Now I can reveal that I made the Lazarus patch partly when I should have read to my math exam. Under pressure my mind goes into a hyper-active state or something. A psychologist could maybe explain it better. Anyway, I scored well in the math exam, too, no problem.

My feature got attention and mails were written but it was not accepted. Actually I created many versions of the GUI based on feedback.
The first version had everything at the same page in 2 panes, Profiles pane and Details pane. That was intuitive but big and crowded.
The second version had a clear list of profile names and a button that opened a details form for the selected profile. That is still my favourite. It is the most intuitive GUI for such things.
It was rejected because the (hard-)core developers want to use the settings as before. The dialog has to be "settings oriented", not "profile oriented". The third version (= the current dialog) follows that idea.

For a while the patch was forgotten but I salvaged it using a local git branch. Recently, finally, it was accepted to Lazarus trunk! After that it was changed some more based on feedback. Widgetset is now selected using a combobox instead of radiobuttons. Options have more room in a multi-line memo and there is a user-configurable list of defines to select from. Etc...
The latest (for now) version looks like this:



There is another dialog for managing the profiles:



I got positive feedback especially from people who cross-compile. The GUI is still complex but it is intuitive and very usable.

A more philosophical point can be made, too. GUIs should be designed and implemented by different people. As a mind-set, GUI design is more close to graphics design than to computer programming.
If no such designers are available, at least comments from outsiders (not Lazarus user) should be listened. I noticed myself that one gets used to confusing GUIs very quickly. A month or two passed and I didn't pay attention to it myself.
Open source projects with financial backing usually concentrate more on visual appearance. And commercial SW, too, of course, but sometimes they consider visual appearance more important than code quality which is not good either.


Juha

Delphi Converter improves

Converter has taken a big step forward during the past few months. The main features I had in mind are now implemented. Most details are configurable in Settings dialog. All settings are saved in file delphiconverter.xml in local Lazarus configuration directory and thus are persistent.

This is the settings dialog:




There is a wiki page with detailed explanation of conversions: Delphi_Converter_in_Lazarus

Here is a brief list of them.

Conversions for Unit file

* All unit source files get a {$mode delphi} directive. It makes the compiler support language syntax exactly like Delphi has it.

* {$R *.DFM} is replaced with {$R *.lfm} if the form file is renamed and converted. Conditional compilation is used if the target is "Lazarus and Delphi".

* Unit names in Uses section and include file names are fixed to match the real case sensitive name found in the file system. This is needed for case sensitive file systems.

* Some unit names in Uses section are either replaced or removed.

* Some Delphi types are replaced with "fall-back" LCL types (same as in form files).

* Some function names called in the code are replaced.

Conversions for Form file

* Older Delphi versions used a binary format for .dfm form files. The converter always converts them to ascii text format.

* .dfm form file is renamed or copied to .lfm and converted as needed. There is also an option to use the same Delphi form file directly. See section Target below.

* Unknown properties are removed.

* Some Delphi types are replaced with "fall-back" LCL types (same as in unit files).

* Top and Left coordinate offset adjustment for controls inside visual containers.

Implementation details

Codetools are used a lot when changing the source code and .lfm form file.

One challenge was to replace function calls inside the source code, using parameters from the original call as defined in configuration. Codetools create a parse tree of the code but it includes only definitions, not function calls or other code constructs.
It means that the source code must be parsed char by char when looking for function calls to replace. Fortunately there was TFindDeclarationTool.FindReferences which I could use as the base for my TConvDelphiCodeTool.ReplaceFuncCalls. I copied the code, studied and debugged it for some time, then stripped useless parts out and added more code for replacing the function calls.

Another challenge was adjusting Top and Left coordinates of controls inside visual containers.
I based my TConvDelphiCodeTool.CheckTopOffsets on TStandardCodeTool.CheckLFM.
Again, I copied, studied, stripped, modified and added code.

The huge code-base of codetools looks first almost incomprehensible. The code browsing features of Lazarus are a big help here. They let you jump around code with no delays. After jumping and debugging for some time the code starts to make sense, piece by piece.

It is funny. When you first look at complicated code in a big project, you think: "oh, who is able create such code?". Then you make some code yourself and then have a month or 2 pause, and then look at the code and think: "oh, who has made this? Must be a clever person! ... oops, it is my own code...".
I guess other coders have similar feelings. Nobody can handle big amounts of code at one time. Sometimes you concentrate on the big picture and forget the details, sometimes you fiddle with the details and forget everything else.
In the end, for an outsider, the code may look like some intelligent person had made it. :-)

Juha Manninen

User defined color-schemes

As the lazarus community grows people yearn for more customizations to please their personal habits.

To help creating a wider choice of readily available settings, user defined color schemes have been introduced.

So now, your community needs you.

Get the latest Lazarus snapshot, load your favourite color settings (or create the perfect scheme from scratch) and then make it available to all of us. All you need is press "Export", enter a Name and save it.
Upload it to your home page, or a place of your choice and link it on our wiki so everyone will find it.

Wiki page to link to your scheme(s): wiki.lazarus.freepascal.org/UserSuppliedSchemeSettings
Documentation: wiki.lazarus.freepascal.org/IDE_Window:_Editor_Options_HighlightColors

"Page-Locking" or "multiply Editor-Windows (part 2)"

Following up the article about "Using multiply Editor-Windows", let's look at some more advanced scenarios.

You may want to use two editors, so that one shows you the interface of your class, while in the second you can work on the implementation of it.

The only thing is, once you have carefully positioned the first editor, you must always make sure, that you don't move it by accident. If it gets focus and you trigger a jump-to-implementation (or a jump to history/bookmark in this file), it will move away from your chosen location and you have to re-position it again.

This is where page-locking comes in. You can tell Lazarus, that it shouldn't move this editor away from your chosen location. The context menu has an entry "Lock Page" which will toggle the lock for the page. If the page is locked the entry in the context menu has a checked mark, and the editor tab will show an "#" in front of the file-name. (The command can also be assigned to the keyboard.)

Once your page is locked, Lazarus will no longer move it to other locations. You can still go to the editor and use the cursor keys or page up/down to reposition it. But if you try to jump between interface and implementation, go to declaration, bookmarks, etc, the IDE will automatically change to the other editor showing this file and move the other editor to the location you want to see.

So now in the example with the class declaration in one window, you can choose any method declaration of the class in the fixed window, and then trigger a jump to it's implementation. And it will always end you up in the 2nd window, in which you want to edit the code.

But what if you are in the 2nd window and jump back to the interface of your class? You don't need to have both windows showing the same code. By default Lazarus will recognize that your first (locked) window, already displays the interface. And the IDE will take you back to this first window.
Lazarus offers you some settings, to change this behaviour, if you like a different behaviour. (See Options / Editor / Multi Window)

And what happens if you accidentally lock an editor that has no 2nd view of the file? or you lock all editors of a given file? If that happens, Lazarus will open a new editor in a new tab (in an existing or even in a new window) for you. And if you don't like that, you can change the options so lazarus will ignore the locks, if this case arises.

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.

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

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?