Board index » kylix » Kylix Community Project - thoughts

Kylix Community Project - thoughts


2004-09-15 09:18:10 AM
kylix2
Hi!
Just a few thoughts on the FreeCLX project.
Probably nobody here will know that I've taken Andreas' patches and made
a (more or less) Delphi 6 Interface compatible version. It's not
perfectly 100% compatible, but I've recompiled the runtime packages and
my D6 IDE now runs with the patched CLX under the hood.
I've done this, because I need the cross platform feature of Borland's
CLX framework (including full package support).
Now, given that Andreas already speaks of doing a complete interface
change or/and update the CLX to make use of QT x.y, I fear that I won't
be able to use any of the work the Kylix Community Project will do.
(Neither will I be able to contribute.)
Generally my concerns can be summed up as follows:
->I really doubt that the community respects the cross-platform
approach (D6, D7, K1, K2, K3, ... )
->The community doesn't have the financial backing to buy a
Kylix/Delphi QT x.y devel license - with the result, that every program
based on the 'FreeCLX' with updated QT binding would have to be GPLed.
(Which is an absolute No-No)
->Lack of QA (For my tasting even now some of Andreas' patches are
too far away from original source and a likely source of errors)
->The CLX community is rather small and I fear I've not seen any
contribution done by the other project admins
->Borland has now officially 'killed' CLX as officially supported
platform.
->Who stears the whole project? Who is responsible for getting
releases out the door? (And how often?) Do 'we' have a homepage? (Or is
this some unimportant sub-project to Indy?)
->What's the process of contributing a change to the codebase and how
will the QA handle it? (Test-tools for QA? Bug database?)
IOW: Who decides what goes in, how will the change be tested and how to
apply for a change?
->Will Borland include the project outcome in e.g. D9?
->In which way will Borland support the whole idea? (QT License?)
Plus: It doesn't solve the issue of 'buggy Kylix IDE' and we won't get
any compiler updates.
So - in fact - this is bad news.
In my humble opinion - if Borland is asking for help of the community -
'we' should take Lazarus, implement an option to call the Borland
compiler, add the missing controls to the LCL and write an import wizard
for Kylix/Delphi projects. Perhaps it would even be possible to rework
the LCL in parts so that it would be possible to use it with Borland's
Delphi Win32 compiler/IDE product line.
This way the community would win most: A free Pascal compiler (with
source) plus IDE on the Linux side and still the option to load/compile
applications with normal Borland Delphi/Kylix compilers. Plus: The
community would be totally independant from Borland.
Of course the freepascal guys also have a Windows32 version of Lazarus..
Willi
 
 

Re:Kylix Community Project - thoughts

Quote
Of course the freepascal guys also have a Windows32 version of Lazarus..
Would rock if the 32-bit IDE could generate 64-bit code from FreePascal.
That would be even one-up on Delphi as 64-bit does not seem to be
forthcoming (well, they did mention conversion of VCL.Net to support 64-bit
is ongoing, so just maybe, those changes may flow down to VCL.Win32/64).
--
Regards
Ray Mond
P.S. Hi Willibald. Great to see you here since the days of the DWSII
documentation project.
 

Re:Kylix Community Project - thoughts

Ray Mond wrote:
Quote
>Of course the freepascal guys also have a Windows32 version of Lazarus..


Would rock if the 32-bit IDE could generate 64-bit code from FreePascal.
That would be even one-up on Delphi as 64-bit does not seem to be
forthcoming (well, they did mention conversion of VCL.Net to support 64-bit
is ongoing, so just maybe, those changes may flow down to VCL.Win32/64).

Borland quite obviously is focuss ed on .NET framework as a target for
compilation (rather than Windows/Linux/MAX/32Bit/64...). I suppose this
is a good idea on the long run. Unfortunately they are not too active in
taking other frameworks but the (partly propriety) Microsoft one into
consideration. Nagging them into guaranteeing MONO compatibility would
be a good thing.
-Michael
 

{smallsort}

Re:Kylix Community Project - thoughts

