Board index » kylix » Re: Kylix now officialy dead?

2004-11-08 06:26:29 PM
kylix1
Arthur Hoornweg wrote:
1) Kylix and Delphi 7 still work. Delphi 2005 is not changing this.
2) There is the FreeCLX initiative, which may (and I hope does) lead to
CLX becoming available for Delphi 2005 too.
3) CrossKylix will be on the companion CD of Delphi 2005, suporting
Delphi 2005.
4) We do not know what will happen on the Kylix side. Borland has been
much to busy with the Windows side during this year and the year before
to do much on Kylix. I guess that this will be similar next year with
.Net 2.0 on the horizon. Nevertheless Borland has been changing the
strategy somewhat on Kylix (e.g. with FreeCLX), which is showing that
Borland is seeking for a way how to continue Kylix.
Jan
 

A sad day. Delphi 2005 will have no more CLX support or
so I've heard.
So any future Kylix version will no more have the "platform
independence" feature because you can't recompile a Kylix
source under Delphi or vice versa.
So guys, it looks like Kylix is dead...
--
Arthur Hoornweg
(please remove the ".net" from my e-mail address.
I had to take this measure to counteract SPAM
flooding my mail box)
 

Simon Kissel wrote:
Borland went through the hazzle to create CLX for Windows and did not
do this from the beginning. I think that's one of the reasons, why
Kylix did not take off.
How difficult will it really be to convert CLX on Linux to better match
the VCL? AFAIK they are already pretty similar. The most prominent
issue will be to get rid of the strange Q in all the Unit names...
conversion of CLX.
BTW: I am really impressed with CrossKylix. It has really restarted my
interest in Kylix. Thanks a lot for doing this!
Jan
 

{smallsort}

This doesn't mean Kylix is dead.
What's dead is the CLX on Windows, and rightfully so. Nobody really
wanted to do CLX on Windows and to have to ship QT libs with the
application anyway. What most people probably want is native Win32
(VCL) for Windows, and VCL/CLX for Linux. The key to getting there is
actually pretty simple:
Make the Linux CLX more compatible to the Windows VCL, and then use
the Windows VCL designer to design your forms. These then can be
compiled to Linux.
This at least is what I'd like to see, and Borlands decision to drop
the CLX for Windows by no means is a road-block for that.
Simon
 

Simon Kissel wrote:
actively working on that, it's not a good sign. I sincerely
doubt there will ever be another Borland Kylix update.
--
Arthur Hoornweg
(please remove the ".net" from my e-mail address.
I had to take this measure to counteract SPAM
flooding my mail box)
 

with it.
The question also is what you personally think Kylix is.
My impression on the various aspects is the following:
1.) The CLX.
The CLX more or less is just a renamed VCL clone. The Windows part of it doesn't
have any future. Nobody likes the drawback of working non-native under Windows.
The Linux part of it actively maintained by the FreeCLX project now. For Linux it
will stay and get updated. In the future, the CLX hopefully will become so compatible
to the VCL that visually you can't spot a difference for the components. This will
allow you to use the VCL Form Designer, which is actively maintained by Borland.
2.) The Kylix IDE
As you may know, Delphi 2000 uses the Galileo IDE, which is a complete rewrite. The
Kylix IDE is based on the old Delphi 6/7 IDE. That makes the current Kylix IDE a
pretty much dead-end. I don't expect a new Kylix IDE for the near future. If Borland
again sees a market for a Linux IDE, they might one day do another attempt. I
personally don't expect a new Kylix IDE for the near future.
3.) The compiler
The Kylix compiler works like a charm. Also it should be easily updateable to the
current state of the Win32 compiler. It would be a rather small investment for Borland
to get their customers an updated Kylix compiler.
4.) Cross-Platform development Windows/Linux
In my personal, very biased opinion, "Kylix" has a bright future here. All that's needed
to make Delphi a perfect cross-platform RAD solution is:
a) A crosscompiler integrated into the Delphi IDE. The Delphi 2005 IDE is perfectly
extendable in this area due to its "personality" support. And as a temporary solution,
we currently have CrossKylix.
b) A cross-platform GUI framework. VCL on Windows + "CLX" for Linux will provide this.
That's the way quite a few people have used Delphi/Kylix from the start anyway, using
some IFDEFs.
c) A remote de{*word*81}.
Summary:
If you are a Linux developer, who wants to develop only under Linux and for Linux, forget
about Kylix. Most "real Linux geeks" don't want RAD, but {*word*155} low-level c. Near all
of them don't want to work with closed-source software, and even less want to pay money
for software. That's the reality Borland has faced when trying to sell Kylix.
If you are a Windows developer who also wants to deploy some of this applications to Linux,
then you can safely stay with Kylix. Right now writing all kind of web services, server-,
database and middleware applications works like a charme without any real issues, and
you can enjoy the full RAD power of Delphi. And if you are more into GUI client
applications, you currently have to work around some compatibility issues and bugs, but
it works, and chances are good it will get much better soon.
I personally think that 99% of all people that paid for Kylix are Users coming from the
Delphi Windows world. From a business standpoint it would totally make sense to keep
these customers.
Personally I would not miss the Kylix IDE at all. I never used it. I always created
my Applications under Windows and then compiled them on Linux. I have the feeling I'm
not alone. The number of CrossKylix users points into the same direction.
My personal hope is that Borland will integrate everything needed to build Linux
applications into the Delphi IDE.
Simon
 

