On Saturday 19 January 2008 19.39:32 Damien Gerard wrote: > > Sorry for my ignorance, but I really don't see the interest of fpGui. > Under Windows, I prefer Win32 due to it is the native gui. Under Linux > GTK2 make all the work I need. QT may be too I don't really know I > have not enough tested it. Under OS X I would prefer Cocoa but Carbon > is fine too(additionally this widgetset begins to be really usable). > > Projects work on these 3 platform without any defines, and they are > quite complex. And the current LCL solves those issues too. > So what fpGUI brings to me ? > With the Lazarus approach to use OS-native or external widgets it is difficult to achieve consistent behaviour over all platforms. To write your own widget base library in pascal is more work at the beginning but much easier to achieve high quality and productive cross platform development once the kernel is written. A big plus is the ability to add needed base functionality for the higher levels into the kernel, it allows a maximum of flexibility and platform independence.
The architecture of MSEgui: There is a twindow object which represents the top level window of the operating system. twindow holds the handle to the OS window object. The top level widget (for example a tmseform) is responsible for creating and destroying the twindow object. Every widget holds a reference to the assigned twindow of the top level widget. That is twidget.window of a child widget maps to twindow of the top level twidget. twindow has a canvas which is used for painting all widgets of the form. The canvas is a parameter of the paint method: " twidget = class(tactcomponent,iscrollframe,iface) [...] procedure paint(const canvas: tcanvas); virtual; " The paint canvas works on a server side pixmap with the size of the update area in order to implement platform independent double buffering. The pixmap is copied to the screen after the widgets of the window are painted. If the update area is small, the pixmap is small too which results in good performace. twidget.font is normally a nil pointer which means that the widget uses the font of the parent widget or a default font if there is no parent. In object inspector of MSEide or in code you can create a local tfont instance if needed. The same principle applies for twidget.frame, twidget.face and other not always used class properties, they are a nil pointer only if the widget doesn't need them. Because of this and the fact that there is only one window handle per form, there is no need for a stripped-down "TGraphicControl". Every MSEgui twidget has all possibilities, every twidget can serve as top level window-widget. MSEgui is completely Unicode based, all text strings are widestrings. MSEgui has a Unicode capable tpostscriptprinter and an own report generator and designer, the MSEgui database components convert from/to utf8 or the system encoding while reading/writing from/to the database, text fields are stored as widestrings in the dataset . Worth to mention is tmsebufdataset with "TClientDataset"-like functionality. Another innovative component is twidgetgrid. Every inserted edit widget builds a data colum in the grid. All properties and events of the column widgets are working, the result is a very flexible and powerful compound widget. tdbwidgetgrid is the DB-aware version of the twidgetgrid. MSEide+MSEgui is at version 1.6 and used in production. Invested development time about 14'000 hours up to now. MSEide is GPL, MSEgui modified LGPL like the FPC-RTL. For questions and bug reports please use NNTP: news://news.grid-sky.com/public.mseide-msegui.talk Martin _________________________________________________________________ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
