Kylix in Limbo 443
IgD writes "Kylix, Borland's Linux port of their popular Delphi compiler has been covered on Slashdot before. LinuxWorld is reporting that Kylix development is in limbo. Many speculate this is a politically correct way of saying the project has been abandoned. There hasn't been any updates to Kylix 3.0 in well over a year. One user who attended BorCon this year wrote in his blog that Borland didn't have any updates to Kylix planned for 2004. This is really disheartening news. Why didn't Kylix sell? Does this say something about the application or about the difficulties of marketing a commercial Linux application?"
Not surprised (Score:3, Informative)
So now you look at a platform like Linux, with a minority marketshare, and look at Delphi with its already small marketshare.... that adds up for
Oh, don't forget dotnet and java, both of which have a lot of muscle behind them.
Kylix/CLX has too many problems (Score:3, Informative)
I've been developing a file manager which makes use of the components below. With every component I've described issues I've found with them.
TApplication:
- Some very weird bug caused spontaneous segmentation faults during the Application.run command. I traced the cause of the segmentation fault the a line similar to Form1.Edit1.caption
TForm:
- Assigning and reading the top and left properties during form creating will give wrong results and in some cases cause the form to be put in the wrong place.
TMainMenu, TPopupMenu:
- The BeforeDrawMenuItem gets buggy if boldfaced characters are used.
TListView:
- Drag and Drop implementation is completely screwed up. Whether I use CLX OnDragStart kind of commands or code which calls Qt directly, drag and drop operations will give rise to strange mouse behavior.
- Multiselect and Drag 'n Drop is not compatible. I've had to rewrite all the mouse handling in order to be able to drag 'n drop and select items. I had to deny all mouse events to CLX in order for everything to work.
- Multiple columns and an Imagelist will cause images to be displayed in the subcolumns even if the imageindex is -1.
- OnDrawItem fails miserably. In the first place there is no direct way of knowing what column your are drawing the information for. In the second place the canvas provided to draw on stretches beyond other columns. If you drag the scrollbars the drawed data gets screwed up.
-TTreeView
The TTreeView has all the same problems as the TListView, as they both are based on Qt's QListView
-TCoolBar & TToolbar
A Ttoolbar on a TCool bar gives a wrong height property for buttons on the toolbar. A Toolbar sometimes spontaneously gives itself another position on my form. This is not reproducible and happens occasionally.
General Problems:
-The FindFirst command is very limited. Instead of providing all items available in a TStatBuf buffer it does some translation to windows which eliminates some of linux's cool aspects like symbolic links. Directories and System files are indistinguishable because of bad code in CLX.
- On my Redhat 7.2 computer using Kylix is one big Illegal Operation festival.
- On my Redhat 7.1 computer I can't use the debugger because it WILL crash after 4-9 debug cycles.
- Icon support is really bad. The kylix code is unable to decode almost all ordinary
These are just some issues which I can think of at the moment. There are more. During development of this program I've spent more than 50% of my time solving problems with Kylix. This consists of either looking for workarounds, changing CLX code, calling Qt directly, or rewriting components entirely. So many functions provided by Qt are not available in Kylix, which in some cases severely limits the functionality of the Kylix components. The only things which went well were calls which bypassed CLX or used LibC. I'm seriously considering dumping kylix and using Qt directly. I've gotten fed up with having to debug Borland's attempt at a layer between Qt and their compiler. I don't feel like waiting for Kylix version 3.0 or whatever in which they've hopefully solved all these issues. I hope someone will convince me otherwise because I believe Kylix has great potential. I've been using Delphi for some time now and I love Delphi. It has been a great disappointment to see Kylix fail.
Comment removed (Score:3, Informative)
Kylix doesn't sell?? (Score:3, Informative)
IgD writes:
I didn't see a trace of that in either the article or the blog...
Then in the blog:
So no, it hasn't really been abandoned. It's just Borlands usual way of releasing stuff.
Alternatives.... (Score:3, Informative)
http://www.lazarus.freepascal.org
Might be of some interest to some Delhpi folks.
Re:seen the price of VS.NET? (Score:5, Informative)
Apple, meet Orange.
You're comparing a Win32 development tool to a Linux development tool. Now I'll pretend you know this, and debate it anyways-- with Visual Studio .NET Professional you don't just get one language, you get access to four. You get Visual C# .NET, Visual C++ .NET, Visual Basic .NET and Visual J# .NET. With Kylix all you get is Delphi (Pascal) and C++ (which I'm not entirely sure, but I think the backend uses gcc-- I may be wrong on this point though).. two languages vs. four languages in VS.
Of course the odd thing is, Kylix has an "open edition" that's free as in beer for GPL work, IIRC. It doesn't make sense that Linux developers wanting to try it out wouldn't try the OE version then pay for the retail version if they wanted to do commercial apps down the road.
Agreed, their IDE's have always been a winner with me, but their marketing skills leave loads to be desired. Just check out some of the prices at shop.borland.com vs. the prices list at shop.microsoft.com for examples of the travesty going on at Borland today. *shakes head*
Re:seen the price of VS.NET? (Score:2, Informative)
Because it was ugly (Score:5, Informative)
Kylix vs. Delphi: the CLX (Score:4, Informative)
In addition using CLX means you've got to distribute DLLs with the app. Until now we've managed to avoid this. Something you don't often hear about but in our eyes a major advantage of Delphi is that for many apps the EXE is all you need - no DLL hell for support staff to worry about.
Price wasn't an issue for us: Kylix 3 came free with our copy of Delphi 7.
Probably because of Borland's support of wx (Score:4, Informative)
The operative phrase is "based on" (Score:3, Informative)
It suffers from few of the restrictions of the standard language, and has many enhancements (e.g., properties) that are better than their C++ equivalents, IMO.
Also, it compiles faster than C++, and the IDE is just great.
It has its problems though, (every language does), but, all in all, I think that it compares favorably against C++ in many ways (and, of course, unfavorably in others).
Re:Linux users are cheap (Score:3, Informative)
I pity the companies who tried to develop Linux software using Kylix and are now orphaned. I'd say that this is the reason why Linux users try to avoid non-free (as in slavery) software.
If Kylix were free (as in freedom) software, at least the users who still wanted to use it would have the option of paying for a team to continue support and upkeep. Now they're a SOL if they need anything fixed/canged.
Re:Delphi? (Score:5, Informative)
About three years ago, I found a bug in the implementation of the virtual list view. I filled out their online bug report, giving in excruciating detail an explanation of what the problem was, why I thought it was happening, and exactly what had to be done to reproduce it. Three days later, I got a response that the bug was verified as existing, had been cataloged, and would be fixed in the next update. That was in Delphi 5.0.2. Now, 3 years later, they're on Delphi 7, and the bug still hasn't been fixed. Talking to colleagues of mine, I have found other examples of the exact same pattern: Bug gets reported, bug acknowledged by Borland, bug never gets fixed.
Borland really needs to fix these kinds of problems, as they only lead to frustrations for programmers. If they're going to take the trouble to catalog and verify bugs, they really need to go one step further and fix them.
Re:it's pretty obvious... (Score:3, Informative)
>Who needs Kylix when you can write your GUIs in >Python using wxWindows, GTK, or QT for FREE?
_productivity_
>Who needs Kylix when you can write your GUIs in >Perl using wxWindows, GTK, or QT for FREE?
_productivity_
>Who needs Kylix when you can write your GUIs in >C/C++ using wxWindows, GTK, or QT for FREE?
_productivity_
In other words the exact same reasons why the bulk of the professional programmers on Windows doesn't use this.
Kylix was not targeted at the hobbyist programmer, _OR_ the serious programmer with a difficult task.
It was targeted at
- converting delphi source. (e.g. database clients) to create a corporate Delphi software market.
- Productivity while building new (GUI) linux apps.
For the hobbyist, or professional that is at home at unix, Kylix was less useful, because of the sheer size, the distro requirements etc.
And of course you have
Who needs Kylix when you can _drag and drop_ your GUIs in Delphi's Pascal using Lazarus (lazarus.freepascal.org) FOR FREE ?
As a bonus, it works on FreeBSD and (soon) linux/ too
Re:it's pretty obvious... (Score:3, Informative)
This is partially true, but Lazarus is only usable for just under a year.
I also don't pretend that lazarus is a drop in replacement.
However it does allow to recompile most non-visual Delphi sources with the brandnew 1.9 Free Pascal compiler. (that is much closer to D6 compat then the old one), and it is actual GUI design a la Delphi, not distro or even OS dependant (which does it for me, Debian and FreeBSD here)
FPC moreover is tinkering with PPC, Sparc and Arm, and there is serious hope this will be up and running with lazarus in late spring next year
LAZARUS Project is the alternative (Score:2, Informative)
http://www.lazarus.freepascal.org
http://lazarus-ccr.sourceforge.net
Kylix alternative (Score:2, Informative)
It's a shame about Kylix. Fortunately there's an open source alternative.
The Lazarus IDE has made a lot of progress over the last year. It's built on the cross platform and self contained Free Pascal Compiler... so all a Lazarus app needs to install and run is GTK and a Linux kernel with elf support. This makes writing and packaging trans-distro apps a relatively easy process. Lazarus and FPC can currently produce full featured graphical apps on Linux and FreeBSD. A The Win32 version is also progressing nicely, for those who are interested.
The Lazarus IDE and Free Pascal Compiler are written in Object Pascal and compile themselves. The latest RPM's and source tarballs can be found at http://lazarus-ccr.sourceforge.net [sourceforge.net].
Re:Delphi? (Score:3, Informative)
Comment removed (Score:3, Informative)