Let's start with the last paragraph:
Quote
Perhaps it would even be possible to rework
the LCL in parts so that it would be possible to use it with Borland's
Delphi Win32 compiler/IDE product line.
I have a working LCL for Delphi. It is now oudated but it can be compiled
with Delphi. The only problem I have with this is that after offering the
changes to the Lazarus development team, they refused and discared all my
changes. "Why should we remove operator overloading to support Delphi
compilers?" and such comments from them brought me to "discard" the
Lazarus project. On the one hand they want Delphi developers but on the
other had they do not want them, at least the dcc32.exe. But fpc is no
alternative for me at the moment. The Qt3forKylix/Delphi does not work
with it because of some compiler bugs. For my proove of concept I had to
disable many Qt class methods. The newest fpc compiler (CVS) seems to have
fixed this bug, but still no alternative to dcc32.
Quote
Probably nobody here will know that I've taken Andreas' patches and made
a (more or less) Delphi 6 Interface compatible version.
I know it :-)
Quote
Now, given that Andreas already speaks of doing a complete interface
change or/and update the CLX to make use of QT x.y, I fear that I won't
be able to use any of the work the Kylix Community Project will do.
(Neither will I be able to contribute.)
The update to Qt 3 would only hurt the QComCtrls interface (and I'm not
sure if this is really necessary as I'm currently only working on QTypes
and QGraphics) because some controls are replaced by others under Qt 3.
Event the TFont.CharSet is obsolute had will have no functionality under
Qt 3.
Quote
->I really doubt that the community respects the cross-platform
approach (D6, D7, K1, K2, K3, ... )
It is K3 only. (and maybe (I hope) D7). For Delphi 6 I'll try to do
backporting the patches as far as possible. In that case I could discard
the inferface incompatible version and use your version.
Ad the DB component are not part of the FreeCLX I will still release
patches for them on my homepage.
Quote
->The community doesn't have the financial backing to buy a
Kylix/Delphi QT x.y devel license - with the result, that every program
based on the 'FreeCLX' with updated QT binding would have to be GPLed.
(Which is an absolute No-No)
That is something the admin team has to talk about.
Quote
->Lack of QA (For my tasting even now some of Andreas' patches are
too far away from original source and a likely source of errors)
It's not easy to write patches and do QA with only one person. All my
patches that would go into the FreeCLX Community Project will be reviewed
and tested. First all non-critical patches will be applied (means z-order
and OnActivation/OnDeactivation are the last applied patches, if ever).
And some patches meight disappear due to the Qt 3 port (I hope the z-order
problem is solved by Qt 3).
Quote
->Borland has now officially 'killed' CLX as officially supported
platform.
Where have you found this? Or is it just a conclusion you've taken from
the annoucement?
Quote
Do 'we' have a homepage?
freeclx.sourceforge.net
Quote
->Who stears the whole project?
Borland and the admin team.
Quote
Who is responsible for getting releases out the door?
The admin team.
Quote
And how often?
The first release meight be in spring 2005. We have lot's of work to do.
Apply and test my patches, port to Qt 3 which meight results in some
internal changes. (But at least my QDialogs.MessageDlg hack will go away
because it is fixed in Qt 3).
Quote
->What's the process of contributing a change to the codebase and how
will the QA handle it? (Test-tools for QA? Bug database?)
IOW: Who decides what goes in, how will the change be tested and how to
apply for a change?
These are all things that have to be discussed.
Quote
->Will Borland include the project outcome in e.g. D9?
Not in D9 (DiamondBack).
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
 

Re:Kylix Community Project - thoughts

Andreas.
This does sound promising.
Under what conditions would you recommend starting a new project using
Kylix right now ?
Can we work on and compile for an up-to-date Linux distribution (e.g.
the latest Suse enhanced by the latest version of Linux 2.6? )
-Michael
 

Re:Kylix Community Project - thoughts

Michael Schnell wrote:
Quote
Can we work on and compile for an up-to-date Linux distribution (e.g.
the latest Suse enhanced by the latest version of Linux 2.6? )
I will setup a SuSE 9.1 with kernel 2.6.8.1. But the IDE and the Compiler
are Borland's part. If they decide not to work on them then it is their
bear. At the moment the Delphi command line compiler works for me unter
SuSE 9.0 with kernel 2.6.8.1.
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
 

Re:Kylix Community Project - thoughts

