Board index » kylix » ANN: Universal Object Pascal Library (UOPL)

ANN: Universal Object Pascal Library (UOPL)


2004-11-05 11:06:04 PM
kylix2
ANN: Universal Object Pascal Library (UOPL)
sourceforge.net/projects/uopl/
The goal of the project is to develop a cross product
(initial Delphi and Free Pascal / Lazarus) development
library. This will allow the developer to choose between
the standard libraries (VCL and LCL) and use the UOPL in its
place. Programs will seamlessly move between the two
products allowing you to compile for W32, AMD64, Linux and
Mac OS X. In addition, major improvements will be added to
the library including full UNICODE support. The project is
currently looking for interested developers. We are in need
of programmers with a strong background in UNICODE,
variants, and the GTK+ library.
Please contact me if you are interested in joining the project.
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 
 

Re:ANN: Universal Object Pascal Library (UOPL)

On 2004-11-05, Thomas Miller < XXXX@XXXXX.COM >wrote:
Quote
ANN: Universal Object Pascal Library (UOPL)
sourceforge.net/projects/uopl/

The goal of the project is to develop a cross product
(initial Delphi and Free Pascal / Lazarus) development
library. This will allow the developer to choose between
the standard libraries (VCL and LCL) and use the UOPL in its
place. Programs will seamlessly move between the two
products allowing you to compile for W32, AMD64, Linux and
Mac OS X. In addition, major improvements will be added to
the library including full UNICODE support. The project is
currently looking for interested developers. We are in need
of programmers with a strong background in UNICODE,
variants, and the GTK+ library.

Please contact me if you are interested in joining the project.
Several such projects have been announced over the years, and all are likewise
broad in their statements. (to your credit, you don't mention C# and JVM)
However what I miss is even a very skimpy description on how you want to
tackle the obvious problems (VCL being Windows centric, message passig based and
copyrighted, LCL being slightly GTK biassed, and methodproc based, FPC and Kylix
having totally different Unix runtime units etc).
Moreover, why do you need to program GTK+ btw, if you base on higher level toolkits
as VCL and LCL?
 

Re:ANN: Universal Object Pascal Library (UOPL)

Thomas Miller schrieb:
Quote
The goal of the project is to develop a cross product (initial Delphi
and Free Pascal / Lazarus) development library. This will allow the
developer to choose between the standard libraries (VCL and LCL) and use
the UOPL in its place. Programs will seamlessly move between the two
products allowing you to compile for W32, AMD64, Linux and Mac OS X.
Could you give us some more details about how this will be done?
Thanks!
 

{smallsort}

Re:ANN: Universal Object Pascal Library (UOPL)

Marco van de Voort wrote:
Quote
On 2004-11-05, Thomas Miller < XXXX@XXXXX.COM >wrote:

>ANN: Universal Object Pascal Library (UOPL)
>sourceforge.net/projects/uopl/
>
>The goal of the project is to develop a cross product
>(initial Delphi and Free Pascal / Lazarus) development
>library. This will allow the developer to choose between
>the standard libraries (VCL and LCL) and use the UOPL in its
>place. Programs will seamlessly move between the two
>products allowing you to compile for W32, AMD64, Linux and
>Mac OS X. In addition, major improvements will be added to
>the library including full UNICODE support. The project is
>currently looking for interested developers. We are in need
>of programmers with a strong background in UNICODE,
>variants, and the GTK+ library.
>
>Please contact me if you are interested in joining the project.


Several such projects have been announced over the years, and all are likewise
broad in their statements. (to your credit, you don't mention C# and JVM)

However what I miss is even a very skimpy description on how you want to
tackle the obvious problems (VCL being Windows centric, message passig based and
copyrighted, LCL being slightly GTK biassed, and methodproc based, FPC and Kylix
having totally different Unix runtime units etc).
As far as I am concerned, Kylix is in maintenance mode.
Until the compiler and IDE are opened up, then Kylix is a
dead end solution. But lets not argue about that. None of
us have a crystal ball.
The Lazarus project has already rewritten most of the core
VCL as open source. So there is no copyright issue if we
start with their code.
The Linux version is based mostly on GTK (as Kylix is based
mostly on QT). GTK doesn't have a licensing issue for using
it on commercial projects / products (that QT has).
Delphi and Chrome are the future for managed code. IMO,
Free Pascal and Lazarus are the future of native code.
The problem is that I need to (and want to) live in both
worlds for the next 5 years (at least). The biggest problem
is a consistent library. This is what this project is all
about. Taking the idea of CLX and making it work with
Delphi and Lazarus (any one here want native 64bit, win32,
Linux, and Mac support?).
Quote

Moreover, why do you need to program GTK+ btw, if you base on higher level toolkits
as VCL and LCL?
LCL is to GTK as CLX is to QT.
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

Re:ANN: Universal Object Pascal Library (UOPL)

We will be using a similar model to Lazarus using include
files. I haven't had time to dig down deep yet, but is
seems that the structure could be cleaned up a bit.
So for instance
/Source
/uopl
class.pas //Only ifdefs with includes
/includes
ClassDelphiWin.inc
ClassFPLWin.inc // Free Pascal Lazarus
ClassLinuxGTK.Inc
ClassMacGTK.Inc
ClassMacCarbon.Inc
This is something we will discuss immediately as well as
where to start the fork in the object hierarchy (TObject,
TPersistant, or somewhere in between).
We don't want to replace what is there, but have an
alternative. Every object will be named TuoplXXXXX or
TuoplClass.
If you want to be in on the discussion, join the list
sourceforge.net/mail/
I plan on starting things up on Wednesday.
theo wrote:
Quote
Thomas Miller schrieb:

>The goal of the project is to develop a cross product (initial Delphi
>and Free Pascal / Lazarus) development library. This will allow the
>developer to choose between the standard libraries (VCL and LCL) and
>use the UOPL in its place. Programs will seamlessly move between the
>two products allowing you to compile for W32, AMD64, Linux and Mac OS X.


Could you give us some more details about how this will be done?

Thanks!
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

Re:ANN: Universal Object Pascal Library (UOPL)

On 2004-11-08, Thomas Miller < XXXX@XXXXX.COM >wrote:
Quote
Marco van de Voort wrote:
>However what I miss is even a very skimpy description on how you want to
>tackle the obvious problems (VCL being Windows centric, message passig based and
>copyrighted, LCL being slightly GTK biassed, and methodproc based, FPC and Kylix
>having totally different Unix runtime units etc).

As far as I am concerned, Kylix is in maintenance mode.
Until the compiler and IDE are opened up, then Kylix is a
dead end solution. But lets not argue about that. None of
us have a crystal ball.
I don't fully agree, though you are partially right. Kylix is stil
way stronger.
Quote
The Lazarus project has already rewritten most of the core
VCL as open source. So there is no copyright issue if we
start with their code.
Sure. But why something new? Why not simply join Lazarus? What is the
added value? And are you really sure the things you quickly summon up
(like VCL on one side, and LCL on the other) aren't mutually exclusive?
That's why I reacted. Your proposal was so very vague. You want to
make something platform independant based on something that is
already pretty platform independant (like the LCL)
Quote
The Linux version is based mostly on GTK (as Kylix is based
mostly on QT)
The *nix version (*BSD and Mac OS X work too) is GTK1 based yes. Some work
is done for GTK2, and if there is enough manpower, Aqua and QT could also be
tackled.
Quote
GTK doesn't have a licensing issue for using it on commercial projects /
products (that QT has).
QT doesn't have a real license problem on *nix. GPL makes an exception for
libs deployed with the OS.
Quote
Delphi and Chrome are the future for managed code. IMO,
I don't know. Managed wise, the difference between the languages are much
smaller this time. If I'm forced to go .NET it might not be Wirthian.
Moreover Java still holds the high-ground.
Chrome will never get enough userbase, at least not the next half decade,
Delphi.NET will drop VCL.NET sooner or later.
Quote
Free Pascal and Lazarus are the future of native code.
For Pascal: yes, I think so. Borland won't let win32 die, it can confortably
generate money in the legacy market for a few years. However I don't except
much new major development on win32, except some syntactic sugar leftovers
from .NET syntax wise (like for-each in D2005).
However I'm already thinking so since 1997, and can remember Lazarus
conception.
Quote
The problem is that I need to (and want to) live in both worlds for the
next 5 years (at least).
If you start something, it will be at least 1-2 years just to get settled
and really start going. Typically one major iteration is needed to get the
direction right and all noses in the right direction.
Quote
The biggest problem is a consistent library. This is what this project is
all about. Taking the idea of CLX and making it work with Delphi and
Lazarus (any one here want native 64bit, win32, Linux, and Mac support?).
LCL is already like CLX. Lazarus already has all this.
I don't think it is doable to reach significant higher levels of compability
by putting a layer over LCL on one side, and CLX on the other.
Quote
>Moreover, why do you need to program GTK+ btw, if you base on higher level toolkits
>as VCL and LCL?

LCL is to GTK as CLX is to QT.
and win32 in both cases.
I think much more interoperability can be achieved more effectively by:
1) improving Lazarus and FPC, directly.
2) helping former delphi only projects to become more open to FPC/Lazarus.
(and then I mean actually helping, not just mailing)
3) doing header conversions, preferably working on both.
 

