Board index » kylix » OpenCLX release

OpenCLX release


2004-04-07 10:04:09 PM
kylix1
Hi all,
Quite some time ago, I started the OpenCLX project. Since Borland's
FreeCLX hadn't been updated in quite some time, the goal was to get an
open sourced CLX that was updated to the current version of Kylix (3).
Things got bogged down when I was asked by Borland if I might be
interested instead in getting FreeCLX back running. Unfortunately,
getting FreeCLX revived never happened, and by the time I finished
waiting for them, I had moved onto other projects.
So much for history. I'm not back working on some projects that will
benefit from a revitialized opensource CLX. OpenCLX, therefore, is back
up and running. I have released the first version.
Why OpenCLX? Two reasons:
1) FreeCLX hasn't been updated since the original Kylix 1 release.
2) There is no support in Kylix Open edition for databases.
FreeCLX originally included all the base classes needed to support
databases (tdatabase, etc). However, no version of Kylix Open Edition
has ever shipped with a CLX that had this compiled in. This means, that
even third party database solutions couldn't be used.
The goal with OpenCLX, then, is to enable the user to use third party
open source database solutions, like ZeosLib. In fact, I hope to
actually include it in a later OpenCLX release.
OpenCLX still has a ways to go. But, if anyone wants to try it out, zip
over to sourceforge.net/projects/openclx
 
 

Re:OpenCLX release

I appreciate your enthusiasm but why not put the same effort towards
Lazarus? (lazarus.freepascal.org) Lazarus is a full featured open
source object oriented pascal compiler. Every day bugs are getting fix and
more and more features are becoming available.
"Kurt D L Fitzner" < XXXX@XXXXX.COM >wrote in message
Quote
Hi all,

Quite some time ago, I started the OpenCLX project. Since Borland's
FreeCLX hadn't been updated in quite some time, the goal was to get an
open sourced CLX that was updated to the current version of Kylix (3).
Things got bogged down when I was asked by Borland if I might be
interested instead in getting FreeCLX back running. Unfortunately,
getting FreeCLX revived never happened, and by the time I finished
waiting for them, I had moved onto other projects.

So much for history. I'm not back working on some projects that will
benefit from a revitialized opensource CLX. OpenCLX, therefore, is back
up and running. I have released the first version.

Why OpenCLX? Two reasons:

1) FreeCLX hasn't been updated since the original Kylix 1 release.
2) There is no support in Kylix Open edition for databases.

FreeCLX originally included all the base classes needed to support
databases (tdatabase, etc). However, no version of Kylix Open Edition
has ever shipped with a CLX that had this compiled in. This means, that
even third party database solutions couldn't be used.

The goal with OpenCLX, then, is to enable the user to use third party
open source database solutions, like ZeosLib. In fact, I hope to
actually include it in a later OpenCLX release.

OpenCLX still has a ways to go. But, if anyone wants to try it out, zip
over to sourceforge.net/projects/openclx
 

Re:OpenCLX release

Jeff Undercash wrote:
Quote
I appreciate your enthusiasm but why not put the same effort towards
Lazarus? (lazarus.freepascal.org) Lazarus is a full featured open
source object oriented pascal compiler. Every day bugs are getting fix and
more and more features are becoming available.
I appreciate the enthusiasm of the Lazarus developers. It's a great
project, and as soon as I can clear enough projects off my plate to have
the time, I will be happy to contribute towards it. However, right now
I need C++ and database access... neither of which Lazarus/FreePascal
can provide.
It's too bad FreeCLX was GPL and not LGPL, or else you could have
scavenged a lot of code. Perhaps with the death of Borland's support of
CLX they will donate the code. Then again, looking at their open-source
history...
C'est la vie.
I'm curious, though, why they are following the Delphi example. It
seems to me, they are making the same mistake Borland made. If they
made all the base classes and libraries in C++ it would be much easier
to interface them with the OS, widgets, other libraries, etc. Then if
they really want Pascal, make a quick and dirty Pascal conversion
interface to it. Would be less work, give access to a greater number of
potential developers, and would attract a wider audience in the end.
in the long run it would be much easier to do the reverse
 

