[lazarus] CVS changes

[Michal Bukovjan]

Keith Bowes wrote:

>----- Original Message -----
>From: "Michal Bukovjan" <michal.bukovjan at openone.cz>
>To: <lazarus at miraclec.com>
>Sent: Sunday, February 03, 2002 1:18 PM
>Subject: Re: [lazarus] CVS changes
>
>>The interfacebase.pp is the problem. Right now it includes winapih.pp,
>>which references types defined in LCLType/LCLLinux.
>>However, this units exist only to emulate "Windows types" on Linux. The
>>whole interfacebase methods are very Windows centric.
>>The idea is to implement more general routines (like the new one
>>Frame3d) which may not have corresponding counterpart in Windows. The
>>interfacebase should be
>>platform independent layer, as much as possible, including graphic types
>>(and possibly others as well, it is just that GTK is about graphics).
>>The corresponding platform specific interface should implement the
>>abstract layer, rather than emulate Windows functions.
>>BTW, this concept will have to be taken much further, if it should work
>>properly - think about:
>>- GTK themes, which Lazarus does not respect at all currently.
>>- system color concept (clWindow, clBtnFace, etc.) which comes from
>>Windows and makes little sense on GTK
>>- keyboard accelerator system
>>- multimedia interface
>>
>
>I don't have anything against this, as long as you can keep everything
>implementable on every interface (be it win32 or qt or perhaps possible
>future interfaces for BeOS, DOS, etc).  However, I think it may be a tad
>erroneous to put the GTK-centric stuff in winapi.inc.  Perhaps you could
>move that stuff (eg, Frame3d and CreatePixmapIndirect) to gtkapi.inc and
>gtkapih.inc and put only Windows-API methods in winapi.inc and winapih.inc.
>Then, you can create gtkgtkapi.inc and gtkgtkapih.inc files in the gtk
>interface to implement these.  Likewise, I could create win32gtkapi.inc and
>win32gtkapih.inc files to emulate these things; ditto for qt and possible
>future interfaces.
>
>Keith
>
But this is exactly the point I tried to get to, I only used GTK just an 
example.
This is the reason I call for a creation of an abstract interface, which 
would be a superset of common (graphic) functions and use classes and 
types, platform independent, holding the information in platform 
independent way.

As an example, take the method TCanvas.Frame3d. The logic is as follow:

TCanvas,Frame3d -> call LCLAPI.Frame3d -> platform specific 
implementation in interface object (like DrawFrameBorder in Win32, 
gtk_paint_shadow in GTK, draw-shadow-point-by-point-because-this 
platform-does-not-have-native-impl in yet-another-platform, etc.

BTW, this approach is quite commonly used in many projects - and so you 
can have graphical backend like X11, SDL, libsvga, and so on...

Michal

>
>_________________________________________________________________
>     To unsubscribe: mail lazarus-request at miraclec.com with
>                "unsubscribe" as the Subject
>    archives at http://www.miraclec.com/list_archives/lazarus
>