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

Re: Kylix now officialy dead?


2004-11-09 02:53:12 AM
kylix2
R.F. Pels wrote:
Quote
Pot. Kettle. Black.
Thank you very much for your profound answer. You seem to be in Monday
depression. Is your job that bad?
 
 

Re:Re: Kylix now officialy dead?

R.F. Pels schrieb:
Quote
>Do you have a purpose behind this, or are you just having a bad day?


Pot. Kettle. Black.
Are the coffee shops closed today?
"Why don't you knock it off with them Negative Waves! Why don't dig how
beautiful it is out here. Why can't you say something righteous and
hopeful for a change"
 

Re:Re: Kylix now officialy dead?

Quote
>Thanks. I myself also am very positive regarding Kylix future, now that I
see how many people are using CrossKylix. Compared to the low activity
in this newsgroup, it's an quite impressive number.<<
That's really good Simon - I'm pleased for you. I bet there were more than a
few moments where you thought "I wonder if anyone will actually use
this...." !!
I'm using it and it's been an excellent addition to my armoury.
Dean
 

{smallsort}

Re:Re: Kylix now officialy dead?

Quote
>>So, in that case, it might not be dead but is effectively flatline.
>
>Only if you are part of the "I want to develop FOR linux ON linux"-group.
>Which seams to be rather small. Actually you are the first one that group
>to speak up ;)

In the same vein as you seem to advise me: have a look at the programs
originating in the Linux camp that eventually are ported to Win32. Same
old.
And this is relevant HOW? Delphi is coming from the DOS/Windows, chances are
low to see people starting with Kylix under Linux who then want to port to Windows,
if that's what you wanted to say.
Also porting from POSIX to Windows is an entirely different world. And the past
has shown that many Unix/Linux killer apps ported to Windows took several years
to become somewhere near stable or performant. Remember Apache 1.x... coming
from the fork-world to the world of threading (that back then more or less was
an unused concept under Linux/BSD) was major step to take. But well, that's
off-topic I guess.
Quote
>No it isn't. Probably>80% of all linux programs are written using VI+gcc.
>And 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.

I think you are grossly underestimating that. And FWIW, kdevelop is much
better integrated into the building system that is used most of the time.
I can only speak of the big linux applications I use myself. That being said
I have to admit those are mostly server-side stuff. And the Linux die-hard guys
I personally know all only use VI for everything.
I guess we both don't have exact statistics.
Quote
>>And yet another load of bollocks. Borland simply wanted to jump on the
>>Linux 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.
>
>Name ONE commercial Linux RAD IDE that has significant sales.

Naem ONE commercial Linux RAD IDE that actually is worth it for a Linux
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.
What I wanted to say is that Kylix is the first and afaik still only commercial
RAD IDE offering for Linux. It's hard to compare something that doesn't have
any competitors.
The IDE being compiled against Wine*LIB* (you should know the difference) wasn't
a too future-proof idea, we all know that. It was planned to change in later
IDE versions. There was simply no real alternative to QT2. What else should
they have used? The alternative would have been nothing, NO GUI components.
Also Kylix never was tied to a particular glibc versions. Glibc uses versioning.
Get your facts straight.
Quote
Then why is a vendor such as Oracle able to let you install it relatively
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.
Oracle isn't exactly a GUI application, is it? If you wish to compare this
with Kylix, well, then compare it with the Kylix command line compiler. Works
under all flavours of Linux without any issues.
Quote
>Looking at all that gives me the feeling that getting Kylix to the point
>it now is was a major task, and quite successfull.

... in creating a nice and expensive doorstop that does not survive a single
Qt major version.
There is no single application that survived QT2 to QT3. They completely changed
all interfaces.
If you want to further discuss this, please do some research on the technical
facts. Hints given above, not too hard. Else I'll just justify my conclusion
that you are just a troll.
Simon
 

Re:Re: Kylix now officialy dead?

