[lazarus] CVS changes

[Mattias Gaertner]

On Sun, 03 Feb 2002 19:18:51 +0100
Michal Bukovjan <michal.bukovjan at openone.cz> wrote:

> >>likewise Graphics -> Graphics and GraphType.
> >
> >Bad: loosing delphi compatibility in the lcl
> >Good: breaking circles
> >The compiler doesn't seems to have problems with the current lcl inner circles, so why the change?
> >
> 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.

Right. Although, I would call them Delphi centric.
The advantage is that Delphi code needs less changes to work with the LCL.


> 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.

The abstract interface should define the base what we want to have on all platforms.
To get the best from both worlds, emulation has to be done. I see no problem, in emulating windows functions. There are already some parts in the LCL that are more gtk specific than win32 specific, so the win32 interface emulates gtk functionality.


> 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.

Not entirely correct. Graphic systems like the java awt does not respect themes.
The LCL uses the interface specific widgets/objects/buttons/... . But, you are right, the LCL should respect it more. (e.g. colors, borders)


> - system color concept (clWindow, clBtnFace, etc.) which comes from 
> Windows and makes little sense on GTK

They can be emulated. But the gtk knows more than colors. Instead of colors it can also use pixmaps. The LCL should support both too.


> - keyboard accelerator system

This is mostly a problem of the menu/popup menu. They need a lot of work.


> - multimedia interface

Hmm. Interesting point. 


> >>Something lik C header files. Maybe in future they could contain 
> >>abstract class declarations as well, I would like to discuss this first, 
> >>though.
> >>
> >
> >I think, this depends on every case. What classes do you think of?
> >
> TCanvas, TBitmap - the classes whose methods are actually implemented by 
> the interface.pp methods it calls.
> I very much miss C header files here (the split between declaration and 
> implementation).For instance, we often pass things like LogBrush, 
> hBitmap, etc. - Windows centric, why not use platform independent 
> TBrush, TBitmap and work with those?

1. Delphi compatibility.
2. most LCL objects can exists without a handle. A handle like hBitmap is the interface specific representation of/connection to a TBrush.

We should not change the interface functions, just to make them look somewhat nicer.
But, I think, we can add some alternative functions to the interfacebase, that are more readable. For example functions with parameter names like wParam, LParam are all but helpful.


> Again, this was not a problem as we were emulating Windows API, but once 
> we start to take advantage (or properly use) features of GTK widgets, 
> which go beyond what emulating Windows API provides, we are at a loss.

For example?


Mattias