Re:ANN: Universal Object Pascal Library (UOPL)

Quote
Sure. But why something new? Why not simply join Lazarus? What is the
added value? And are you really sure the things you quickly summon up
(like VCL on one side, and LCL on the other) aren't mutually exclusive?
....or join the FreeCLX project, which also would be an alternative ;)
Quote
>GTK doesn't have a licensing issue for using it on commercial projects /
>products (that QT has).

QT doesn't have a real license problem on *nix. GPL makes an exception for
libs deployed with the OS.
Sorry, but you are wrong. From www.trolltech.com/products/qt/licensing.html:
"Qt Commercial Licensing
Use the Qt Commercial License to:
Build commercial software.
Build software whose source code you wish to keep private.
Two qualities of the Qt Commercial License should be emphasized:
It is a development license.
You must purchase a Qt Commercial License from Trolltech or from any of its authorized
resellers before you start developing.
For desktop applications, there are no royalties, runtime licenses, or other additional
costs."
Doing commercial applications requires you to have a development license.
Quote
Chrome will never get enough userbase, at least not the next half decade,
Delphi.NET will drop VCL.NET sooner or later.
I wouldn't be to sure. If you ask people, why they stay with Delphi, you
will again and again get "VCL" as a response. Borland isn't deaf, they must
have noticed that.
Quote
>Free Pascal and Lazarus are the future of native code.
I strongly doubt this. The team would need much more resources. For me
Free Pascal still is the same as it was 5 years ago - a few guys who find
it cool to play with compiler technology, and who start doing tons of
different things instead of finishing something.
If I recall correctly TThread was announced for FreePascal aproximately 4
years ago now. As far as I can see, it's still not working.
If development speed stays the same, FreePascal will take another few
years to get on par with the current Kylix compiler. And no, it does not
impress me that you can build "Hello World" on Win64. I don't sell
"Hello World" kind of programs ;)
Simon
 

Re:ANN: Universal Object Pascal Library (UOPL)

On 2004-11-08, Simon Kissel < XXXX@XXXXX.COM >wrote:
Quote
>Sure. But why something new? Why not simply join Lazarus? What is the
>added value? And are you really sure the things you quickly summon up
>(like VCL on one side, and LCL on the other) aren't mutually exclusive?

...or join the FreeCLX project, which also would be an alternative ;)
Nope, wrong license. LGPL is mandatory, and so is platform independance.
Quote
>>GTK doesn't have a licensing issue for using it on commercial projects /
>>products (that QT has).
>
>QT doesn't have a real license problem on *nix. GPL makes an exception for
>libs deployed with the OS.

Sorry, but you are wrong. From www.trolltech.com/products/qt/licensing.html:
See www.trolltech.com/products/qt/opensource.html :
.. This is completely different from the Qt Commercial Editions which cannot be distributed at all.
Which is why made the point about Qt installed with the OS.
I don't distribute Qt. I just access it from the host OS.
And GPL allows this. If Trolltech doesn't, afaik the above statement (open source version being under
GPL) is not valid.
Quote
Use the Qt Commercial License to:
Build commercial software.
Build software whose source code you wish to keep private.
That doesn't exclude similar features in the open source license, guaranteed in the GPL.
Quote
>Chrome will never get enough userbase, at least not the next half decade,
>Delphi.NET will drop VCL.NET sooner or later.

I wouldn't be to sure. If you ask people, why they stay with Delphi, you
will again and again get "VCL" as a response. Borland isn't deaf, they must
have noticed that.
I was at a D2005 launch, and Borland itself used pretty much always WinForms for
its demoes. VCL.NET is a migration technology.
However I do have some hopes a significant number of developers will remain on win32
for quite a while. A poll at the same launch showed that 4 (4!) of the +/- 120 people
present used D8 or .NET in general. And one of those 4 was dr Bob, who gave a presentation
for Borland.
Quote
>>Free Pascal and Lazarus are the future of native code.

