[lazarus] Progress

[Samuel Liddicott]

> -----Original Message-----
> From: Michael A. Hess [mailto:mhess at miraclec.com]
> Sent: Wednesday, September 01, 1999 12:48 AM
> To: lazarus at miraclec.com
> Subject: Re: [lazarus] Progress
>
>
> Marc Weustink wrote:
> >
> > Why not ?
>
> For the reason I explained right after.
>
> > >The reason is due to the fact that ALL and I mean ALL of the
> > >generation of the Button, how it looks, how it is drawn, how it
> > >reacts to events is found in and controled by the GTK library.
> >
> > OK, but if you found a way to pass drawing to the canvas of the
> > LCL-button to the widget-librar, then I cant see why it's wrong to
> > inherit a LCL button and add your own stuff.\
>
> Because you can't. All of the events that are generated by a component
> are done IN the GTK library. The LCL does not generate any events for
> any components, EVER.

Why not?  Delphi does, and often.  The API and Delphi both generate messages
which are handled by the wndproc and then the message handlers.  What do you
think all the CM_ messages are?

> It only receives events that are passed to it from
> the GTK lib that were generated by the GTK widget that was made by the
> GTK library. The LCL is acting as a wrapper around the GTK library
> widgets and the wrapper is being made to look like the same kind of
> classes found in Delphi. However the LCL doesn't have any control over
> the widgets themselves. They are made by the GTK lib.

This is exactly the same situation with delphi and windows

> You can not
> override the drawing of a GTK widget from within the LCL. That is part
> of the C code within the GTK library.

Then, we are scuppered from the start.  But I don't actually believe this.

> > If you have to do this in the lib's then youend up implementing one
> > for every lib!
>
> Well it is done in the lib because that is were the GTK code is. Yes if
> you want to create a new fancy component and want it to be used with
> whatever API someone wants to use then you need to build it for EVERY
> API.

No, you just need to implement TControlCanvas different for every API, which
we expected anyway.

> If you don't then you will be subjecting the user to only using the
> API that you designed it for. There isn't anything we can do about that.

TControlCanvas and API:LCL message abstraction, and some limited LCL:API
abstraction (move widget, hide widget, change parent etc) will manage it
all.  Then as long as the developer sticks to the delphi VCL methods it will
work fine with the LCL.  Thats why I DO need to modify the LCL slightly, so
the final developer doesn't have to do it every time.

> > Thats what I like about Lazarus. We shouls use core componets
> > available in all API's or components based upon/constructed by these
> > core components. If I see it correcvtly these should be in the LCL and
> > not in the API-lib.
>
> Again you don't seem to understand how the APIs work. Lazarus and the
> LCL doesn't create ANYTHING. All components are created in the GTK lib.

With delphi, they are all created by windows.

> There are no core components to create in the LCL.

There will be, or we are scuppered.  Most of the "extra" delphi components
are based on a TWinControl with custom painting.  If GTK won't allow this,
it will die shortly anyway.

> Everything is created
> by the widget library. The LCL is acting as a standard wrapper to manage
> the widgets no matter which API is used to create them.

Sam as windows.

> As I mentioned
> earlier this wrapper is just being made to LOOK like the Delphi class
> library

which is what I need to complete

> but it doesn't actually do the work of the Delphi VCL.

err... it does actually, pretty much, and will even more by the time I have
finished with it.

> It was mentioned in the first post about "waiting to find out about GTK
> primitives". There are NO GTK primitives. GTK is the widget library that
> creates components in windows with events. The GTK widget library is
> built ontop of the GDK Graphics Library.

OK, primitives was the wrong word, I should have said "basic operations on
widgets" then.

> Here is a layout of the libs. when using GTK+
>
>    -------------------------------------------------------
>    |                    Application                      |
>    -------------------------------------------------------
>                              |
>                              |
>    -------------------------------------------------------
>    |                    Lazarus/LCL                      |
>    -------------------------------------------------------
>       |                                   |          |
>       |                                   |          |
>       |                                   |      ---------
>       |      |----------------------------|------|  GTK  |
>       |      |                            |      ---------
>       |      |                            |          |
>       |      |                            |          |
>       |      |                        --------------------
>       |      |      |-----------------|        GDK       |
>       |      |      |                 --------------------
>       |      |      |                           |
>       |      |      |                           |
>    -----------------------            --------------------
>    |        GLIB         |            |      X Window    |
>    -----------------------            --------------------
>
>
> When using Gnome it gets even more complex because another layer which
> is Gnome sites inbetween Lazarus and the GTK+ library.
>
> What I am trying to make everyone understand is that the LCL doesn't
> call any primitives to actually draw anything as far as components go.
> You might call some primitives to do some actual drawing within a GTK
> Drawing Widget

wow.  Sounds like TControlCanvas will work then.

> but you can't CREATE or make an OwnerDrawn component when
> using GTK unless you create it in "C" and add it to the GTK library.

Well maybe we need to implement it by insering a GTK Drawing Widget into the
widget then.

> I ask again.    Is this clear???

This is, but having heard you I don't see what it changes.

Sam