{smallsort}

Re:OpenCLX release

"Kurt D L Fitzner" < XXXX@XXXXX.COM >wrote in message
Quote
Jeff Undercash wrote:
>I appreciate your enthusiasm but why not put the same effort towards
>Lazarus? (lazarus.freepascal.org) Lazarus is a full featured
open
>source object oriented pascal compiler. Every day bugs are getting fix
and
>more and more features are becoming available.

I appreciate the enthusiasm of the Lazarus developers. It's a great
project, and as soon as I can clear enough projects off my plate to have
the time, I will be happy to contribute towards it. However, right now
I need C++ and database access... neither of which Lazarus/FreePascal
can provide.
Check out qt. It has great connectivity to a whole plethora of db's, and
it's easy to make things "data-aware". The more I use it on both Linux and
Windows, the more I like it.
 

Re:OpenCLX release

Kurt, in your original post, you stated you wanted to add DB support namely
ZeosLib. You also stated your time and resources are limited. It seems the
reality is you are a one man show trying to beat a dead horse (Kylix).
There are others in the Lazarus community working on bringing in ZeosLib and
DB support. Furthermore, you are doing Borland's job without compensation.
Wouldn't your time and resources be better invested in a true community
effort like Lazarus?
Quote
It's too bad FreeCLX was GPL and not LGPL, or else you could have
scavenged a lot of code. Perhaps with the death of Borland's support of
CLX they will donate the code. Then again, looking at their open-source
history...
*WHY* would anyone want to use that code????????????
 

Re:OpenCLX release

Quote
I'm curious, though, why they are following the Delphi example. It
seems to me, they are making the same mistake Borland made. If they
made all the base classes and libraries in C++ it would be much easier
to interface them with the OS, widgets, other libraries, etc.
If a common API is used, it should not matter if the libraries are done
in C++ or in Pascal. Borland was too early as was about to change the
ABI. AFAIK, the GCC 3 ABI has not stabilized, so that Lazarus / Free
Pascal can use it. I don't know if they already do so.
-Michael
 

Re:OpenCLX release

Michael Schnell wrote:
Quote
If a common API is used, it should not matter if the libraries are done
in C++ or in Pascal. Borland was too early as was about to change the
ABI. AFAIK, the GCC 3 ABI has not stabilized, so that Lazarus / Free
Pascal can use it. I don't know if they already do so.
Kylix (Delphi)'s own ABI is more compatible to GCC 3's that the
FreePascal's ABI (related to the class/object keywords).
--
Regards,
Andreas Hausladen
 

Re:OpenCLX release

if they were ABI compatible you could link c++ libs to object pascal and
vice versa ?
actually lazarus link to GTK what is wrong on that ?
Andreas Hausladen a écrit:
Quote
Michael Schnell wrote:


>If a common API is used, it should not matter if the libraries are done
>in C++ or in Pascal. Borland was too early as was about to change the
>ABI. AFAIK, the GCC 3 ABI has not stabilized, so that Lazarus / Free
>Pascal can use it. I don't know if they already do so.


Kylix (Delphi)'s own ABI is more compatible to GCC 3's that the
FreePascal's ABI (related to the class/object keywords).


 

Re:OpenCLX release

honey wrote:
Quote
if they were ABI compatible you could link c++ libs to object pascal and
vice versa ?
Yes.
Quote
actually lazarus link to GTK what is wrong on that ?
GTK is written in C. You can already succesfully link C <->FreePascal,
but not yet C++ <->FreePascal. The `C' ABI is `well' documented.
Micha
 

Re:OpenCLX release

honey wrote:
Quote
actually lazarus link to GTK what is wrong on that ?
GTK is C framework, GTK+ is C++.
And Kylix can link against GTK the same as FreePascal can. The difference
for the C++ ABI is that FreePascal has 3 dwords in front of the first
virtual method in the VMT and all TObject virtual methods have positive
VMT indices. That could be worked around by using the "object" keyword.
But there FreePascal has the 3 dwords too. Kylix does not have these 3
dwords and gcc 3.x doesn't have them, too. So it is easier to map a Kylix
object to a gcc class than a FreePascal object/class to a gcc class.
--
Regards,
Andreas Hausladen
 