I strongly doubt this. The team would need much more resources.
I see steady progress. If you don't, please use arguments.
Quote
For me Free Pascal still is the same as it was 5 years ago - a few guys
who find it cool to play with compiler technology, and who start doing
tons of different things instead of finishing something.
FPC is getting there. It is a mammuth task to do parttime, and you should understand
that, being in the same kind of business yourself.
FPC 1.9.x is a massive progression.
Quote
If I recall correctly TThread was announced for FreePascal aproximately 4
years ago now. As far as I can see, it's still not working.
TThread has been working since 1.9.2 afaik. Maybe you mean TMREWs, which is
indeed not implemented.
FPC is pretty much getting close to modern Delphi on a base system level.
There are a lot skeletons in the cupboard (two major ones, packages and C++
linking), and several smaller ones (dispinterfaces, implements style
delegation, a lot of variant stuff barely tested and its RTL parts
incomplete)
On the other hand, we have 5 working architectures, and aspire to have them
roughly on the same level this year, or early next at the 2.0 release.
Quote
If development speed stays the same, FreePascal will take another few
years to get on par with the current Kylix compiler.
Depends. I wouldn't be surprised if FPC didn't match Kylix or Delphi fully
even in ten years. But depending on your business and application kind, it
is already better than Kylix. Mainly with regards to application deployment,
platforms. nativeness etc.
I'm strongly starting to suspect you haven't seen the 1.9.x series yet. Then you are
right. 1.0.x series is in freeze since december 1999, which nearly perfectly matches
your 5 years of nothingness.
Quote
And no, it does not impress me that you can build "Hello World" on Win64.
I don't sell "Hello World" kind of programs ;)
("hello world" runs on AMD64 btw, win64 is only available in "solutions" for Itanium)
Neither do I, which is why I desperately need 64-bit memory support (I have a statstical
system that needs data in memory at work. I'm not 100% sure it will grow beyond the 3 GB border
yet, but it is getting closer and closer).
P.s. Doing advocacy for Cross-Kylix is fun and ok, but please remain reasonable.
 

Re:ANN: Universal Object Pascal Library (UOPL)

Marco van de Voort wrote:
Quote
On 2004-11-08, Thomas Miller < XXXX@XXXXX.COM >wrote:

>Marco van de Voort wrote:
>
>>However what I miss is even a very skimpy description on how you want to
>>tackle the obvious problems (VCL being Windows centric, message passig based and
>>copyrighted, LCL being slightly GTK biassed, and methodproc based, FPC and Kylix
>>having totally different Unix runtime units etc).
>
>As far as I am concerned, Kylix is in maintenance mode.
>Until the compiler and IDE are opened up, then Kylix is a
>dead end solution. But lets not argue about that. None of
>us have a crystal ball.


I don't fully agree, though you are partially right. Kylix is stil
way stronger.
Kylix is stronger, no doubt about it, but for how long?
Quote


>The Lazarus project has already rewritten most of the core
>VCL as open source. So there is no copyright issue if we
>start with their code.


Sure. But why something new? Why not simply join Lazarus? What is the
added value? And are you really sure the things you quickly summon up
(like VCL on one side, and LCL on the other) aren't mutually exclusive?
As others have mentioned here, they have no desire to
support Delphi directly. I need to live in both worlds for
some time. I need a library that allows me to do that.
I am not the only one that needs that.
Quote

That's why I reacted. Your proposal was so very vague. You want to
make something platform independant based on something that is
already pretty platform independant (like the LCL)
The LCL is OS independent, not development tool independent.
Quote


>The Linux version is based mostly on GTK (as Kylix is based
>mostly on QT)


The *nix version (*BSD and Mac OS X work too) is GTK1 based yes. Some work
is done for GTK2, and if there is enough manpower, Aqua and QT could also be
tackled.

Our efforts will focus on GTK 2 only. UNICODE support will
be a major development point.
Quote

>GTK doesn't have a licensing issue for using it on commercial projects /
>products (that QT has).


QT doesn't have a real license problem on *nix. GPL makes an exception for
libs deployed with the OS.

True, but is QT that much better then GTK? I don't know,
but maybe someone here can tell us all their impressions.
Quote

>Delphi and Chrome are the future for managed code. IMO,


I don't know. Managed wise, the difference between the languages are much
smaller this time. If I'm forced to go .NET it might not be Wirthian.
Moreover Java still holds the high-ground.

Chrome will never get enough userbase, at least not the next half decade,
Delphi.NET will drop VCL.NET sooner or later.
True, but very few GUI stuff is done in Java. Server side
it is king currently. I don't have any clue or opinion on
which one will win the war there.
Quote


>Free Pascal and Lazarus are the future of native code.


For Pascal: yes, I think so. Borland won't let win32 die, it can confortably
generate money in the legacy market for a few years. However I don't except
much new major development on win32, except some syntactic sugar leftovers
from .NET syntax wise (like for-each in D2005).

Exactly. And now Kylix is just going to get CLX updates for
the foreseeable future. Not much to get e{*word*277}d about.
Quote
However I'm already thinking so since 1997, and can remember Lazarus
conception.


>The problem is that I need to (and want to) live in both worlds for the
>next 5 years (at least).


If you start something, it will be at least 1-2 years just to get settled
and really start going. Typically one major iteration is needed to get the
direction right and all noses in the right direction.
I think the LCL _is_ the first iteration. If the goal of
LCL was to be universal, I would join it. But in its
mandate, LCL is there to support Free Pascal and Lazarus,
and I don't see that changing.
Quote


>The biggest problem is a consistent library. This is what this project is
>all about. Taking the idea of CLX and making it work with Delphi and
>Lazarus (any one here want native 64bit, win32, Linux, and Mac support?).


LCL is already like CLX. Lazarus already has all this.

I don't think it is doable to reach significant higher levels of compability
by putting a layer over LCL on one side, and CLX on the other.
I am not trying to make it compatible with CLX. I am not
trying to make it compatible with LCL. The project is to
make the library load as a VCL in Delphi and load as an LCL
in Lazarus and maintain as much compatibility as possible
between the too. Just like CLX was suppose to do between
Delphi and Kylix. In addition, with all the source
available, we can expand the library at will. Something
Borland has not done with the VCL and you can't do without
access to private members. You can do a lot, but not everything.
Quote


