Slashdot Mirror
Kylix in Limbo
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?"
Delphi, with its ability to write Windows programs, was having trouble enough. Once Visual Basic came along, it really stole a lot of their thunder in terms of making it easy to write windows programs.
..... yup, small marketshare.
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.
Natural != (nontoxic || beneficial)
I've been using Kylix for about 3 months now, and I've reached the stage of considering completely abandoning Kylix and continuing with linux native C++ and Qt.
:= ''. If I
remove that line there is no problem. This is definately weird stuff.
.ico files.
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.
Some of the problems might have been that you had to run one of the mass market distros to even get the installer to run.
Obviously Gentoo was out - so I couldn't install it there.
Atop RH 8 it ran like a dog, slower than molasses. Turning off the antialiasing helped, but not that much. The Win32 version was much more responsive. It appeared like the environment was running in some kind of emulation layer.
It didn't use the GNU toolchain so porting the apps was nigh unto impossible.
It didn't seem like a winner, and I happen to like Delphi...
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
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.
Not my area really, but I know I've got a buddy working on the Lazarus project:
http://www.lazarus.freepascal.org
Might be of some interest to some Delhpi folks.
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*
All I know about Bush is I had a good job when Clinton was president.
The old-style Turbo C IDE does exist for Linux. A clone called RHIDE provides a very similar look and feel, and many new features.
I started using it right about the time that geramik came along. I finally had some unity in application appearence. After using Kylix for a while I came to the realisation that anything I wrote with it would not only look out of place among everything else on my system, but in my opinion at least - look pretty ugly. I had a program I was working on in Kylix up when a friend came over, and the first thing she said after walking by the computer was "Hey! That looks like a Windows 3.1 program!". Perhaps they've changed this behavior since then, but since finding WxWindows I havn't had any motivation to check back.
Everything will be taken away from you.
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.
In Julian Smart's recent announcement of the wxwindows foundation, he noted that Borland is supporting wxwindows development and that an employee of Borland is on the Board of Directors at the foundation. This is probably behind Borland's 'neglect' of kylix--expect the next generation to support wxWindows. This doesn't sound like abandonment to me.
Borland "Object Pascal" isn't standard Pascal.
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).
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
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.
Free Software: Like love, it grows best when given away.
I've been a fan of Borland Delphi for many years now. After trying VB, MSVC++, and Delphi, I found Delphi the easiest to use. Its native code dependencies make it easy to deploy applications without worrying if the user is running the latest version of the MS C++ runtime libraries (MFC), and the ever growing library of natively written code makes it easy to deploy all kinds of applications. I do have one giant complaint about Borland, though. They make little effort to fix known and documented bugs in their software.
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.
>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
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
Open cross-platoform Object Pascal, Delphi compatible, still beta, but really worth investigating.
http://www.lazarus.freepascal.org
http://lazarus-ccr.sourceforge.net
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.
I used Delphi for several years. If they had adopted ODBC database connectivity instead of their Borland custom database connectivity I would still be using Delphi and Builder.
Glonoinha the MebiByte Slayer
"...because Delphi's VCL is based on the MFC."
Bzzzt! The VCL was/is an original OO/component framework built on top of the Win32 API, using nothing from MFC.
Steve Magruder, Metro Foodist