Carbon interface internals
This page gives an overview of the LCL Carbon interface for macOS and will help new developers.
For installation and creating a first Carbon application refer to Carbon Interface.
- Lazarus known issues (things that will never be fixed) - A list of interface compatibility issues
- Win32/64 Interface - The Windows API (formerly Win32 API) interface for Windows 95/98/Me/2000/XP/Vista/10, but not CE
- Windows CE Interface - For Pocket PC and Smartphones
- Carbon Interface - The Carbon 32 bit interface for macOS (deprecated; removed from macOS 10.15)
- Cocoa Interface - The Cocoa 64 bit interface for macOS
- Qt Interface - The Qt4 interface for Unixes, macOS, Windows, and Linux-based PDAs
- Qt5 Interface - The Qt5 interface for Unixes, macOS, Windows, and Linux-based PDAs
- GTK1 Interface - The gtk1 interface for Unixes, macOS (X11), Windows
- GTK2 Interface - The gtk2 interface for Unixes, macOS (X11), Windows
- GTK3 Interface - The gtk3 interface for Unixes, macOS (X11), Windows
- fpGUI Interface - Based on the fpGUI library, which is a cross-platform toolkit completely written in Object Pascal
- Custom Drawn Interface - A cross-platform LCL backend written completely in Object Pascal inside Lazarus. The Lazarus interface to Android.
Platform specific Tips
- Android Programming - For Android smartphones and tablets
- iPhone/iPod development - About using Objective Pascal to develop iOS applications
- FreeBSD Programming Tips - FreeBSD programming tips
- Linux Programming Tips - How to execute particular programming tasks in Linux
- macOS Programming Tips - Lazarus tips, useful tools, Unix commands, and more...
- WinCE Programming Tips - Using the telephone API, sending SMSes, and more...
- Windows Programming Tips - Desktop Windows programming tips
Interface Development Articles
- Carbon interface internals - If you want to help improving the Carbon interface
- Windows CE Development Notes - For Pocket PC and Smartphones
- Adding a new interface - How to add a new widget set interface
- LCL Defines - Choosing the right options to recompile LCL
- LCL Internals - Some info about the inner workings of the LCL
- Cocoa Internals - Some info about the inner workings of the Cocoa widgetset
Documentation about Carbon
- Free Pascal's Carbon API unit is FPCMacOSAll.pas in /usr/local/share/fpcsrc/packages/extra/univint.
Carbon interface development basics
- Target Mac Tiger version is 10.4
- Avoid using obsolete or deprecated APIs and functions (e. g. QuickDraw vs. Quartz 2D)
- Use object approach
- Check Carbon calls result with OSError function
- Assume UTF-8 encoded strings between LCL and Carbon widgetset (for future Lazarus Unicode support)
What is already working ?
- Features - see Roadmap#Status_of_features_on_each_widgetset
- Forms and controls - see Roadmap#Status_of_components_on_each_widgetset
- Creating TOpenGLControl with AGL context (see components/opengl/)
- Mouse events
- Keyboard events
What needs to be done next?
Carbon IDE Bugs
|'...' buttons in dialogs||Now they are too large I think|
|OK/Cancel||Many dialogs have non-Mac check-X glyphs|
|Menu bar||Too wide for 1024x768 display resolution|
|Lazarus menu||Help About and app prefs (Environment options) should be accessible here|
|Menus||Many missing or non-standard menu shortcuts:
File New should be Cmd+N
- Apple Command key is mapped to ssMeta
- Apple Control key is mapped to ssCtrl
- Apple Option key is mapped to its inscription, i.e. ssAlt
- Virtual key codes mapping is not reliable (depends on keyboard language layout!)
- Title: You cannot change it at runtime. You have to set it in Application Bundle.
- OnDropFiles event is fired when file is dropped on application dock icon or opened via Finder if is associated. You have to enable this event in Application Bundle.
Drawing and measuring text precisely in parts
If you want to draw (via TextOut, TextRect) or measure (via TextWidth, TextHeight) text divided into various parts and rely it will be displayed same each time not depending on its division, you have to disable some default typographic features (like kerning, fractional positioning, ...) of Canvas. You can choose one of the following:
- CarbonWidgetSet.SetTextFractional(Canvas, False); // from CarbonInt unit
- TCarbonCustomControl(CustomControl.Handle).TextFractional := False; // from CarbonPrivate unit
- TCarbonDeviceContext(Canvas.Handle)..TextFractional := False; // from CarbonCanvas unit
The only possible efficient way of taking a screenshot on macOS is using OpenGL. Apple provides a demonstration function which returns a CGImageRef with the screenshot. This function was converted to Pascal and is available on the glgrab.pas unit on the carbon interface directory. This function requires the Apple-specific parts of the Apple OpenGL headers, and those aren't yet on the FPC Packages, so they were translated and are located on lazarus/lcl/interfaces/carbon/opengl.pas until they are released on a stable Free Pascal.
After obtaining a CGImageRef, the next step to implement the RawImage_fromDevice method is obtaining a local copy of it's pixel data. It isn't possible to directly access the bytes of a CGImageRef, so the image needs to be drawn to a CGContextRef which uses a memory area allocated by us as buffer. This method has the great advantage of converting from the internal format of the screenshot bytes to the very convenient ARGB, 32-bits depth, 8-bits per channel format that is default to LCL.
macOS has two possible ways of focusing: Full keyboard navigation (enabled with Accessibility options), Text field navigation (only controls that are to receive text input should be focused). Full keyboard navigation is the same as any other widgetset.
There's no way to say if control is text-input or not. Native OS controls will handle focus themselves. The Carbon Widgetset checks if bound LCLObject is SynEdit and will switch the focus to it.
Because Quartz 2D's clipping is decreasing, care must be taken for proper clipping region change. There should be no code, that changes CGContext's clip region directly. Carbon widget API's functions should be used instead.
These are things that will probably never be solved.
Mouse.CursorPos changing does not generate mouse (move) events
Release mouse capture is not supported
Command line parameters
Because Carbon applications are executed via Application Bundle, command line parameters are not passed. You have to use OnDropFiles event to detect openning associated files.
Shortcuts indication is not supported
Drawing on Canvas outside OnPaint event is not supported
Drawing on screen device context is not supported
TCustomControl.Color of clBtnFace makes its background transparent
TWinControl.Font fsStrikeOut is not supported
- Icon is not supported
- ShowInTaskbar is not supported
- TForm.top=0 is not good. Use TForm.top=23
TEdit.PasswordChar different then default is not supported
TMemo.WordWrap when is disabled, does not allow to scroll text horizontally
TListBox.Columns is not supported
- DroppedDown does not show drop down list when style is csDropDownList
- DropDownCount is not supported
- Style: csSimple, csOwnerDrawFixed and csOwnerDrawVariable are not supported
TPanel.Bevelxxx: bvLowered and bvSpace are not supported
TBitBtn.Spacing is not supported
- LineSize is not supported
- ScalePos is not supported
- TickMarks are not supported
- BarShowText is not supported
- Smooth is not supported
- Step is not supported
TColorDialog.Title is not supported
macOS System (Windows' and Controls') Handles
It’s some times necessary to access system windows or control handles directly. For example, you wish to use some system features that are not available (not yet implemented?) for LCL. It’s very common for LCL Windows developers (and Delphi developers) to use TControl.Handle property, since Handle is a system window handle for Win32 widgetset. It can be used with any system function. But it’s not so for Carbon widgetset. TControl.Handle would return handle native to widgetset not macOS. TControl.Handle would return TCarbonWidget class (declared at CarbonDef unit). This’s a wrapper class, and you can use it to get system handle.
var AHiView: HiViewRef; begin ... //this is incorrect way of getting system handle for Carbon widgetset //AHiView:= HiViewRef(Button1.Handle) //this is correct way AHiView := TCarbonWidget(Button1.Handle).Widget; ... end;
You should also note, that there’s difference in getting WindowRef in LCL versions. If you’re using Lazarus 0.9.26 or earlier you should get WindowRef in the following way:
var MacWin: WindowRef; begin ... MacWin := TCarbonWidget(Form1.Handle).Widget; ... end;
If you’re using svn LCL version (latest trunk), then you should use the following way:
uses ..CarbonPrivate.. var MacWin: WindowRef; begin ... MacWin := TCarbonWindow(Form1.Handle).Window; ... end;
Keep in mind, that LCL is designed to be cross-platform library, and accessing system handles to use with system functions makes you program hardly portable. The way of getting system objects handle might also be changed in future.
Unfortunately Apple only added a facility to check menu visibility in Snow Leopard 10.6. To overcome this limitation in a simple way in previous versions one can use the following code, which should work in previous versions using a class method in TCarbonWSCustomTrayIcon:
uses CarbonWSExtCtrls; ... begin if TCarbonWSCustomTrayIcon.IsTrayIconMenuVisible(TrayIcon1) then Caption := 'Visible' else Caption := 'Not visible'; end;
How to add a new control
For example TButton.
TButton is defined in lcl/buttons.pp. This is the platform independent part of the LCL, which is used by the normal LCL programmer.
Its widgetset class is in lcl/widgetset/wsbuttons.pp. This is the platform independent base for all widgetsets (carbon, gtk, win32, ...).
Its Carbon interface class is in lcl/interfaces/carbon/carbonwsbuttons.pp:
TCarbonWSButton = class(TWSButton) private protected public class function CreateHandle(const AWinControl: TWinControl; const AParams: TCreateParams): TLCLIntfHandle; override; end;
Every WS class that actually implements something must be registered. See the initialization section at the end of the carbonwsXXX.pp unit:
TCarbonWSButton overrides CreateHandle to create a Carbon button helper class called TCarbonButton in carbonprivate.pp, which really creates the button control in the Carbon and installs event handlers.