thought they couldn't get CLX compatible enough to the VCL, and that
it would be better to offer a solution that's 1:1 the same for Windows
and Linux.
to solve. But all in all, the current CLX is a pretty good base to get
VCL to Linux. Of course there are a few problems, also concept-wise. One
is how to mark if a VCL component in the tool palette/forms designer if it
will compile for Win32 only or for both Linux and Win32. This probably was
the reason for the Q-stuff - it makes you know if a component is cross-
platform or not.
see how many people are using CrossKylix. Compared to the low activity
in this newsgroup, it's an quite impressive number.
Simon
 

Simon Kissel wrote:
There are incompatibilities, but as long as the dfm files are
compatible, the rest could be sorted out during a compile run.
incorporate. If there is no CLX on Windows (and no VCL on Linux) there
is no need to separate this.
increase. If then all those compiler enhancements of Delphi 2005 are in
the Kylix compiler that could become the "dream-team" Kylix never was.
Jan
 

"Simon Kissel" wrote
Almost decade ago, I stooped using vi and other nonsense
on UNIX machines and did all code writing on windows, ftp-ing
it to UNIX and compiling it there. For most part, it was plain
ANSI C, perfectly compilable with BCC.
I started same way with FPC and Kylix, until you
pointed me to CrossKylix version 0.5.
I still can't understand how Borland
got it so wrong in a first place.
 

R.F. Pels wrote:
worth considering. Just by spitting out accuses without any facts you
are actually attacking somebody who provides help and value!
Do you have a purpose behind this, or are you just having a bad day?
 

Simon Kissel wrote:
bandwagon with a half-baked product in the first place. Pricing for any
serious IDE simply isn't and wasn't an option for most of the Linux
developers.
--
Ruurd
 

Which seams to be rather small. Actually you are the first one that group
to speak up ;)
then there are some written using some other texteditor + some other compiler.
The whole gnu collection is written in c. It can't get any less RAD than this,
can it (Assembler aside)? Compared to this the number of Eclipse- and KDevelop-
Users seems to be rather tiny.
Feel free to google for all glibc and kernel bug reports coming from Borland
while developing Kylix. You'll see what kind of support they got from the
Linux community. Mostly "we don't care about a commercial vendor" kind of
reponses. Now have a look how well other vendors of closed source application
or objects are doing. They all suffer from the same fate: The Linux community
expects that everyone will rebuild all their applications for every release
of glibc and the various libraries. Look 7 threads above to see how an
obviously untested glibc2.3.4 release in gentoo recently caused ALL closed-
software out there break.
Looking at all that gives me the feeling that getting Kylix to the point
it now is was a major task, and quite successfull.
And hey, now have a look at all the reported problems with Kylix since its
release. With only a hand full of exceptions, those problems are caused by
bugs inside glibc, the kernel, pthread and qt. It's not Borland faults when
under Linux commonly buggy library versions are released, and interfaces
are broken all the time.
doesn't it? ;)
Simon
 

"Hrvoje Brozovic" < XXXX@XXXXX.COM >wrote in
 

Jan Mitrovics wrote:
--
Ruurd
 

Simon Kissel wrote:
originating in the Linux camp that eventually are ported to Win32. Same
old.
better integrated into the building system that is used most of the time.
developer to buy. And no, Kylix is not it. In fact, Kylix has been a huge
mistake to begin with. Tied way to close to Qt2, Wine and ONE particular
glibc version.
easy on a non-supported platform? Exactly. They let you link their stuff
into an executable. And they will not tie you to versions of libraries of
which they know that they will be out-of-date quite fast.
Qt major version.
same old, and not an argument.
if you can't understand that, please get some professional help with your
CRI.
--
Ruurd