>>Moreover, why do you need to program GTK+ btw, if you base on higher level toolkits
>>as VCL and LCL?
>
>LCL is to GTK as CLX is to QT.


and win32 in both cases.

I think much more interoperability can be achieved more effectively by:
1) improving Lazarus and FPC, directly.
2) helping former delphi only projects to become more open to FPC/Lazarus.
(and then I mean actually helping, not just mailing)
3) doing header conversions, preferably working on both.

How does that help me with my current Delphi work? How does
that help the 100's of Delphi programmers that see Lazarus
as a real opportunity, but can't drop Delphi and need to
work in Lazarus when it makes sense, but mainly stay with
Delphi until Lazaus in more mature?
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

Re:ANN: Universal Object Pascal Library (UOPL)

Simon Kissel wrote:
Quote
>Sure. But why something new? Why not simply join Lazarus? What is the
>added value? And are you really sure the things you quickly summon up
>(like VCL on one side, and LCL on the other) aren't mutually exclusive?


...or join the FreeCLX project, which also would be an alternative ;)
Kylix is a dead end. No news on the IDE or compiler front
was not good. I don't see them giving it away either. So
Kylix will be nice for a while longer and has some legs left
with the FreeCLX project, but in the end, it is a dead end.
If I had anything in CLX already, then I would probably
join, but I don't, so I see LCL as a better long term bet.
Quote


>>GTK doesn't have a licensing issue for using it on commercial projects /
>>products (that QT has).
>
>QT doesn't have a real license problem on *nix. GPL makes an exception for
>libs deployed with the OS.


Sorry, but you are wrong. From www.trolltech.com/products/qt/licensing.html:

"Qt Commercial Licensing

Use the Qt Commercial License to:
Build commercial software.
Build software whose source code you wish to keep private.

Two qualities of the Qt Commercial License should be emphasized:

It is a development license.
You must purchase a Qt Commercial License from Trolltech or from any of its authorized
resellers before you start developing.

For desktop applications, there are no royalties, runtime licenses, or other additional
costs."
I still have to buy it even for the the simplest of apps and
at $ 7480, that is more then I am willing to pay.
Quote

Doing commercial applications requires you to have a development license.


>Chrome will never get enough userbase, at least not the next half decade,
>Delphi.NET will drop VCL.NET sooner or later.


I wouldn't be to sure. If you ask people, why they stay with Delphi, you
will again and again get "VCL" as a response. Borland isn't deaf, they must
have noticed that.
Yes they are!!!! Why do you think Kylix is where it is.
Quote


>>Free Pascal and Lazarus are the future of native code.


I strongly doubt this. The team would need much more resources. For me
Free Pascal still is the same as it was 5 years ago - a few guys who find
it cool to play with compiler technology, and who start doing tons of
different things instead of finishing something.

If I recall correctly TThread was announced for FreePascal aproximately 4
years ago now. As far as I can see, it's still not working.

If development speed stays the same, FreePascal will take another few
years to get on par with the current Kylix compiler. And no, it does not
impress me that you can build "Hello World" on Win64. I don't sell
"Hello World" kind of programs ;)
The biggest problem I see is that Delphi developers loose so
much when moving over, it isn't worth time. With this new
UOPL, they won't be loosing anything!!! Worst case is that
we will end up with a better VCL then what comes standard
with Delphi. You can then buy the Pro version to get
Enterprise type capability.
Quote

Simon
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

Re:ANN: Universal Object Pascal Library (UOPL)

On 2004-11-08, Thomas Miller < XXXX@XXXXX.COM >wrote:
Quote
>>us have a crystal ball.
>
>
>I don't fully agree, though you are partially right. Kylix is stil
>way stronger.

Kylix is stronger, no doubt about it, but for how long?
Let me rephrase, Kylix is still stronger overall, and that will remain so
for a while. However depending on application and deployment requirements
FPC will be there.
It's not FPC against Kylix or Delphi against FPC. It is the delphi continuum,
keep libs general, and choose tools based on task.
Quote
As others have mentioned here, they have no desire to
support Delphi directly. I need to live in both worlds for
some time. I need a library that allows me to do that.
I am not the only one that needs that.
I need Delphi more than Kylix. I have no need for Kylix, except to get
Delphi things running that I can't get running with FPC for some reason.
(less often heard, but Kylix C++ support is sometimes something to be
desired, specially if you are on a schedule)
Quote
>make something platform independant based on something that is
>already pretty platform independant (like the LCL)

The LCL is OS independent, not development tool independent.
True. However I doubt you can be fully development tool independant.
Once could try to wrap LCL widgets like LCL wraps the GTK widgets, however
then starting from straight GTK might be more doable.
Also, one can't probably get more compatible to Kylix without getting into
the problems that makes Kylix apps so hard to deploy on an avg Unix distro.
The rich emulation has its advantages, but also puts much higher requirements
on the libs.
Quote
>The *nix version (*BSD and Mac OS X work too) is GTK1 based yes. Some work
>is done for GTK2, and if there is enough manpower, Aqua and QT could also be
>tackled.
>
Our efforts will focus on GTK 2 only. UNICODE support will
be a major development point.
Then LCL has nothing to offer, except maybe exchanging knowledge with people
doing similar things in LCL.
Quote
>QT doesn't have a real license problem on *nix. GPL makes an exception for
>libs deployed with the OS.
>
True, but is QT that much better then GTK? I don't know,
but maybe someone here can tell us all their impressions.
QT and KDE are better accepted in comapnies. However GTK apps are integrating
much better then they used to. The difference is fading.
Quote
>Chrome will never get enough userbase, at least not the next half decade,
>Delphi.NET will drop VCL.NET sooner or later.

True, but very few GUI stuff is done in Java. Server side
it is king currently. I don't have any clue or opinion on
which one will win the war there.
I think that VB.NET will reign the .NET clientside, and that the rest may lift a few
percents off its back.
Quote
>>next 5 years (at least).
>
>
>If you start something, it will be at least 1-2 years just to get settled
>and really start going. Typically one major iteration is needed to get the
>direction right and all noses in the right direction.