R.F. Pels wrote:
Quote
Yes, in fact I do. IMHO, porting an application from one OS to
another is a much more painfull process than most of us realize. It
is not merely catering to similar frameworks that is the difficulty
here, the difficulty lies in catering to different worlds altogether.
Proper tools are a boon, but will not shield you from having to make
numerous wellinformed choices on the use of primitives and
components. Get it wrong, and one is rapidly pulled into having to
maintain different and divergent codebases.
I do agree on this. Nevertheless I did not understand why you chose to
bring your points across in such a rude manner. The way you had
expressed them did not really help to understand your POV.
WRT Kylix Delphi and CrossKylix:
I do see the shortcomings of Kylix. I can also understand that some
people might look down on it. For sure Borland made a couple of
mistakes with their Kylix adventure. The lack of success is a proof
itself. Some where technical some were marketing mistakes. However, it
is moot to discuss this now. The situation is as it is.
The new movement in this area is from my POV a change in the right
direction. It will not help to bring in a lot of Linux developpers into
the Delphi camp (actually I guess none would be a safe bet ;-). For
existing Delphi developers, who need to go to Linux for some reason,
CrossKylix is a much less painful way than Kylix on Linux. Hence the
good success that CrossKylix currently has. With a more VCL compatible
CLX it might become even more popular. It might not be good enough for
your standards and needs, but it fits my needs pretty well.
 

Re:Re: Kylix now officialy dead?

Simon Kissel wrote:
Quote
What I wanted to say is that Kylix is the first and afaik still only
commercial RAD IDE offering for Linux. It's hard to compare something that
doesn't have any competitors.
It is however quite easy to say that:
1. The commercial viability of Kylix seems very disappointing
2. Kylix is tied too strongly to a number of components that are far more
volatile than the release cycle of Borland, which leads to numerous
technical problems in deploying it on newer Linux distros in a
workable fashion
3. Kylix is a radical departure of the building mechanisms used in the
Linux world (although I can understand why)
In fact, I think Kylix was just meant as a sort of porting tool to port
Windows applications to Linux. By tying it to Qt2 and not making that
connection flexible in the first place Borland effectively created a
product that has a very limited lifetime, not to mention the fact that Qt2
isn't exactly looking very nice. This - and the fact that Borland seems to
have stopped developing Kylix any further - gives me reason to believe that
Kylix as it is now is an unsuccessfull commercial IDE offering and has been
that from the beginning, notwithstanding the sublime efforts of several
people to prolong its lifetime.
In fact, I'm somewhat astonished that Borland didn't use their RAD designer
prowess to create just that, a RAD designer tool, and piggy back that on a
bindable CLX or a visual framework where they could have provided the tools
to generate the bindings a developer needs. An IDE is something that the
Linux world isn't waiting for. There are more than enough IDE's around -
Anjuta, kdevelop, Eclipse - just to name a few. Do I need yet another
programming language for Linux? No, I don't. There are enough of them as it
is.
It is RAD UI design that is an area where Linux can be improved. Port
applications from Windows? Fine. Create a portable format specification,
import it in the Linux variant of the designer and generate equivalent
code. Do I need a Borland Pascal compiler for that? In fact I only need
that to port UI and application code. Is that a viable alternative? Only if
the compiler and runtime is properly integrated in the other tools of the
trade, gdb for example. And even then, the original code should be
structured and maintained in a portable fashion.
And even then. In most cases, I think it is easier to just recreate Windows
functionality in Linux if that is what is wanted. Yes, good tools will help
doing that. And yes, maintaining more than one codebase might be difficult,
but should be set off against (paritally) maintaining one codebase catering
to VCL as well as CLX.
Quote
Get your facts straight.
Getting my purely technical facts straight isn't mitigating the fact that by
now the technical underpinning can be regarded as outdated and/or feeble by
now. WineLib should have gone out the door after Kylix1.
Quote
>Then why is a vendor such as Oracle able to let you install it relatively
>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.

Oracle isn't exactly a GUI application, is it? If you wish to compare this
with Kylix, well, then compare it with the Kylix command line compiler.
Works under all flavours of Linux without any issues.
No, I don't want that. That is not the point. The point is that it /is/
possible to create a product that does not pubicize its internals while at
the same time being rather successfull in surviving the volatile nature of
Linux as it is.
Quote
There is no single application that survived QT2 to QT3. They completely
changed all interfaces.
There are numerous techniques that make it quite easy to adapt a framework
library to interface flux. You might be interested in the speed with which
a number of language bindings are updated in KDE, for example.
Quote
Else I'll just justify my conclusion that you are just a troll.
You don't need to justify your own conclusion. It's all yours. I'd rather
have you not trying to stereotype me into something undesireable for the
single reason that you do not seem to agree with me.
--
Ruurd
 

Re:Re: Kylix now officialy dead?

Jan Mitrovics wrote:
Quote
>LOL. Seeing an onslaught of programs totally unsuitable for Linux.