Andreas Hausladen schrieb:
Quote
I have a working LCL for Delphi. It is now oudated but it can be compiled
with Delphi. The only problem I have with this is that after offering the
changes to the Lazarus development team, they refused and discared all my
changes. "Why should we remove operator overloading to support Delphi
compilers?" and such comments from them brought me to "discard" the
Lazarus project.
Which is a real shame! Unfortunately the Pascal community (especially on
Linux) is not that big and establishing _one_ framework would help us
all.. Additionally the LCL framework doesn't have the QT license issues.
But if you (and the admin team) can convince Borland of giving 'us'
an updated qtintf (for Windows and Linux), this point is not relevant
anymore.
Quote
But fpc is no
alternative for me at the moment. The Qt3forKylix/Delphi does not work
with it because of some compiler bugs.
True, the fpc compiler still lacks features (compared to the Kylix
compiler), but at least it's open source and there are people behind it
that care (somehow)..
Quote
I know it :-)
Yea, you're probably the only one :-)
Quote
It is K3 only. (and maybe (I hope) D7). For Delphi 6 I'll try to do
backporting the patches as far as possible. In that case I could discard
the inferface incompatible version and use your version.
As it seems that I'm the only one using D6 and CLX I would probably help
you out and do a D6 version myself.. But only, if there is a solution to
the QT license 'problem'..
Quote
>->The community doesn't have the financial backing to buy a
>Kylix/Delphi QT x.y devel license - with the result, that every program
>based on the 'FreeCLX' with updated QT binding would have to be GPLed.
>(Which is an absolute No-No)


That is something the admin team has to talk about.

I really hope you come up with a solution that allows us to do non GPL
development. Otherwise I'll probably have a look at the LCL..
Quote
>->Lack of QA (For my tasting even now some of Andreas' patches are
>too far away from original source and a likely source of errors)


It's not easy to write patches and do QA with only one person.
Of course.. Which means that the project could need some QA persons ;-)
BTW: The ultimate way for QA would be to write a new Kylix IDE with the
new framework :-) But again: Why re-invent the wheel when there already
is such a project in work..
Quote
>->Borland has now officially 'killed' CLX as officially supported
>platform.


Where have you found this? Or is it just a conclusion you've taken from
the annoucement?
Well, mostly it's a conclusion I've drawn from the announcement; Of
course my impression can be wrong, but as the community now is
responsible for CLX development, Borland has no need to do anything in
that area.. Additionally Borland already has to support two frameworks
(VCL and VCL.NET as I understand) and Kylix won't be updated in next year..
Quote
The first release meight be in spring 2005. We have lot's of work to do.
Apply and test my patches, port to Qt 3 which meight results in some
internal changes. (But at least my QDialogs.MessageDlg hack will go away
because it is fixed in Qt 3).
Sounds promising!
Quote
>IOW: Who decides what goes in, how will the change be tested and how to
>apply for a change?

These are all things that have to be discussed.
I hope you'll communicate the found solution back here?
Quote

>->Will Borland include the project outcome in e.g. D9?


Not in D9 (DiamondBack).
But chances are good for e.g. D10?
Willi
 

Re:Kylix Community Project - thoughts

On 2004-09-15, Willibald Krenn < XXXX@XXXXX.COM >wrote:
Quote
applications with normal Borland Delphi/Kylix compilers. Plus: The
community would be totally independant from Borland.
Of course the freepascal guys also have a Windows32 version of Lazarus..
And a Mac OS X, Linux/PPC one :_)
 

Re:Kylix Community Project - thoughts

Andreas Hausladen wrote:
Quote
>Perhaps it would even be possible to rework
>the LCL in parts so that it would be possible to use it with Borland's
>Delphi Win32 compiler/IDE product line.

I have a working LCL for Delphi. It is now oudated but it can be compiled
with Delphi. The only problem I have with this is that after offering the
changes to the Lazarus development team, they refused and discared all my
changes. "Why should we remove operator overloading to support Delphi
compilers?" and such comments from them brought me to "discard" the
Lazarus project. On the one hand they want Delphi developers but on the
other had they do not want them, at least the dcc32.exe.
Note that there is a difference between compiling the LCL with delphi,
or projects *using* the LCL with both fpc and dcc32. People will want to
use the VCL on delphi/win32, I guess...why use the LCL on delphi, while
the VCL is more featurecomplete (and less buggy)?
Quote
But fpc is no
alternative for me at the moment. The Qt3forKylix/Delphi does not work
with it because of some compiler bugs. For my proove of concept I had to
disable many Qt class methods. The newest fpc compiler (CVS) seems to have
fixed this bug, but still no alternative to dcc32.
Can you explain why it still is no alternative?
Micha
 

