This page contains notes for lazarus core developers about ongoing development.
Multi form properties / using DataModules from other forms in the designer
This feature allows to use components of other designer forms. A common example is to use the TDataSource on a DataModule for the DataSource property of a db control. Designer forms can only reference each other if they have a CreateForm statement in the lpr file (Project Options / Forms).
- Manual referencing via source code works.
- TPersistentPropertyEditor.GetValues - List all possible values. Check for class compatibility and if the target form is listed in the CreateForm statements of the lpr file and if the target unit does not belong to a package that will conflict if used.
- TPersistentPropertyEditor.GetValue - Show component path
- TPersistentPropertyEditor.SetValue - search the component via the given path
- When component is deleted, the property must be set to nil - This is not the job of the IDE, but should be achieved by the normal TComponent FreeNotification feature. Maybe eventually a check could be added, if this is implemented properly and force a nil on error.
- When a component is renamed the property does not need to be updated, because the form is open and use the pointer not the name. But the designer must be flagged 'modified', because the lfm has changed. See below.
- When reference form is opened, then target forms are opened too.
- When target form is closed, then only the designer is closed. The component is kept hidden.
- When all referring forms are closed/hidden, the hidden component will be automatically freed.
- Circle dependencies are allowed.
- When referenced component is renamed, the using units must be set modified.
- When referenced component is deleted, the using units must be set modified.
- Opening a unit now checks if designer is already created
- Reopen/Revert a form - all connected forms are now closed
- Allow to connect to forms, that are used in the uses section. Technically there is no connection between the uses section and the form streaming, because form streaming uses global variables. But the IDE must somehow find the referenced form. Without the uses section the IDE must in worst case search and read every reachable lfm file on disk. So the uses section is a good compromise between speed and flexibility.
번역, i18n, lrt files, po files
프로젝트에 자동으로 .po 파일을 생성하고 업데이트하는 기능을 추가합니다.
- Dialog options for project/package to enable i18n
- Collect TTranslateStrings from RTTI while designer form writing and writing them to lrt file.
- Copying new strings from rst and lrt files to a single .po file for each project
- load the .po files
- Delete unused strings from the .po file of package/projects
- Update translated .po files, similar to the updatepofiles tool.
- Copying new strings from rst and lrt files to a single .po file for each package (implemented, need dialog option to change po filename or need agreedment to use same name of package)
- Collect all .po files of project and all used packages into a directory. This directory can then be used by the project to load the strings at runtime. And installers can copy the content.
- standardize filenames and path, so that loading the translations at runtime is possible without writing code.
Frames are special child forms. The goal is to edit them like forms in the IDE designer, and to use them as components on designer forms.
compile lazarus clean with passing -dEnableTFrame (not necessary starting from svn release 16909)
- Manually creating via source
- gtk1, gtk2, qt, win32/win64
- Create a new frame
- Open a frame in the designer
- Save a frame
- Close a frame
- Revert a frame
- Design a frame (adding, selecting, moving controls, ...)
- Opening a nested frame
- Opening a nested frame with ancestors
- Support for the inline keyword for lfm and lrs streams.
- Add a frame to a form, add unit to uses section, package to project dependencies
- Auto opening frame if not yet loaded
- Close a frame that is currently used by a nested frame
- Close a form with an embedded frame
- Save a form with an embedded frame
- Delete a frame embedded in a form
- Inherited nested Components (Components with the frame as Owner and not the Form)
- Show inherited nested components properties in OI
- Forbid deleting nested inherited components
- Forbid renaming nested inherited components
- Show inherited nested components events in OI as ClassName.MethodName
- When dblclick on inherited nested components events in OI create an event with the following code: Frame1.FrameResize(Sender);
- When Ctrl+Click on inherited nested components events in OI jump to inherited code.
- show nested components in OI component tree
- Write nested component to stream
- Forbid putting a component onto a nested frame, because TWriter does not support that.
- Revert a form with an embedded frame
- Propagate changes of ancestor to nested controls
VFI - Visual Form Inheritance
Forms can inherit from other forms. The .lfm streams of ancestors are read/applied before the current lfm. The .lfm of the descendant is the difference between ancestor and current state. The IDE allows to open and edit inherited forms. VFI does not only apply to TForm, but TDataModule, TFrame and any registered base designer class. For the full features compile with -dEnableTFrame.
- find ancestor unit, lfm and class
- automatically open ancestor form hidden in background
- open descendant and read ancestor lfm first
- show hidden ancestor form
- hide ancestor form
- automatically close hidden ancestor form if not needed anymore
- create new ancestor form via 'File / New ... / Inherited Items'
- forbid deleting inherited components
- forbid renaming inherited components
- inherited events (partially working)
- apply changes of ancestor to descendants when both are open
Create auto generated files in the output directory
The IDE auto creates some files, like the .lrs files of the .lfm files. These files should be auto created in the output directory. This has the advantage that they are not in the source directory, making browsing and version control systems easier.
- Option for projects for .lrs files
- new projects should by default use an output directory (except for the executable/bundle)
- .lrs files can be created in the output directory
- .rc file 프로젝트의 메인리소스 (version and icon)
- .manifest 파일
- 패키지 옵션
The jedi code formatter
- Pressing ctrl+D will format your source file
- Settings are stored and read by IDE from JCFSettings.cfg file
- port the jcf option dialogs
- use jcf for indentation
컴파일러 매시지 번역
The IDE can only parse English compiler messages. The same for linker and make messages. It would be nice to show the translated messages. The FPC sources contain the translated texts, for example compiler/msg/errord.msg for german. Since FPC 2.4.0 the compiler knows the option -vq which shows the message number. This could be used to find for an English message the translation (if there is any) or from the translation back to the English one. The main problem is to distinguish compiler, linker and make messages.
- extend the TOutputFilter to search for the compiler message numbers
- write a parser for the compiler message table
- using the numbers to find out the type of message (error, fatal, hint, warning, note, ...)
- extend the TOutputFilter to filter the compiler message numbers. Most users don't need the numbers.
- always passing -vq to the compiler.
- finding the right table. For example some quick fix items need one of the message parameters (e.g. unit bla not found). For this the text and the placeholder position is needed.
- using the numbers for the quick fix items
- show breakpoints etc in asm window
- implement/design interface on debugger class to show/handle threads
- attach to process
- implement/design interface on debuggerclass to handle os exceptions
- implement/design interface on debugger class to show messages
- implement/design interface on debugger class to show loaded modules
- implement debugging of forked processes
- implement launching process on xterm (mainly for console apps)
- find include files in fpc sources