Re:OpenCLX release

let me try to understand :)
.it's seems to be clear that 'ideally' we (almost i) would like rock
solid os independant components library.
unfortunately today there is VCL, CLX, VCL for NET
and we woul'd like to have and 'Universal component library' !
..the best should have been to migrate completely VCL to linux and then
no need to create CLX (probably VCL are to much close to win32 to do
that or borland not put the task force to finish the complete port of
VCL and then need to rename it as CLX..)
.for now what can be done ?
- for non visual components such as DB components they rely only on
TCP/IP low level .
what do you think about ZeosDB ?
perhaps i'm wrong but in all case it not seem to be a big problem
due to low interaction with OS and higher level of TDasaset , TQuery ...
classes
- the biggest problem are visual components
it's sure that wxwidgets seems to be a beautiful library but
what's wrong with GTK ? is there API limitations ?
i mean if tomorrow (or after tomorrow :) ) there is an opensource GCL
delphi/Kylix/LRS package with all GTK wrapped in OP objects ?
i think i'll use it even ( not even also particularly ) on win32 side !
Micha Nelissen a écrit:
Quote
honey wrote:

>if they were ABI compatible you could link c++ libs to object pascal
>and vice versa ?


Yes.

>actually lazarus link to GTK what is wrong on that ?


GTK is written in C. You can already succesfully link C <->FreePascal,
but not yet C++ <->FreePascal. The `C' ABI is `well' documented.

Micha
 

Re:OpenCLX release

Ok, in that case do you need to code a specific linker ?
give more time to FPC team and wait next release to verify that linking
OP/C++ can be done ?
in both cases : GTK (C link) and wxwidget (C++link) OP class wrappers
will be required ?
there is also the backward compatibility problem, i mean public property
and methods of this dreamed component library should be the same as VCL
existing ones ?
Andreas Hausladen a écrit:
Quote
honey wrote:


>actually lazarus link to GTK what is wrong on that ?


GTK is C framework, GTK+ is C++.

And Kylix can link against GTK the same as FreePascal can. The difference
for the C++ ABI is that FreePascal has 3 dwords in front of the first
virtual method in the VMT and all TObject virtual methods have positive
VMT indices. That could be worked around by using the "object" keyword.
But there FreePascal has the 3 dwords too. Kylix does not have these 3
dwords and gcc 3.x doesn't have them, too. So it is easier to map a Kylix
object to a gcc class than a FreePascal object/class to a gcc class.


 

Re:OpenCLX release

honey wrote:
Quote
let me try to understand :)

.it's seems to be clear that 'ideally' we (almost i) would like rock
solid os independant components library.
unfortunately today there is VCL, CLX, VCL for NET
and we woul'd like to have and 'Universal component library' !
use java, don't problem with that and the performance are good when we
know coding
--
Borland rulez pages.infinit.net/borland
 

Re:OpenCLX release

Marc,
you are probably right, but...
i must admit the following fact :
just after my guirlfriend i love OP :)
and as a linux novice i'm wondering what is a good way/long term
for this visual componet library !
-pros and cons using directly xlib
-pros and cons using Qt
-pros and cons using Gtk
-pros and cons using wxwidgets
or something else ?
is there any idea taking in consideration following points for an
universal OP visual component library ?
-open source
-plateform independant
-99% backward compatible with win32 vcl
(okay only 98% compatible :) )
Regards
Olivier
Marc Collin a écrit:
Quote
honey wrote:

>let me try to understand :)
>
>.it's seems to be clear that 'ideally' we (almost i) would like rock
>solid os independant components library.
>unfortunately today there is VCL, CLX, VCL for NET
>and we woul'd like to have and 'Universal component library' !



use java, don't problem with that and the performance are good when we
know coding



 

Re:OpenCLX release

Marc Collin
I really wonder why you waste your time in the Kylix Forums.