I think the LCL _is_ the first iteration.
See above. The LCL arch is slightly different.
Quote
If the goal of LCL was to be universal, I would join it. But in its
mandate, LCL is there to support Free Pascal and Lazarus, and I don't see
that changing.
Neither do I. Changing wouldn't make much sense. However that doesn't mean
that the unification is doable in finite time, before the last one turns of the
light in the Kylix camp.
Because when Kylix is dying, it will be harder and harder to get manpower. All people
want your product because it will breath a few more years of life into their aging apps,
but not help.
That is the problem of doing commercial product spinoffs. 99% of the users
are so spoiled, you can't get them to do much. The few cluefull are on a timetable,
and to them any large project costs more time than it yields.
I think there is much more to be gained to abandon the holy grail approach,
and focus on the codebases that can be easily shared, and let the last few
percents incompatible.
Quote
>I don't think it is doable to reach significant higher levels of compability
>by putting a layer over LCL on one side, and CLX on the other.

I am not trying to make it compatible with CLX. I am not
trying to make it compatible with LCL. The project is to
make the library load as a VCL in Delphi and load as an LCL
in Lazarus and maintain as much compatibility as possible
between the too. Just like CLX was suppose to do between
Delphi and Kylix.
CLX has the same interface on both. LCL a different one from CLX, but also
the same for both platforms. Their whole internal archs are shaped to implement that
interface.
However your one would have VCL on the win32 side, and LCL on the *nix side.
The compability on both sides would have to go pretty deep, or 3rd party
products wouldn't work. In my opinion that is not possible, at least not practically
in the finite time left.
Quote
>I think much more interoperability can be achieved more effectively by:
>1) improving Lazarus and FPC, directly.
>2) helping former delphi only projects to become more open to FPC/Lazarus.
>(and then I mean actually helping, not just mailing)
>3) doing header conversions, preferably working on both.
4) work on better dfm2lfn conversion and similar tools.
Quote
How does that help me with my current Delphi work?
It will allow you to reuse a larger part of the delphi code for lazarus, or
a future spinoff of CLX, continued crosskylix work etc, with near instant
return on invested time, instead of waiting for years for the toolkits
to develop and become usable and hoping for a perfect conversion.
Quote
How does that help the 100's of Delphi programmers that see Lazarus as a
real opportunity, but can't drop Delphi and need to work in Lazarus when
it makes sense, but mainly stay with Delphi until Lazaus in more mature?
It will decrease the gap for some of them, and the more able will be able to
cross. CrossKylix will also benefit from joint efforts on headers and
getting generic Delphi code Kylix runnable together with e.g. future versions
of CLX.
Even in ideal circumstances, I don't expect your project to top even only Lazarus
in the coming 2-3 years.
 

Re:ANN: Universal Object Pascal Library (UOPL)

Quote
>...or join the FreeCLX project, which also would be an alternative ;)

Nope, wrong license. LGPL is mandatory, and so is platform independance.
This is not true. The project will be dual-licensed LGPL and Borland-no-nonsense.
I know this information isn't on the website yet, but this decision has been long
done. I'm a commercial developer, I wouldn't invest my time into a project if
I'm not allowed to use the result afterwards ;)
Quote
>Sorry, but you are wrong. From www.trolltech.com/products/qt/licensing.html:

See www.trolltech.com/products/qt/opensource.html :

.. This is completely different from the Qt Commercial Editions which cannot be distributed at all.

Which is why made the point about Qt installed with the OS.

I don't distribute Qt. I just access it from the host OS.
"Based on the "Quid Pro Quo" principle, if you wish to derive a commercial advantage
by not releasing your application under an open source license, you must purchase
an appropriate number of commercial licenses from Trolltech. By purchasing commercial
licenses, you are no longer obliged to publish your source code.
If you wish to use a Qt Open Source Edition, you must contribute all your source code
to the open source community in accordance with the GPL or the QPL's license terms."
These are very clear and definitive license terms.
Quote
And GPL allows this. If Trolltech doesn't, afaik the above statement (open source version being under
GPL) is not valid.
Well, I guess that's up to them to decide ;)
I agree that linking to LGPL libs would be legal, but without a development license
you are not allowed to DEVELOP using QT.
Or in other words: Yes, it's of course possible to ignore their clear license times
and use Warez. But don't expect anyone joining you then.
Quote
>I wouldn't be to sure. If you ask people, why they stay with Delphi, you
>will again and again get "VCL" as a response. Borland isn't deaf, they must
>have noticed that.

I was at a D2005 launch, and Borland itself used pretty much always WinForms for
its demoes. VCL.NET is a migration technology.

However I do have some hopes a significant number of developers will remain on win32
for quite a while. A poll at the same launch showed that 4 (4!) of the +/- 120 people
present used D8 or .NET in general. And one of those 4 was dr Bob, who gave a presentation
for Borland.
Well, that's exactly what I said, isn't it? ;)
People want the VCL. That's why many of them stay with Borlands products.
This includes me, for the matter.
Quote
I see steady progress. If you don't, please use arguments.

>For me Free Pascal still is the same as it was 5 years ago - a few guys
>who find it cool to play with compiler technology, and who start doing
>tons of different things instead of finishing something.

FPC is getting there. It is a mammuth task to do parttime, and you should understand
that, being in the same kind of business yourself.
I'm not criticising FPC. It's a great project and all that. But when I look at
it from the "can I build my business applications on that?", the answer is a clear
and definitive no. It's a slowly progressing hobby project with limited resources.
Borland hasn't updated the Kylix compiler for years now, and FPC still is nowhere
near it.
Quote

FPC 1.9.x is a massive progression.

>If I recall correctly TThread was announced for FreePascal aproximately 4
>years ago now. As far as I can see, it's still not working.

TThread has been working since 1.9.2 afaik. Maybe you mean TMREWs, which is
indeed not implemented.
No. I got a similar answer 4 years ago. "There is some TThread implementation
somewhere, but we never really tested it". When I last checked a few months ago,
it was still completely non-working and crashing immediately. And if you search for
TThread at the mailing list archive, you'll still only find "is this supposed
to be working??" kind of messages. Also if you look at the effort to port
Indy to FreePascal, last time I checked it was suspended because the Thread-
stuff doesn't work.
I doubt after 4 years anything has changed during the last few weeks.
You simply don't need TThread for "Hello world", and that's why nobody cares.
Quote
FPC is pretty much getting close to modern Delphi on a base system level.
There are a lot skeletons in the cupboard (two major ones, packages and C++
linking), and several smaller ones (dispinterfaces, implements style
delegation, a lot of variant stuff barely tested and its RTL parts
incomplete)

On the other hand, we have 5 working architectures, and aspire to have them
roughly on the same level this year, or early next at the 2.0 release.
Yes, 5 "working" architectures. But not a single complete one. I see no
business case for "Hello world" on Amiga. It's a cool hack, but that's it.
Quote
>If development speed stays the same, FreePascal will take another few
>years to get on par with the current Kylix compiler.

