Custom Drawn Interface/ru

From Free Pascal wiki
Jump to navigationJump to search

│ English (en) │ русский (ru) │

Other Interfaces

Platform specific Tips

Interface Development Articles

Введение

LCL-CustomDrawn-Android имеет следующие оссобенности:

  • Движки для X11, Android и Windows и частично рабочий для Cocoa, другие могут быть добавлены в будущем
  • Отрисовка сделана полностью внутри Lazarus, не используя родных(native) библиотек, за исключением отрисовки текста. Это гарантирует одинаковое изображение на всех платформах и единый уровень поддерживаемых функций
  • Только одно родное(native) окно используется для каждой формы, в backend для Андроид на данный момент это одно native-окно для всего приложения
  • Используются the Lazarus Custom Drawn Controls для реализации стандартных элементов управления LCL
  • Испольуются его графический движок для частей LCL: TLazIntfImage, TRawImage, lazcanvas и lazregions

FAQ

Comparison of LCL-CustomDrawn and LCL-fpGUI

Item LCL-fpGUI LCL-CustomDrawn
Native handles fpGUI uses 1 native window for each control LCL-CustomDrawn uses 1 native window for each form in X11, Cocoa and Windows and 1 native surface for all forms in Android
Canvas implementation fpGUI uses native Canvas routines from the platform LCL-CustomDrawn has a define to choose between native and non-native (via LazFreeType) text metrics/rendering and everything else from canvas drawing is implemented by TRawImage+TLazIntfImage+TLazCanvas. Being non-native means a faster and more reliable result.
Supported platforms Windows, Windows CE and Linux (via X11) Windows, Cocoa (Mac OS X), X11 (Linux) and Android
Level of indirection fpGUI acts as an intermediary between the LCL and the platform There are no intermediaries, the LCL talks directly to each platform
Adaptation for platforms without native sub-windows fpGUI would need extensive changes to work in platforms which do not have native sub-controls, for example Android, linux framebuffer, OpenGL LCL-CustomDrawn is designed from the start to work on very limited platforms, for example the Linux Framebuffer, an Android SurfaceView or OpenGL
LCL Adaptation fpGUI is a separate unrelated framework. It's controls and Canvas APIs do not necessary match what is required by the LCL LCL-CustomDrawn is designed to perfectly implement all features from the LCL and perfectly paint it's Canvas drawing routines like LCL-Win32, LCL-Gtk2 and LCL-Qt do
How to port the LCL to a new platform using this widgetset? First you need to port fpGUI and then verify if LCL-fpgui keeps working You can port LCL-CustomDrawn directly to new platforms by implementing a new backend which contains support for form, application and and other parts

More comments on why developing LCL-CustomDrawn instead of LCL-fpGUI: Just to start with, it is the correct architecture. There is no need for an intermediary API which complicates the architecture and makes debugging and porting harder. We can do everything directly without it and greatly simplify our code. Also, by eating our own dog food we ensure that our platform is more strongly tested and has a higher quality. Each feature in LCL-CustomDrawn is implemented using other more basic features. For example TButton, TPageControl and all other visual controls are implemented with TCanvas, so it guarantees that our Canvas drawing is in excellent shape. Drawing in LCL-CustomDrawn is executed via LCL classes: TRawImage, TLazIntfImage and TLazCanvas. If there is an intermediary API then porting the LCL means first porting the intermediary API and debugging it and then debug the combined package. LCL porters should not need to learn unrelated frameworks to port the LCL.

On top of that, LCL-CustomDrawn is designed from the start to be portable to even the most spartan and problematic of platforms. It requires from the platform only a raster surface in any pixel format and also input events. From that onwards we can implement everything else non-natively. There are non-native implementations of Forms, WinControls, standard controls, TCanvas drawing, dialogs and even text can be provided if necessary. Each backend can select its mix of non-native / native elements, although they should never attempt to implement TWinControl natively. fpGUI on the other hand would need a large rewrite to be able to support this level of portability.

Движки для LCL-CustomDrawn

LCL-CustomDrawn нуждается в движках для реализации основной части виджетов. Каждый backend должен реализовать следующие минимальные части:

  • TWidgetSet.Run, ProcessMessages, etc
  • TForm
  • TWinControl with all events
  • TTrayIcon

LCL-CustomDrawn-Android

Этот движок работает. Смотрите эту страницу Custom Drawn Interface/Android

Также смотрите Android Programming/ru

LCL-CustomDrawn-X11

Этот движок работает. Смотрите Custom Drawn Interface/X11

LCL-CustomDrawn-Cocoa

Этот движок работает.

LCL-CustomDrawn-Windows

Этот движок работает.

LCL-CustomDrawn-iPhone

Этот движок планируется, но еще не начат.

Canvas

TCanvas will be fully non-native in this widgetset and based on LazCanvas. All drawings to visual controls and on the OnPaint event of controls of the form are naturally double-buffered because the entire drawing of the form is first performed on an off-screen buffer and then copied in 1 operation to the form native canvas. In reality there is only 1 TLazCanvas for the entire form, but sub-controls will think they are on a separate canvas because the property BaseWindowOrg sets an internal start position of the canvas and also because all drawings will be clipped to reflect the size and shape of the sub-control.

Отрисовка шрифтов

Когда определение CD_UseNativeText установленно, LCL-CustomDrawn будет использовать родной(native) для платформы способ отрисовки текста, как это предусмотренно движком. Если оно не активно, тогда будет использоватся LazFreeType для отрисовки текста. Определение автоматически активно для некоторых движков, если это удобно для их использования.

Message and Common Dialogs

Message and Common Dialogs might be native if this is considered very convenient for the backend. If not, they will be non-native. At the moment the Android backend has native message boxes.

Оконные визуальные элементы управления

Все оконные визуальные элементы управления (TButton, TPageControl, и др.) будут основыватся на Lazarus Custom Drawn Controls

Conditional defines accepted by LCL-CustomDrawn

Here are defines which affect the functionality offered by this interface:

  • CD_UseNativeText - Activates using native text instead of LazFreeType. This define will be automatically set if convenient for a particular backend

And here debug information defines:

  • VerboseCDPaintProfiler - Adds profiling information to indicate how fast the paint event is processed
  • VerboseCDWinAPI - Extended verbose information for LCLIntf calls, except those which are covered by one of these defines instead:
    • VerboseCDText - Verbose info for text winapi calls
    • VerboseCDDrawing - Verbose info for Canvas and drawing operations
    • VerboseCDBitmap - Verbose info for Bitmap and rawimage creation and handling
  • VerboseCDForms - Extended verbose information for TWSCustomForm methods and about the non-native form from customdrawnproc (when utilized)
  • VerboseCDEvents - Extended verbose information for native events (for example mouse click, key input, etc). This excludes the paint event
  • VerboseCDPaintEvent - Debug info for the paint event
  • VerboseCDApplication - Verbose info for App routines from the Widgetset object
  • VerboseCDMessages - Verbose info for messages from the operating system (Paint, keyboard, mouse)
Retrieved from "https://wiki.freepascal.org/index.php?title=Custom_Drawn_Interface/ru&oldid=89074"