Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 1999-04

Portable lib

6 messages · 5 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Michael A. Hess
to Cliff Baeseman: Why not just join Lazarus and place in the conditional defines for the win32 stuff. We…
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. 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.

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.

Show quoted text 8 lines
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.

Show quoted text 5 lines
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!

==== Programming my first best destiny! ==== Michael A. Hess Miracle Concepts, Inc. http://www.miraclec.com

Reply by email

Nicolas Aragon
to Cliff Baeseman: Why not just join Lazarus and place in the conditional defines for the win32 stuff. We…

Hello,

Why not just join Lazarus and place in the conditional defines for the win32 stuff.

I just talked about Win32 as an example. There are more advantages.

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.

Second: if you later add support for Xlib, text mode (both could be useful for installations programs), another OS'es... you will have a code full of defines and, what's worse, you could have managed some feature with an eye put on implementation, and it won't be so easily maintenable. If you keep the separation between classes, it's much more difficult to fall in such distractions. It's like the lines in the roadway when you must adjust to an interface definition.

Just an example: our other thread about boxes, panels, memos and scrollbars. If you'd just want to follow the gtk way of doing things, you should use typical gtk boxes like most other gtk programs. But you don't. Why? because you want to keep as possible the way Delphi treats controls positioning. At some point, when a difficult problem arises, you'd probably feel the temptation to change some behaviour and code relying on this behaviour would be difficult to translate, if possible at all.

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.

I finally bought Gamma's book and, looking for bridge pattern, I found this in the first page:

"Consider the implementation of a portable Window abstraction in a user interface toolkit..."

Not bad example :)

We would be more than happy to work with you!

I will like to join efforts, I think you are doing a fine job... who said "show me the code"? :-)

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.

The problem I've found now it's about passing method references as parameters. I think Michael is checking it now. In the meantime I'll try to familiarize with your code. Hope you will slow down or I will be unable!! :)

I understand your position on a cross platform tool ;)

Mine is clear ;)

greetings

Nico

Reply by email

Sergio A. Kessler

"Michael A. Hess" el d�a Thu, 29 Apr 1999 19:06:05 -0400, escribi�:

Show quoted text 11 lines
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

Show quoted text 6 lines
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 :)

Show quoted text 37 lines
> 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

Reply by email

Nicolas Aragon

[Crossposted to Megido General and Lazarus lists]

Hello,

When I joined Megido project some months ago, it looked great to me to create a portable programming environment, not like Delphi which is strongly attached to one O.S.

I won't discuss again the reasons or means to build a portable lib, because they appear too obvious to me, and seem to be a hieroglyphic to everybody else.

Now that we can program Win32 GUI apps with FPC, I think the waste is even clearer so I've decided to make it as a personal project.

I intend to work alone and I feel no hurry to get results. Features will be minimal: a few controls running both over gtk and winapi, forms designer, object inspector, and basic database support.

Code will be published under LGPL at:

http://www.clubdelphi.com/nico/

Megido: please send any comments to because I'll
unsubscribe from this list.

greetings

Nico

Reply by email

Cliff Baeseman
to Nicolas Aragon

Why not just join Lazarus and place in the conditional defines for the win32 stuff.

We would be more than happy to work with you!

I understand your position on a cross platform tool ;)

Cliff

Earlier message 40 lines
-----Original Message----- From: Nicolas Aragon Sent: Thursday, April 29, 1999 12:30 AM To: ; Subject: [megido-general] [lazarus] Portable lib [Crossposted to Megido General and Lazarus lists] Hello, When I joined Megido project some months ago, it looked great to me to create a portable programming environment, not like Delphi which is strongly attached to one O.S. I won't discuss again the reasons or means to build a portable lib, because they appear too obvious to me, and seem to be a hieroglyphic to everybody else. Now that we can program Win32 GUI apps with FPC, I think the waste is even clearer so I've decided to make it as a personal project. I intend to work alone and I feel no hurry to get results. Features will be minimal: a few controls running both over gtk and winapi, forms designer, object inspector, and basic database support. Code will be published under LGPL at: http://www.clubdelphi.com/nico/ Megido: please send any comments to because I'll unsubscribe from this list. greetings Nico _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject

Reply by email

Shane Miller

Perhaps I've missed soemthing, but what are we talking about. Exactly how are you saying things should be different? Should the code be included with FCL? I'm not understanding what the desire is and how to accomplish it.

Shane

>> "Sergio A. Kessler" 04/29 7:25 PM >>>

"Michael A. Hess" el d�a Thu, 29 Apr 1999 19:06:05 -0400, escribi�:

Show quoted text 11 lines
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

Show quoted text 6 lines
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 :)

Show quoted text 37 lines
> 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

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject

Reply by email