Sorry, but I fail to see, where you provide any kind of contribution
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?
Yes, in fact I do. IMHO, porting an application from one OS to another is a
much more painfull process than most of us realize. It is not merely
catering to similar frameworks that is the difficulty here, the difficulty
lies in catering to different worlds altogether. Proper tools are a boon,
but will not shield you from having to make numerous wellinformed choices
on the use of primitives and components. Get it wrong, and one is rapidly
pulled into having to maintain different and divergent codebases.
--
Ruurd
 

Re:Re: Kylix now officialy dead?

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.
--------------
This kind of attitudes seems a bit silly when attempting to make Linux a
commercially viable product. Perhaps this is the real reason why Borland
isn't developing the Kylix product any further, and possibly why we don't
here of many other commercial products becoming available for Linux**. This
type of reaction would send a pretty strong message to Borland that Kylix
isn't wanted. Next, I will agree that Linux has made strong strides into
the server market, though it is still a minority in that market. I have also
played around with Linux myself and I will also agree that it has great
potential. However, I have found that there is certain percentage of Linux
supporters who feel that any piece of software written to run under Linux
should be free for anyone to use and preferably with the source code
included, and the statement above reaffirms that with me. This is of course
coming from someone who makes his living from writing software.
**Yes, I know that Oracle and IBM have products that run under Linux,
however the bulk of them are Java based.
 

Re:Re: Kylix now officialy dead?

R.F. Pels wrote:
Quote
There are numerous techniques that make it quite easy to adapt a
framework library to interface flux. You might be interested in the
speed with which a number of language bindings are updated in KDE, for
example.
Like one mouse click for the "Qt3 for Kylix" bindings ?
Quote
By tying it to Qt2 and not making that
connection flexible
The problem is that the CLX is not like an application that uses a subset
of the framework. CLX uses most classes and functions offered by the
framework. So how would you have made the binding flexible?
Quote
in the first place Borland effectively
created a product that has a very limited lifetime, not to
mention the fact that Qt2 isn't exactly looking very nice.
At that time when Kylix was released there was no Qt3 available, so Qt2
was the look KDE 2 users were used to.
--
Regards,
Andreas Hausladen
 

Re:Re: Kylix now officialy dead?

Andreas Hausladen wrote:
Quote
>There are numerous techniques that make it quite easy to adapt a
>framework library to interface flux. You might be interested in the
>speed with which a number of language bindings are updated in KDE, for
>example.

Like one mouse click for the "Qt3 for Kylix" bindings ?
No Andreas, you of all persons should know that generating and checking
bindings isn't that easy. However, I don't think it would be undoable if
properly tooled. Not exactly a one-click type of thing, no. Or did you
forget the smiley perhaps :-)
Quote
The problem is that the CLX is not like an application that uses a subset
of the framework. CLX uses most classes and functions offered by the
framework. So how would you have made the binding flexible?
I'll probably will get flamed to death for even suggesting it. However, the
decorator pattern looks quite promising in that respect. That creates the
possibility of binding to different underlying UI frameworks from a common
place. By no means a trivial excersize, I realize that. And possibly
leading to noops in certain cases because the underlying UI may lack
certain features. This is not a perfect world alas.
I /know/ that in Java it is a different ballgame, and more or less hacked,
but that could have been a way to do it for at least the visual parts of
CLX. And yes, Java, or Swing for that matter isn't a fully successfull
example of it, most notably on the issue of standard dialogs like those for
opening and saving files.
There are better examples of adapting a framework to different technologies.
In the VCL and CLX arena, the way Borland succeeded in hooking into
different databases for example.
That all said, what would have happened if all Win32 specific code had been
factored out of the VCL by introducing decorators? In my mind that would
have opened the possibility of a truely portable VCL. Not only portable to
Qt2, Qt3 or the different KDE flavours, but even to .Net or wxwidgets...
Quote
>in the first place Borland effectively created a product that has a very
>limited lifetime, not to mention the fact that Qt2 isn't exactly looking
>very nice.

At that time when Kylix was released there was no Qt3 available, so Qt2
was the look KDE 2 users were used to.
And I think one of the main reasons why KDE at that time already provided
the means to theme it. In fact, KDE2 looked better than plain Qt2, IMHO.
--
Ruurd
 

Re:Re: Kylix now officialy dead?

