[lazarus] My opinions

[Cliff Baeseman]

We had actually considered such a proposal before but the messaging solution
works in all cases no matter what the GUI rendering engine is. In the case
of QT where I need a extern C call anyhow the messaging solution works just
fine and frankly I do not see how it could be done any other way.

Take for instance last night I said ok lets integrate my QT Engine into the
LCL. I first copied the GTK interface object and then wacked out all of the
code. I put in one define in the interface unit and bang QT was in there. I
then ran the hello world example with no gui interface code. It ran so then
I just put a trace in the IntSendMessage to see what messages where being
passed. I placed in the code to call my QT engine and in about ten minutes I
had the whole deal running.

This does allow for us to change code in only one place and all of the GUI
code interacts in one place.  Say for instance that Delphi had originally
been built on top of this idea. They could have had delphi running on linux
in very short order. I have absolutely no doubt in my mind that I can
support any rendering kit in thais manner.

The fact of the matter is yes it is a lot more difficult to program in this
manner but the extreme flexibility is worth it.

Cliff

-----Original Message-----
From: Florian Klaempfl <Florian.Klaempfl at gmx.de>
To: Lazarus Mailinglist <lazarus at miraclec.com>
Date: Saturday, October 23, 1999 10:51 AM
Subject: [lazarus] My opinions


>I followed up the lazarus development for some time now and I think that
the message
>solution isn't a good way, i.e. sending a message for every small piece of
action.
>I thought a little bit more about that topic and I think to get an idea
>how to support multiple GUI APIs without a lot of ifdefs and without
breaking
>delphi compatiblity too much:
>
>Take the following class tree:
>
>TAbstractCanvas
>   |
>   |---TGTKCanvas
>   |---TWin32Canvas
>   |---TQtCanvas
>   ....
>
>TAbtractCanvas implements the common stuff, while the TGTKCanvas etc
implements the system dependend
>stuff
>Now you'll ask: where is TCanvas?
>TCanvas should be declared
>
>TCanvas : class of TAbstractCanvas
>
>and depending on the GUI API TCanvas is initializes appropriatly. The
constructors must be
>virtual, of course.
>
>BTW: This solution allows even to support multiple APIs with _one
executable_, you have only to
>set the class variables inn the init code.
>
>If this isn't appliable to the whol class library I think it's useful for
some seperated classes
>as TCanvas to avoid the large overhead of the message passing.
>
>_________________________________________________________________
>     To unsubscribe: mail lazarus-request at miraclec.com with
>                "unsubscribe" as the Subject
>    archives at http://www.miraclec.com/list_archives/lazarus
>