Depends. I wouldn't be surprised if FPC didn't match Kylix or Delphi fully
even in ten years. But depending on your business and application kind, it
is already better than Kylix. Mainly with regards to application deployment,
platforms. nativeness etc.
Sorry, I don't see that. The only thing I could imagine beat FPC Kylix in would
be small, non-multithreaded CGI applications that don't do anything. But run
on lots of platforms including Amiga ;)
Quote
I'm strongly starting to suspect you haven't seen the 1.9.x series yet. Then you are
right. 1.0.x series is in freeze since december 1999, which nearly perfectly matches
your 5 years of nothingness.
The lasts tests I've done where about 3 months ago. As far as I can see from the website,
there has not been a new release since then. I didn't check the snapshots, though.
Quote
Neither do I, which is why I desperately need 64-bit memory support (I have a statstical
system that needs data in memory at work. I'm not 100% sure it will grow beyond the 3 GB border
yet, but it is getting closer and closer).

P.s. Doing advocacy for Cross-Kylix is fun and ok, but please remain reasonable.
Where am I doing advocacy for CrossKylix in this thread?
Point is:
- These are the Borland newsgroups, not the FPC ones.
- I don't believe FPC is anywhere near being a usefull replacement for Kylix.
- I'm expressing this opinion.
No CrossKylix in that ;)
Also, I would LOVE it if FPC would be a viable alternative. The reason I did CrossKylix
is not that some fantatic-borland-{*word*60} reason, I simply have a business running with
products written in Delphi/Kylix, and I needed a way to boost my productivity and keep
this as safe as it can get for the future. And if I would see a decent migration path
I sure would consider taking it.
I will give FPC another try and let you know my findings.
Simon
 

Re:ANN: Universal Object Pascal Library (UOPL)

Marco van de Voort wrote:
Quote
On 2004-11-08, Thomas Miller < XXXX@XXXXX.COM >wrote:

>>>us have a crystal ball.
>>
>>
>>I don't fully agree, though you are partially right. Kylix is stil
>>way stronger.
>
>Kylix is stronger, no doubt about it, but for how long?


Let me rephrase, Kylix is still stronger overall, and that will remain so
for a while. However depending on application and deployment requirements
FPC will be there.

It's not FPC against Kylix or Delphi against FPC. It is the delphi continuum,
keep libs general, and choose tools based on task.
You have hit the nail on the head: "keep libs general".
That is exactly the point of this project. LCL isn't bad,
but it doesn't support Delphi. You sound like you are very
involved with the project. If you can convince them to
include Delphi compatibility, then this new project would
not be needed. But so far I have gotten a cold shoulder
about the whole idea of including a Delphi build capability
of the LCL.
Quote


>As others have mentioned here, they have no desire to
>support Delphi directly. I need to live in both worlds for
>some time. I need a library that allows me to do that.
>I am not the only one that needs that.


I need Delphi more than Kylix. I have no need for Kylix, except to get
Delphi things running that I can't get running with FPC for some reason.
(less often heard, but Kylix C++ support is sometimes something to be
desired, specially if you are on a schedule)


>>make something platform independant based on something that is
>>already pretty platform independant (like the LCL)
>
>The LCL is OS independent, not development tool independent.


True. However I doubt you can be fully development tool independant.

Once could try to wrap LCL widgets like LCL wraps the GTK widgets, however
then starting from straight GTK might be more doable.
Which is the plan. We will use the LCL as a guide since
most of the work is already done there.
Quote

Also, one can't probably get more compatible to Kylix without getting into
the problems that makes Kylix apps so hard to deploy on an avg Unix distro.
Not worried about being compatible with Kylix at all.
Quote

The rich emulation has its advantages, but also puts much higher requirements
on the libs.


>>The *nix version (*BSD and Mac OS X work too) is GTK1 based yes. Some work
>>is done for GTK2, and if there is enough manpower, Aqua and QT could also be
>>tackled.
>>
>
>Our efforts will focus on GTK 2 only. UNICODE support will
>be a major development point.


Then LCL has nothing to offer, except maybe exchanging knowledge with people
doing similar things in LCL.
Exactly. This will be LCL 2 in some regards.
Quote


>>QT doesn't have a real license problem on *nix. GPL makes an exception for
>>libs deployed with the OS.
>>
>
>True, but is QT that much better then GTK? I don't know,
>but maybe someone here can tell us all their impressions.


QT and KDE are better accepted in comapnies. However GTK apps are integrating
much better then they used to. The difference is fading.


>>Chrome will never get enough userbase, at least not the next half decade,
>>Delphi.NET will drop VCL.NET sooner or later.
>
>True, but very few GUI stuff is done in Java. Server side
>it is king currently. I don't have any clue or opinion on
>which one will win the war there.


I think that VB.NET will reign the .NET clientside, and that the rest may lift a few
percents off its back.


>>>next 5 years (at least).
>>
>>
>>If you start something, it will be at least 1-2 years just to get settled
>>and really start going. Typically one major iteration is needed to get the
>>direction right and all noses in the right direction.
>
>I think the LCL _is_ the first iteration.


See above. The LCL arch is slightly different.


>If the goal of LCL was to be universal, I would join it. But in its
>mandate, LCL is there to support Free Pascal and Lazarus, and I don't see
>that changing.


Neither do I. Changing wouldn't make much sense. However that doesn't mean
that the unification is doable in finite time, before the last one turns of the
light in the Kylix camp.

Because when Kylix is dying, it will be harder and harder to get manpower. All people
want your product because it will breath a few more years of life into their aging apps,
but not help.

That is the problem of doing commercial product spinoffs. 99% of the users
are so spoiled, you can't get them to do much. The few cluefull are on a timetable,
and to them any large project costs more time than it yields.

I think there is much more to be gained to abandon the holy grail approach,
and focus on the codebases that can be easily shared, and let the last few
percents incompatible.

No argument here.
Quote

>>I don't think it is doable to reach significant higher levels of compability
>>by putting a layer over LCL on one side, and CLX on the other.
>
>I am not trying to make it compatible with CLX. I am not
>trying to make it compatible with LCL. The project is to
>make the library load as a VCL in Delphi and load as an LCL
>in Lazarus and maintain as much compatibility as possible
>between the too. Just like CLX was suppose to do between
>Delphi and Kylix.


