Board index » kylix » 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
 

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.
 

Ray Mond wrote:
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}

Let's start with the last paragraph:
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.
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.
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.
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).
the annoucement?
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).
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
 

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
 

Michael Schnell wrote:
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)
 

Andreas Hausladen schrieb:
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.
compiler), but at least it's open source and there are people behind it
that care (somehow)..
you out and do a D6 version myself.. But only, if there is a solution to
the QT license 'problem'..
development. Otherwise I'll probably have a look at the LCL..
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..
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..
Willi
 

On 2004-09-15, Willibald Krenn < XXXX@XXXXX.COM >wrote:
 

Andreas Hausladen wrote:
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)?
Micha
 

Micha Nelissen wrote:
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.
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)
 

Andreas Hausladen wrote:
de{*word*81} itself, or some thirdparty tool?
Micha
 

Micha Nelissen wrote:
source code. And setting a breakpoint at some position and watching local
and global variables helps a lot in surrounding the bug.
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)
 

Micha Nelissen wrote:
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)
 

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
 

(would be a good idea, anyway)
-Michael