[lazarus]

[Shane Miller]

This is very important, obvoiusly, to figure this out before proceeding,
however.......

What do you all think of this.  Simniliar to the Windows environment, why
not simply create functions like SENDMESSAGE and CREATECOMPONENT in out
units that are calls to external functions.  In a language.pp file we could
define a global variable that is called............libraryname or something.
If we want to use QT, we set it to QT, else we set it to gtk.  We can then
link the correct libraries into our code.  We write one library for each
language we want to use that contains functions called SENDMESSAGE and
CREATECOMPONENT that can do whatever they need to do to get the "stuff"
done.  This way we could remain independant of the underlying libraries.

I know that it won't be this simple, but I think we could start coding a
gtk.pp unit with the appropriate createcomponent and sendmessage functions.
We would need a few functions to get handles (window handles) and such, but
not a big deal....

Thoughts?  (don't flame too harshly)

Mind you I am interested in going this way because I think we can start
quickly, it would be very flexible, etc.

Shane

-----Original Message-----
From: Baeseman, Cliff <Cliff.Baeseman at greenheck.com>
To: lazarus at miraclec.com <lazarus at miraclec.com>
Date: Sunday, June 27, 1999 11:17 AM
Subject: RE: [lazarus]


>michael are you suggesting possibly going all the way down to the XLevel
and
>starting there?
>
>  Just trying to get a little flexibility out of this. The GTK + tool kit
is
>programmed very flat. It does not lend it self very well to object based
>programming. This in my opinion is why everyone has such a time with it.
>
>Programming the interface in pascal is ok by me as long as I face no
>restrictions.
>
>
>Cliff
>
>
>
>-----Original Message-----
>From: michael at tfdec1.fys.kuleuven.ac.be
>[mailto:michael at tfdec1.fys.kuleuven.ac.be]
>Sent: Sunday, June 27, 1999 1:07 PM
>To: lazarus at miraclec.com
>Subject: RE: [lazarus]
>
>
>
>
>On Sun, 27 Jun 1999, Baeseman, Cliff wrote:
>
>> Michael,
>>
>>    What we really need to define is a runtime implementation of something
>> such as the JVM for our gui development. Perhaps we need to define a
>common
>> interface that can be ported to all platforms.
>>
>> Something like this.   Our code -->  Interface  -->  GUI Subsystem.
>>
>> The Interface would be our library dll and the GUI Subsystem would be
>> platform code.
>>
>> The interface code would likely have to be written in C or in C++ to talk
>to
>> the GUI of the platform on its level.
>
>I disagree. It is perfectly possible to write it in pascal. The RTL is a
>good
>example of this. I am strongly opposed to mixing languages, as it is only
>likely to create problems. As an example, I would mention the libc -> glibc
>transition in the linux community: It has given us many problems. Not to
>mention the a.out -> ELF transition. All C stuff which forces us to adapt
>our code for no good reason at all. (I never saw the need to go from libc
to
>glibc in the first place !!)
>
>Also, if you GUI subsystem changes, you may well have to adapt 2 sets of
>code: The pascal set and the C set. Remember the hassle to go from gtk 1.0
>to
>1.2 !
>
>>
>> This would be a great undertaking but our GUI code would be totally
>portable
>> as long as the Interface definition did not change.
>>
>>
>> This is the most flexible arrangement that I can think of...
>
>Agreed, with the exception that I think you can (and should) write your
>interface in pascal.
>
>Michael.
>
>_________________________________________________________________
>     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
>