CLX has the same interface on both. LCL a different one from CLX, but also
the same for both platforms. Their whole internal archs are shaped to implement that
interface.

However your one would have VCL on the win32 side, and LCL on the *nix side.

The compability on both sides would have to go pretty deep, or 3rd party
products wouldn't work. In my opinion that is not possible, at least not practically
in the finite time left.
You continue to assume that we are targeting Kylix. Not at
all. From following this newsgroup for the last 2 years,
there are people like yourself that don't think Kylix is
going any place but still use Delphi. What if there was a
library that allowed you to program in Delphi, open the
project in Lazarus and compile to Linux and Mac with less
then 1% if defs in your code? Would that be cool? Join our
list and help us figure out how to make this work. You
may even decide to help program a little :-)
Quote


>>I think much more interoperability can be achieved more effectively by:
>>1) improving Lazarus and FPC, directly.
>>2) helping former delphi only projects to become more open to FPC/Lazarus.
>>(and then I mean actually helping, not just mailing)
>>3) doing header conversions, preferably working on both.


4) work on better dfm2lfn conversion and similar tools.


>How does that help me with my current Delphi work?


It will allow you to reuse a larger part of the delphi code for lazarus, or
a future spinoff of CLX, continued crosskylix work etc, with near instant
return on invested time, instead of waiting for years for the toolkits
to develop and become usable and hoping for a perfect conversion.


>How does that help the 100's of Delphi programmers that see Lazarus as a
>real opportunity, but can't drop Delphi and need to work in Lazarus when
>it makes sense, but mainly stay with Delphi until Lazaus in more mature?


It will decrease the gap for some of them, and the more able will be able to
cross. CrossKylix will also benefit from joint efforts on headers and
getting generic Delphi code Kylix runnable together with e.g. future versions
of CLX.

Even in ideal circumstances, I don't expect your project to top even only Lazarus
in the coming 2-3 years.
We will see. I expect it will be much shorter then that.
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

Re:ANN: Universal Object Pascal Library (UOPL)

On 2004-11-08, Simon Kissel < XXXX@XXXXX.COM >wrote:
Quote
>>...or join the FreeCLX project, which also would be an alternative ;)
>
>Nope, wrong license. LGPL is mandatory, and so is platform independance.

This is not true. The project will be dual-licensed LGPL and Borland-no-nonsense.
I know this information isn't on the website yet, but this decision has been long
done.
I have no insight in that. However then I'm definitely interesting in porting it to FPC,
at least if it can be detangled from unit libc.
Quote
I'm a commercial developer, I wouldn't invest my time into a project if
I'm not allowed to use the result afterwards ;)
Good.
Quote
These are very clear and definitive license terms.
As said, the GPL allows using the open edition.
Quote
>And GPL allows this. If Trolltech doesn't, afaik the above statement (open source version being under
>GPL) is not valid.

Well, I guess that's up to them to decide ;)
Ultemately, it is up to the judge, and that is a long shot, since the GPL hasn't been
tested in court.
Quote
I agree that linking to LGPL libs would be legal, but without a development license
you are not allowed to DEVELOP using QT.
Ah, but if I use e.g. own reverse engineered headers, I do not develop using QT :-)
But it is murky waters, I agree.
However I don't want to talk down trolltech (or Borland with their Open
Edition). While I would not do major development based on a GPL source,
because of the commercial angle, such a GPL/commerical dual license allows
getting a fixes/patches project of the ground that can have a public codebase
and site.
I can still remember the trouble with TV that was never opened up.
Quote
>However I do have some hopes a significant number of developers will remain on win32
>for quite a while. A poll at the same launch showed that 4 (4!) of the +/- 120 people
>present used D8 or .NET in general. And one of those 4 was dr Bob, who gave a presentation
>for Borland.

Well, that's exactly what I said, isn't it? ;)
No. VCL and VCL.NET are quite different. I think VCL and WinForms will be
the winners, not VCL.NET.
Quote
>>tons of different things instead of finishing something.
>
>FPC is getting there. It is a mammuth task to do parttime, and you should understand
>that, being in the same kind of business yourself.

I'm not criticising FPC. It's a great project and all that. But when I look at
it from the "can I build my business applications on that?", the answer is a clear
and definitive no.
Well, that your opinion for your apps. FPC is used commercially, for large systems even
(I can remember an EU db appserver) _before_ Kylix was even released.
Quote
It's a slowly progressing hobby project with limited resources.
So is e.g. crosskylix, and all open source projects discussed here.
Quote
Borland hasn't updated the Kylix compiler for years now, and FPC still is
nowhere near it.
Nowhere near full substitution of Kylix with all the database, enterprise
and polished RAD attached. However to dismiss the entire project as hobbyism
is simply wrong.
Anyway, compilerwise, I'd say we are pretty close. The massive deployment
problems of Kylix apps alone are often enough.
We know for half a decade already that full substitability will be hard.
Quote
>>If I recall correctly TThread was announced for FreePascal aproximately 4
>>years ago now. As far as I can see, it's still not working.
>
>TThread has been working since 1.9.2 afaik. Maybe you mean TMREWs, which is
>indeed not implemented.

No. I got a similar answer 4 years ago. "There is some TThread implementation
somewhere, but we never really tested it". When I last checked a few months ago,
it was still completely non-working and crashing immediately.
Afaik it is working now +/- a year with some bugs removed and restructurings
in spring.
Quote
And if you search for TThread at the mailing list archive, you'll still
only find "is this supposed to be working??" kind of messages. Also if you
look at the effort to port Indy to FreePascal, last time I checked it was
suspended because the Thread- stuff doesn't work.
I don't have any experience with Indy. Indy10 had no docs when I last looked
at it, and Indy9 is only usable (on D6) after the threading fixes last
spring (make sure you have a snapshot of after April)
ICS/win32 works fine though. With threads.
Quote
I doubt after 4 years anything has changed during the last few weeks.
I don't know what you're testing, and if your testing code is correct. I'm not
aware of problems.
Quote
You simply don't need TThread for "Hello world", and that's why nobody cares.
Don't be silly. FPC is a decade beyond hello world. That you can't recompile your
apps without mods doesn't automatically make it hello world levle.
Quote
>incomplete)
>
>On the other hand, we have 5 working architectures, and aspire to have them
>roughly on the same level this year, or early next at the 2.0 release.

