[lazarus] CVS changes

[Chris]

I've been looking at wxWindows, as a platform independant gui.  It's quite
good, and compiles under several versions of OS.  I'm wondering if it might
be worthwhile trying to port the interface to that.
http://www.wxwindows.org/

I've used a couple of apps build with it, and I must say it seems very
snappy.
Chris

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


> 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
> >
>
>
>
> _________________________________________________________________
>      To unsubscribe: mail lazarus-request at miraclec.com with
>                 "unsubscribe" as the Subject
>     archives at http://www.miraclec.com/list_archives/lazarus
>