[lazarus] LCL Structure Discussion

[Michael A. Hess]

Baeseman, Cliff wrote:
> 
> Well first of all it will gain us access to every widget set on a even
> ground.

You still lost me here. How is it more even then what we are doing now?
We intend to move the code to a method similar to wndproc where all of
the signals and messages go through one method for a control. (At least
that is what we discussed 2 weeks ago.) That means that all interface
units would talk to the LCL and the LCL would talk to them in the exact
same manner. Isn't this an even ground?

> It would also give us access to all of the C++ libs and there
> is a bunch of them. Say for instance we needed to load a image to a
> widget. I could do it inside of the library with just a few simple
> lines of C++ because of all of the libs that already exist for it.

You have lost me here again. How does this existing C++ library add an
image to a GTK widget?

> I definately see this as a way to speed along development. Say we wish
> to use the editor for GEdit or KWrite we can do this with a couple of
> lines of code in the library to expose the methods.

So why don't you just expose them with Pascal code the same way it has
been done for GTK? Why do you need this intermediate C++ library? For
that matter there is a gtkeditor widget that we could expose and use now
for the editor. It is what gIDE uses and it does everything Shane is
trying to do in Pascal. The reason he isn't using it is so that the LCL
Editor will be portable to other platforms.

Are you saying that we should move the portability issue out into
another set of libraries that are written in C++? I have already been
pounded on because I felt that we should rely on the external widget
libraries which are written in C. If people want new widgets they have
to write them in "C" or add a whole lot more connection to the widget
set in the LCL. Are you suggesting now that new features for the LCL
will have to be written in C++ in an external library? Then why are we
doing any of this in Pascal? Just recreate Builder++ instead.

Before anyone things I am against or shooting down this idea, I am not.
It is just that I don't understand the advantages or benefits of it.

 
> Now that I think about it a little I would not be suprised if borland did
> not go this route.
> 
> Cliff
> 
> -----Original Message-----
> From: Michael A. Hess [mailto:mhess at miraclec.com]
> Sent: Tuesday, October 12, 1999 10:00 AM
> To: lazarus at miraclec.com
> Subject: Re: [lazarus] LCL Structure Discussion
> 
> Cliff Baeseman wrote:
> >
> > I would like to open up something here for discussion.
> >
> >
> > Now here is where I am going with all of this. Say I was to build a
> > C++ library that could handle all of the UI calls by passing something
> > like IntSendMessage(int Message, int WidgetID,  pointer
> > varDataRecord). We then define a single call back routine that would
> > pass back the WidgetID and a event message constant.
> 
> What am I missing here. Isn't this exactly the same thing we are already
> doing? The only difference is that you have it as an external library
> instead of linked code. Is that the difference?
> 
> > The linux side of the world would have to be written in C++ ....
> 
> Why??
> 
> --
> ==== Programming my first best destiny! ====
> 
> Michael A. Hess      Miracle Concepts, Inc.
> mhess at miraclec.com   http://www.miraclec.com
> 
> _________________________________________________________________
>      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

-- 
==== Programming my first best destiny! ====

Michael A. Hess      Miracle Concepts, Inc.
mhess at miraclec.com   http://www.miraclec.com