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?"
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.
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.
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.
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.