R.F. Pels wrote:
Quote
Heh. Beauty is in the eye of the beholder :-) What I can't stand is
that some people see fit to perpetuate the stereotypical freeloading
image of Linux users. You cannot blame the failure of Kylix on Linux
users not wanting to buy a product. It is the product that is
unsuccessfull, not because it is/was too expensive, but simply
because it didn't cater well enough to the Linux community as a
development tool. As I said in another post, there are enough IDE's
as it is.
While I do not like any kind of stereotypes at all, I guess it is quite
safe to say that the market drivers are somewhat different between the
Linux and the Windows world.
Quote
As a matter of fact, I did purchase all three Kylix versions and had
high expectations of it. I am familiar with Delphi, maybe not the
most recent versions, and would have loved to have the same
functionality and speed in write-test-debug as Delphi, however, Kylix
did never pay off for me in that respect. It never was as stable and
it does not fit into Linux good enough.
I have bought Kylix 1 too. I skipped Kylix 2 and Kylix 3 came with
Delphi 7. I too had high expectations on Kylix, but also on Linux as a
platform. The projects that we targeted with Kylix/Linux did not take
off for reasons more related to business than to technology.
Quote
Granted. However, I still think we need to have a close look at how
the latest initiatives are going to pan out in the coming months. And
I still have some reservations about the viability of Kylix in the
near future.
Well, I would not want to build a whole business around Kylix for the
time beeing. As mentioned earlier, I appreciate the new initiatives and
really hope they will work out well.
 

Re:Re: Kylix now officialy dead?

R.F. Pels wrote:
Quote
No Andreas, you of all persons should know that generating and checking
bindings isn't that easy.
With the right tools it is easy. It is not a one click action but to
regenerate the Qt3 for Kylix library and bindings I must only type "make"
and wait (because of very slow gcc). But the tool I use has a drawback: It
depends on doxygen's generated xml files. Andy doxygen is a pain when
misused as a C++ parser.
Quote
And I think one of the main reasons why KDE at that time already provided
the means to theme it. In fact, KDE2 looked better than plain Qt2, IMHO.
You can use KDE 2 themes in CLX applications with some extra effort, but
who still uses KDE 2. Even Debian does no more use it with the next stable
release.
--
Regards,
Andreas Hausladen
 

Re:Re: Kylix now officialy dead?

Jan Mitrovics wrote:
Quote
I do agree on this. Nevertheless I did not understand why you chose to
bring your points across in such a rude manner. The way you had
expressed them did not really help to understand your POV.
Heh. Beauty is in the eye of the beholder :-) What I can't stand is that
some people see fit to perpetuate the stereotypical freeloading image of
Linux users. You cannot blame the failure of Kylix on Linux users not
wanting to buy a product. It is the product that is unsuccessfull, not
because it is/was too expensive, but simply because it didn't cater well
enough to the Linux community as a development tool. As I said in another
post, there are enough IDE's as it is.
Quote
The new movement in this area is from my POV a change in the right
direction. It will not help to bring in a lot of Linux developpers into
the Delphi camp (actually I guess none would be a safe bet ;-).
As a matter of fact, I did purchase all three Kylix versions and had high
expectations of it. I am familiar with Delphi, maybe not the most recent
versions, and would have loved to have the same functionality and speed in
write-test-debug as Delphi, however, Kylix did never pay off for me in that
respect. It never was as stable and it does not fit into Linux good enough.
Quote
For existing Delphi developers, who need to go to Linux for some reason,
CrossKylix is a much less painful way than Kylix on Linux. Hence the
good success that CrossKylix currently has. With a more VCL compatible
CLX it might become even more popular. It might not be good enough for
your standards and needs, but it fits my needs pretty well.
Granted. However, I still think we need to have a close look at how the
latest initiatives are going to pan out in the coming months. And I still
have some reservations about the viability of Kylix in the near future.
--
Ruurd
 

Re:Re: Kylix now officialy dead?

Andreas Hausladen wrote:
Quote
With the right tools it is easy. It is not a one click action but to
regenerate the Qt3 for Kylix library and bindings I must only type "make"
and wait (because of very slow gcc). But the tool I use has a drawback: It
depends on doxygen's generated xml files. And doxygen is a pain when
misused as a C++ parser.
Yes. RE-generate. But generating the first iteration must have been
'painfull'...
However, what is your take on the other things I posed? I'm interested in
what your take is on them...
--
Ruurd
 

Re:Re: Kylix now officialy dead?

R.F. Pels wrote:
Quote
Yes. RE-generate. But generating the first iteration must have been
'painfull'...
Yes it was painfull because there was no tool that generated the code. But
now I have that tool and it is also able to generate bindings for
wxWidgets except that fact that doxygen generates trash for the wxWidgets
header files.
Quote
However, what is your take on the other things I posed? I'm interested in
what your take is on them...
Yes, it would be nice to have another layer (Linux guys love software
layers: glibc+X+Qt+KDELib ) but for what price?
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
(andy.jgknet.de/blog)