[lazarus] Portable lib

[Sergio A. Kessler]

"Michael A. Hess" <mhess at miraclec.com> el día Thu, 29 Apr 1999 19:06:05 
-0400, escribió:

>Nicolas Aragon wrote:
>> 
>> First: if design is right, you don't have to touch the code in one
>> part to correct or inprove the others. I know it doesn't sound too
>> impressive as of now, but I hope a first sample would show it clearly.
>
>I have to agree with this thought myself. It is one of the reasons I
>wasn't to crazy about the Megido project. Now for the IDE I don't know
>if it is really all that much of a concern as to whether it is portable
>with other libraries. The FCL is where I think portability should be
>addressed.

Agreed 100% with you.
I have tryed to say this all this time along...
(but maybe I'm not very good explaining or convincing :)

we have: FCL/
             win32/
             inc/         (portable)
             ...
             linux/
                   gtk/
                   qt/
                   gnome/
                   motif/
                   ...

no ?

Even I think many Lazarus code should go in fcl/linux/gtk


 I am a Gnome fan myself so I am on the gik+ bandwagon but you
>can't deny the KDE Qt existence. There is alot of good software written
>for that desktop and I am sure that there will be developers that will
>want to write to that desktop using the widgets designed for it. For
>that matter Gnome is written using gti+ plus but it has it's own set of
>high level widgets that are based on gtk+ that Gnome developers would
>want to use.

very good high level widgets, including dbgrids in the gnome-db
package  :)

>> Second: if you later add support for Xlib, text mode (both could be
>> useful for installations programs), another OS'es...
>
>Right. Linux isn't the only game in town. Solaris isn't going anywhere
>anytime soon. I can see FPC being used on Solaris one day and they might
>want a Motif interface.
>
>> Third: it's clear that, this way, you don't have to recompile like
>> you'd have to do with defines. But you could even change the
>> underlying lib without re-linking. A program could check which library
>> is available at run-time and dynamically link to it. The IDE itself
>> could manage a number of different libraries.
>> 
>> Yes, it seems toooo far from the present, when we don't have one :-)
>> But if it isn't done now, it will be very difficult to do it later.
>
>Agreed we aren't there yet or even close to that aspect as far as I am
>concerned. We also have to consider any problems that might arise out of
>a Delphi copyright issue. So we don't need to rush into it.
> 
>> But just because this, I will like to finish a complete example of
>> what I say. Then you could judge if it's acceptable to you. I don't
>> want just to say "this is the right thing to do (C)", and less to you
>> that have working code. If I propose an alternative, I want it to be
>> ready to compile and offer to change actual code seamlessly.
>
>I'll be very interested to see your example code when it is ready. Again
>I don't know if we even need to worry about having to change the
>existing code being used for the IDE development. We still need a good
>GUI IDE for Linux for FPC so I'd rather see something built, anything
>built which will speed up further development. After it is built and
>running it will give us a good test application to slowy modify
>components to a new format if needed.
> 
>> Hope you will slow down or I will be unable!! :)
>
>Yeah! Are these guys greased lighting or what!

well, I have to agree too.
IMO, following the FCL way does not modify Lazarus roadmap and
bring us portability.

Sergio