[lazarus] CVS changes

[Michal Bukovjan]

Mattias Gaertner wrote:

>On Sun, 03 Feb 2002 02:29:58 +0100
>Michal Bukovjan <michal.bukovjan at openone.cz> wrote:
>
>>- split LCLLinux into LCLLinux and LCLType, 
>>
>
>ok
>
>
>>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.
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 chose breaking Delphi compatibility, because
- Delphi is not well designed in this respect (very Windows centric, 
which is understandable since it was not designed for multiple platforms 
in the first place)
- Kylix breaks this kind of compatibility as well (but is neither 
abstract, it relies on Qt for a change :-()
- single code representation

Lazarus should create its own superset of features, with interfaces 
implementing the necessary subsets natively, possibly emulating others

>
>
>>The LCLType unit and GraphType unit contain 
>>constants and types commonly used, the purpose of the split is that we 
>>can now reference common types (like TAlignment) from interfaceobject 
>>units without circular references, or without the need to declare them 
>>twice.
>>
>
>There are no real circles between LCL and the widget-interfaces.
>The only circle is the interfaces.pp. A few weeks ago Marc and I tested successfully to break even this one. The price was just to add a further unit to the main program source.
>The only advantage was, that we can skip the remove intefaces.ppu in the Makefiles. So, we kept the current solution.
>
>
>>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?
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.

>
>
>
>>BTW, I ran into some compiler bugs:
>>
>>1) Compiler mishandles units that begin with the same string, i.e. when 
>>I have units Graphics and GraphicsType, the second is never found!
>>
>
>Can u give an example?
>
As I wrote, Graohics.pp and GraphicsTypes.pp (this was its original 
name). For some reason, compiler only sees one of those. The same 
happened for LCLLinux.pp/LCLLinuxType.pp
I think when compiler looks up units, it compares by the shorter string.

Hmm, now I tried to create an example, and it works. Strange.
But renaming the unit GraphTypes to GraphicsTypes should resurface the 
error.

>
>>2) Inheritance seems to function somewhat strange - for example, try to 
>>create:
>>
>>type TMyButton = class(TBitBtn);
>>
>>Whenever you create this type of button on a form, it is never 
>>displayed. Weird. TBitBtn button is of course OK.
>>
>
>Yes it is. Can u send me an example?
>
Strange, I could not reproduce exactly this behaviour (it works now), 
now the compiler errors out straight away:
1) Declare the new class in buttons.pp, just

  TMyButton = class(TBitBtn);

When you declare this descendant right after TBitBtn declaration, this 
works (it did not for me yesterday, but I was experimenting with 
TSpeedButton as well, so cannot reproduce now)
You can test it working on examples/checkbox.pp (The Button2 "toggle 
checkox" TBitBtn).
On line 208, change the Button2 creation to Button2:= 
TMyButton.Create(Self);
As I said, this works.

2) Now move the declaration down *AFTER* the TSpeedButton declaration.
It will not compile, blaberring something about:

buttonglyph.inc(41,3) Error: Symbol can't be published, can be only a class
buttonglyph.inc(42,3) Error: Symbol can't be published, can be only a class
buttonglyph.inc(43,1) Error: Symbol can't be published, can be only a class
speedbutton.inc(229,3) Error: Symbol can't be published, can be only a class
speedbutton.inc(230,1) Error: Symbol can't be published, can be only a class
buttons.pp(514) Fatal: There were 5 errors compiling module, stopping
make[1]: *** [allunits.ppu] Error 1
make[1]: Leaving directory `/home/michal/source/lazarus/lazarus/lcl'
make: *** [lcl] Error 2

I could reproduce this just by moving the declaration.
As I said, I was playing with this unit, but the not appearing 
descendant class might have been a result of this compiler error just in 
another form. (What I tried was trying to reimplement TSpeedButton as a 
descendent of TBitBtn. No go, even if I made a declaration just as the 
above! But it compiled, but did not show anything.)

Michal

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