Yes, 5 "working" architectures. But not a single complete one.
Define complete. Complete for what? Nothing is complete. I might as well say that
Delphi is not complete, and you wouldn't be able to prove me wrong.
Quote
I see no business case for "Hello world" on Amiga. It's a cool hack, but
that's it.
Amiga is not one of them. (m68k is not added to 2.0). AMD64, Sparc64,
PowerPC and Arm.
I can't comment on your business cases, since I don't know your business. However it
sounds you are in some inflexible business environment.
Quote
>is already better than Kylix. Mainly with regards to application deployment,
>platforms. nativeness etc.

Sorry, I don't see that. The only thing I could imagine beat FPC Kylix in would
be small, non-multithreaded CGI applications that don't do anything. But run
on lots of platforms including Amiga ;)
See lazarus. How small is that app?
Quote
>I'm strongly starting to suspect you haven't seen the 1.9.x series yet. Then you are
>right. 1.0.x series is in freeze since december 1999, which nearly perfectly matches
>your 5 years of nothingness.

The lasts tests I've done where about 3 months ago. As far as I can see from the website,
there has not been a new release since then. I didn't check the snapshots, though.
Not spectacular since. the same progression as between 1.9.2 and 1.9.4 will probably
continue to 1.9.6.
Quote
>yet, but it is getting closer and closer).
>
>P.s. Doing advocacy for Cross-Kylix is fun and ok, but please remain reasonable.

Where am I doing advocacy for CrossKylix in this thread?

Point is:

- These are the Borland newsgroups, not the FPC ones.
The thread was not a FPC one. You made it one, not me. I was talking about setting
up generic codebases.
Quote
- I don't believe FPC is anywhere near being a usefull replacement for Kylix.
Well, there's religious freedom in most countries.
Quote
- I'm expressing this opinion.
Fine. But please don't try to express it as general facts then, and say "my business case".
Quote
Also, I would LOVE it if FPC would be a viable alternative.
... if FPC was a vaiable alternative for me...
Quote
The reason I did CrossKylix is not that some fantatic-borland-{*word*60}
reason,
I don't bear a grudge against Borland. I consider FPC to be a project in the Borland
continuum, pretty much like Delphi, a future FreeCLX etc.
That's also why I keep hammering on selecting a case by case basis, and keep
asking for real arguments, and a decent case, not vague mutterings about
business cases, and rambling on about "hello world" on Amiga.
The thread situation is indeed one. As said, it is certainly not complete.
TMRSW is missing, and probably for certain codepieces won't work (I don't
know one atm, but it could be for other platforms than I'm using. FreeBSD
uses a different pthreads implementation, as said ICS/win32 works )
However to dismiss the entire system ( a 100MB+ codebase) as a "hello world"
program is plain silly.
Quote
I simply have a business running with products written in
Delphi/Kylix, and I needed a way to boost my productivity and keep this as
safe as it can get for the future. And if I would see a decent migration
path I sure would consider taking it.
Don't. If you really set out for a migration path, you will remain stuck
with the safest choice. That is using delphi and{*word*222}all other platforms, till
you really can't anymore.
I did the same thing with BP/Topspeed the compilers I was using then. It won't work, you
have to take some risks.
The smart way is to simply add FPC to the Delphi/Kylix combo. Keep up to
date on these fronts, and make sure you don't crank out new code that has
avoidable incompabilities, and keep existing generic codebases compilable.
That way, when you have a choice (on per project basis) with FPC, you will
have a fair choice, otherwise the overhead involved with crossing over will
_always_ hold you back.
Quote
I will give FPC another try and let you know my findings.
Depending on you time, you could. You can submit bugs and problems on the
website or on mail to me, but preferably with compilable code to reproduce.
 

Re:ANN: Universal Object Pascal Library (UOPL)

On 2004-11-09, Thomas Miller < XXXX@XXXXX.COM >wrote:
(some short points, I already overstepped my time with Simon's reply)
Quote
>Let me rephrase, Kylix is still stronger overall, and that will remain so
>for a while. However depending on application and deployment requirements
>FPC will be there.
>
>It's not FPC against Kylix or Delphi against FPC. It is the delphi continuum,
>keep libs general, and choose tools based on task.

You have hit the nail on the head: "keep libs general".
That is exactly the point of this project. LCL isn't bad,
but it doesn't support Delphi.
It would be hard to support two designtime systems. Runtime is less of a
problem.
Quote
You sound like you are very involved with the project.
I'm FPC devel, mostly busy with Unix rtl.
Quote
If you can convince them to include Delphi compatibility, then this new
project would not be needed. But so far I have gotten a cold shoulder
about the whole idea of including a Delphi build capability of the LCL.
There is a couple of problems:
- designtime support will be hard.
- Delphi has bugs (e.g. compiling FPC with Delphi 6/7 doesn't create a working version)
- FPC has extensions. (inline, operator overloading). D2005 has some of these though.
For more reasons from the Lazarus teams, see the answer on Andreas msgs :
www.lazarus.freepascal.org/list_archives/lazarus/08-17-02_01-02-04/msg04927.html
I also (or actually one of the Lazarus devels) dug into the threading
problems Simon mentioned, and something has dawned on me. Synchronize() is
not implemented, and I probably never noticed since I always used critical
sections to guard subsystems and data. Apparantly ICS doesn't either, or at
least for the components I tested, but ICS does indeed do a lot of stuff in
its own way, since ICS is still compatible with _all_ delphi version
including D1. I used ICS mostly console anyway.
Note that rejections are always at the time, nothing is ever definite ( I
can remember heated debates about implementing delphi compat 8 years ago,
and see what we are discussing now :-)
Quote
>Also, one can't probably get more compatible to Kylix without getting into
>the problems that makes Kylix apps so hard to deploy on an avg Unix distro.

Not worried about being compatible with Kylix at all.
Pure compilation (use LCL as core library under Delphi, without visual part
of the VCL (read forms and deeper)) should be doable. Specially with D2005,
since some things might be better in it.
Quote
You continue to assume that we are targeting Kylix. Not at
all. From following this newsgroup for the last 2 years,
there are people like yourself that don't think Kylix is
going any place but still use Delphi.
IMHO Kylix was too much a Delphi recompilation tool. A lot of the fragility with respect
to library requirements comes from it.
Quote
What if there was a
library that allowed you to program in Delphi, open the
project in Lazarus and compile to Linux and Mac with less
then 1% if defs in your code? Would that be cool?
I prefer a designtime lazarus to using Delphi as mere editor. While I only use it
for small sysadmin like progs, I do use lazarus already.
I'm a more likely candidate to focus on Indy porting. Also because I use
Indy on the Delphi side (historically due to its early SSL support)