Re:Kylix Community Project - thoughts

Micha Nelissen wrote:
Quote
Note that there is a difference between compiling the LCL with delphi,
or projects using the LCL with both fpc and dcc32. People will want to
use the VCL on delphi/win32, I guess...why use the LCL on delphi, while
the VCL is more featurecomplete (and less buggy)?
What about debugging the LCL with Borlands de{*word*81}? Why do you think have
I found many bugs in the LCL after some hours and posted bug fixes? Doing
this with Lazarus and fpc would have been a pain.
Quote
Can you explain why it still is no alternative?
When you can compile the JVCL then I could play with the thought using fpc
under Linux (I need only IA32, and maybe in the furture IA64) but the
Delphi compiler works under Linux, too.
BTW: Have you seen this screen shot:
andy.jgknet.de/oss/qt/qt3forFPC/
It was a pain to get it working with fpc. I had to deactivate everything
fpc (CVS snapshot) could not handle.
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
 

Re:Kylix Community Project - thoughts

Andreas Hausladen wrote:
Quote
Micha Nelissen wrote:


>Note that there is a difference between compiling the LCL with delphi,
>or projects using the LCL with both fpc and dcc32. People will want to
>use the VCL on delphi/win32, I guess...why use the LCL on delphi, while
>the VCL is more featurecomplete (and less buggy)?


What about debugging the LCL with Borlands de{*word*81}? Why do you think have
I found many bugs in the LCL after some hours and posted bug fixes? Doing
this with Lazarus and fpc would have been a pain.
Ah, I never knew how you found those bugs. You did it with the delphi
de{*word*81} itself, or some thirdparty tool?
Quote
>Can you explain why it still is no alternative?

When you can compile the JVCL then I could play with the thought using fpc
under Linux (I need only IA32, and maybe in the furture IA64) but the
Delphi compiler works under Linux, too.
Most of the JCL can already be compiled...
Quote
BTW: Have you seen this screen shot:
andy.jgknet.de/oss/qt/qt3forFPC/
It was a pain to get it working with fpc. I had to deactivate everything
fpc (CVS snapshot) could not handle.
Can you report bugs you found, on www.freepascal.org ?
Micha
 

Re:Kylix Community Project - thoughts

Micha Nelissen wrote:
Quote
Ah, I never knew how you found those bugs. You did it with the delphi
de{*word*81} itself, or some thirdparty tool?
The thirdparty tool were my two eyes. I see bugs very fast when I look at
source code. And setting a breakpoint at some position and watching local
and global variables helps a lot in surrounding the bug.
Quote
Most of the JCL can already be compiled...
The JCL is not the JVCL. It is a first step but the JVCL depends to much
on the VCL/CLX and not at least on the dcc32 generated code.
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
 

Re:Kylix Community Project - thoughts

Micha Nelissen wrote:
Quote
Can you report bugs you found, on www.freepascal.org ?
All bugs I found are already reported.
The most critical bug was/is that if you have a two method with the same
name (overload) and the first one is a dll import function in the
implementation section followed by an implemented method the fpc generates
assembler symbols which do not exist. Buit I heavily use this in
Qt3forKylix.
-------------------------------------------------------
TTest = class(TObject)
public
procedure Test(x: QStringH); cdecl;
procedure Test(const x: WideString); cdecl;
end;
implementation
procedure TTest.Test(x: QStringH); external QtLib name 'TTest_Test';
procedure TTest.Test(const x: WideString);
begin
Test(qs(x).get);
end;
-------------------------------------------------------
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
 

Re:Kylix Community Project - thoughts

Quote
>Of course the freepascal guys also have a Windows32 version of Lazarus..

And a Mac OS X, Linux/PPC one :_)
And of course a Mono version is in the works, right ;-)
Willi
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (www.grisoft.com).
Version: 6.0.760 / Virus Database: 509 - Release Date: 10.09.2004
 

Re:Kylix Community Project - thoughts

Quote
>>Of course the freepascal guys also have a Windows32 version of Lazarus..
>
>And a Mac OS X, Linux/PPC one :_)


And of course a Mono version is in the works, right ;-)

Is this truth, rumor or joke ?
(would be a good idea, anyway)
-Michael