Board index » kylix » What to do with Kylix

What to do with Kylix


2004-02-12 02:33:01 AM
kylix2
www.lemanix.com/lemanix/lemanixisapi.dll/Entry
--
Nick Hodges -- TeamB
Lemanix Corporation
 
 

Re:What to do with Kylix

Quote


www.lemanix.com/lemanix/lemanixisapi.dll/Entry

Nah... Offshore it. Have some enthusiasts in India or elsewhere keep it
going.
(note that I'm saying offshoring and not outsourcing)
--
Anders Ohlsson - Borland Developer Relations - bdn.borland.com/
Borland Software Corporation - www.borland.com/ - Excellence Endures
Enabling our customers to move into the future without abandoning their past
homepages.borland.com/aohlsson/disclaimer_ani.gif
 

Re:What to do with Kylix

Good article, Nick. I've recently acquired Kylix 3 and am learning the
differences from Windows programming.
I'm especially intrigued by 2nd to last paragraph where you state, "Kylix makes
it pathetically easy to build powerful, native DSO libraries that run on
Apache." I've been building a web site in PHP and have been wondering about
using Kylix. I've only written one web app and that was using Delphi 5 with
WebBroker about 4 years ago. I haven't taken the time to get into WebSnap, but
know for sure I don't want to do PHP for the rest of my life!
I'll definitely take a closer look at it.
--
David Cornelius
CorneliusConcepts.com
"Nick Hodges (TeamB)" < XXXX@XXXXX.COM >wrote in message
www.lemanix.com/lemanix/lemanixisapi.dll/Entry
--
Nick Hodges -- TeamB
Lemanix Corporation
 

{smallsort}

Re:What to do with Kylix

David Cornelius wrote:
Quote
I'll definitely take a closer look at it.
For more on WebSnap --
www.lemanix.com/lemanix/lemanixisapi.dll/WebSnap
--
Nick Hodges -- TeamB
Lemanix Corporation
 

Re:What to do with Kylix

Anders Ohlsson (Borland) wrote:
Quote
Nah... Offshore it. Have some enthusiasts in India or elsewhere
keep it going.
I don't mean to attack you or anything, but this comment,
particularly since you work there, sparks all kinds of questions...
Have Borland remote employees work on it?
Open source it?
Sell / give the rights to it & source to someone else?
Enter into a revenue sharing agreement with a remote development
company? They bear the costs, you split the sales?
Or was this a joking, off hand remark w/out an emoticon?
-Brion
 

Re:What to do with Kylix

Nick Hodges (TeamB) wrote:
Quote
www.lemanix.com/lemanix/lemanixisapi.dll/Entry
Nice article. Some thoughts:
Maybe the fact that CLX was bound to one particular Qt version is what made
the GUI part less attractive. In fact, IIRC, Kylix came to market and not
long after that a new major version of Qt came out. Kylix alas lacks the
possibility to graft CLX on the new Qt version. Or on KDE. Or GTK. Not to
mention the fact that Qt2 wasn't/isn't exactly a looker either. In that
last respect, Kylix might have been launched too soon.
As for the webservervices part, yes, there might be a chance there, however,
it still will have a tough time competing with a host of different tools
that more or less target the same area. PHP, Perl, plain old shell
scripting just to name a few. Their relative advantage in the field is not
only their existence but the huge number of utilities and readymade
software that is already in pretty good shape.
Parting thought here is that Borland seems to have some fairly astounding
knowledge on how to create GUI RAD tools, and FWIW, I think that *that* is
what the Linux community is missing: a GUI RAD tool graftable on the major
widget libraries where it is easy to create additional components based on
more or less arbitrary code libraries. However, I seriously doubt that
basing such a tool on ObjectPascal is a very good idea unless it can almost
natively make use of C++ libraries such as Qt.
--
Ruurd
 

Re:What to do with Kylix

R.F. Pels wrote:
Quote
Maybe the fact that CLX was bound to one particular Qt version is
what made the GUI part less attractive.
I don't think there's any doubt about that. I sometimes wonder why
Borland didn't buy TrollTech outright instead of just 'investing'.
--
Nick Hodges -- TeamB
Lemanix Corporation
 

Re:What to do with Kylix

Nick Hodges (TeamB) wrote:
Quote
I sometimes wonder why Borland didn't buy TrollTech
outright instead of just 'investing'.
... And convert Qt to Delphi language :-)
R.F. Pels wrote:
Quote
However, I seriously doubt that basing such a tool
on ObjectPascal is a very good idea unless it can
almost natively make use of C++ libraries such as
Qt.
It is not impossible to link against a C++ shared object with Kylix
(Delphi). Actcually it is easier than doing this with Kylix (BCB) due to
the "external" keyword. As gcc 3 uses an ABI that can be "simply
reimplemented" via a class it should be more easier than it was with gcc
2.95 compiled SOs. And as QObject's VMT starting with Qt 3 is the first
object field we can map the virtual methods directly to the QObject's
methods.
But there are also some issues where you must use some "non Delphi usual"
techniques.
For example the three destructors (base object, complete object and
deleting destructor), static methods (something different from class
method, but class methods could be miss-used for this purpose), static
fields (the only solution I found was a class method returning a (typed)
pointer to the static field). And the most complex issues: templates and
multiple inherences. But as Qt does not utilize templates that extensive
this should not be a problem. The only issue for which I had not found a
good solution is multiple inherences.
Doing the header conversion by hand is only possible for some small
classes but not for the whole Qt library. So a helper utility must be
written that autogenerates the files so that there should be only some
small parts to do by hand.
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
 

Re:What to do with Kylix

Hello,
On 11 Feb 2004 10:33:01 -0800, "Nick Hodges (TeamB)"
< XXXX@XXXXX.COM >wrote:
Quote
www.lemanix.com/lemanix/lemanixisapi.dll/Entry
I would like very much to see any possibility to make Kylix profitable
for Borland and for us. But if the problem has been unrealistic
expectations by Borland, it would be better not to repeat the same
mistake.
Quoting you from the URI above:
Quote
Kylix applications require the Trolltech qt library to be shipped with them.
A precission: an old version of it. QT is very common and there should
be no neeed to deploy current versions.
Quote
An application built with Kylix actually has to go from Pascal through a layer to a C++ library in order to work.
I think this is the key: integration with common Linux libraries.
Quote
Actually, I misspoke. It is GUI applications that have to make these trips.
I think you are wrong there. I haven't looked into this during a long
time, but IIRC Apache 2 wasn't supported and Apache 1.3 needed a
rebuild to add Kylix compiled modules. I wasn't able to do it after a
lot of hours, then I gave up. I thought I had enough Linux experience
then. Maybe not enough.
Eventually I found a solution for using Apache without worrying about
versions. Apache has an internal proxy. You can create a web server
with Indy and tell Apache to act as a proxy for dynamic requests.
But the same problem with versions seemed to happen with database
libraries that would also be needed to build server apps. I could have
looked for another workaround, but then Kylix wasn't looking like the
standard platform that I was looking for.
Quote
Kylix, strip out all of the qt-based GUI features, and sell it as a server building application development tool.
I like the idea, very natural. But there're two more facts that I
don't see clear: first I doubt Kylix will sell well to existent Linux
users whatever you do with it, except completely opensourcing it. I
mean the compiler. Borland won't do it, will it?.
Borland can sell Kylix to Delphi users that want an alternative server
platform, though. Or maybe to the same people that use J2EE or Oracle
in Linux.
And second: don't expect to sell too much in the hosting market. PHP
or Java can be "sandboxed". Kylix would fit better for intranets,
in-house, maybe housing, but not for general purpose hosting. So Kylix
would be competing with J2EE, not with PHP.
If Borland still thinks that it's a good idea, great.
Quote
Linux's major inroads in the marketplace have been as a server, whether it be a database server, a web server, a J2EE server, or any other kind of server. Linux on the desktop remains the dream of many a Linux Distribution seller and Slashdot cowboy, but for now, it is just that, a dream.
I disagree. Office desktops and home desktops are very different
animals. Linux is still a beast for most home users, but it's useable
in corporative desktops.
I have had some requests from customers. They are using Linux as
server and would like to replace desktop apps. There are usable
application for office productivity. But they also need custom apps
and I can't promise to write them with a product that has been
freezed.
Quote
Microsoft has no intention of letting Linux cut into its desktop market the way it has in the server market,
Did they let Linux cut into server market on purpose? ;-)
I guess you mean it took them by surprise. Maybe. But what can they do
to stop Linux in the corporate desktops now?. Next Windows version is
expected for 2006. More friendly distributions and maybe some
productive programming tool (I've read something about a VB clone)
could appear before. Once Linux is adopted by several important
companies or governments, the landscape could change very quickly.
Quote
so trying to sell a development tool that builds desktop applications may be a non-starter, but selling and marketing a tool that builds the kinds of applications that Linux users want and need -- now there's a way to make money.
How is better selling a tool in a crowded market better than in a
{*word*269} one?. There are very complete open source J2EE and PHP
solutions for high and low ends at no cost. Tools for desktop are not
by far as sofisticated as Kylix, IMHO.
Quote
Now I don't know the technical requirements or exactly what work would need to be done to make this happen. Perhaps it would be too much work to make it worthwhile. Perhaps it isn't even possible.
I think (but my information may need to be updated) that the silver
bullet could be some kind of compiler/linker extension that would
allow to directly link to gcc libraries. Borland has compiler
technology and C++ compilers. If Borland can't do it, I would be
puzzled.
Quote
Bottom line: By actually reducing the feature set of Kylix, and by marketing it as a server development tool, Borland might actually be able to turn Kylix into a successful product, and a tool that Linux developers want and need.
I would like to be wrong, really. Maybe if the development could be an
order of magnitude easier with Kylix than with J2EE...
Nick, anyway thank you very much for this. I bought a copy of Kylix 2
and it's very sad to see the dust growing on it :-(
Nico
 

Re:What to do with Kylix

In article <402a755d$ XXXX@XXXXX.COM >, XXXX@XXXXX.COM
says...
Hi,
Quote
www.lemanix.com/lemanix/lemanixisapi.dll/Entry
Totally agree with all the 'server side' stuff, as that is all I ever
wanted to use Kylix for.
To be honest, I would have been more than happy with a compiler 'add
on' to Delphi.Windows that produced Linux binaries (even more happy if
it produced Solaris binaries as well <g>). That would have saved
Borland all the time an effort producing all the Linux GUI stuff and
IDE.
Phil
 

Re:What to do with Kylix

Quote
>I sometimes wonder why Borland didn't buy TrollTech
>outright instead of just 'investing'.

... And convert Qt to Delphi language :-)
Shoo!
Quote
R.F. Pels wrote:

>However, I seriously doubt that basing such a tool
>on ObjectPascal is a very good idea unless it can
>almost natively make use of C++ libraries such as
>Qt.

It is not impossible to link against a C++ shared object with Kylix
(Delphi). Actcually it is easier than doing this with Kylix (BCB) due to
the "external" keyword. As gcc 3 uses an ABI that can be "simply
reimplemented" via a class it should be more easier than it was with gcc
2.95 compiled SOs. And as QObject's VMT starting with Qt 3 is the first
object field we can map the virtual methods directly to the QObject's
methods.
Possible, but quite horrible. The current problem with the VCL
implementation in Delphi-Kylix is that is has to go through straight C.
With all kinds of administration on the Delphi side of the matter in
combination with the number of functions/classes that must be accessible
from the Delphi side to make it work in the first place.
Quote
But there are also some issues where you must use some "non Delphi usual"
techniques.
Maybe that is indeed the biggest problem of all. ObjectPascal and C++ are
pretty much the same but differ in a significant enough number of areas to
make an interfacing solution less than ideal. As you said:
Quote
For example the three destructors (base object, complete object and
deleting destructor), static methods (something different from class
method, but class methods could be miss-used for this purpose), static
fields (the only solution I found was a class method returning a (typed)
pointer to the static field). And the most complex issues: templates and
multiple inherences. But as Qt does not utilize templates that extensive
this should not be a problem. The only issue for which I had not found a
good solution is multiple inherences.
The thing is, after compilation, matters are flattened to regular function
calls. Extending ObjectPascal or making it possible to define external
functions as C++ and properly mangling them before linking in ObjectPascal
would severely simplify matters. The only thing needed in that case would
be the ability to properly mangle the external references:
function DoDah: Integer; external "C++" SomeClass::dodah() const...
for example. Or even:
function DoHicky: Boolean; external "C++" SomeClass<bool>::hicky()....
Quote
Doing the header conversion by hand is only possible for some small
classes but not for the whole Qt library. So a helper utility must be
written that autogenerates the files so that there should be only some
small parts to do by hand.
A while ago I stumbled on such a tool but I forgot where to find it :-( I've
been looking in the last hour or so but alas....
--
Ruurd
 

Re:What to do with Kylix

Quote


Or was this a joking, off hand remark w/out an emoticon?


Indeed. I've had a bad cold the last couple of days. Cold medicine
really screws you
up, let me tell you. Terribly sorry.
--
Anders Ohlsson - Borland Developer Relations - bdn.borland.com/
Borland Software Corporation - www.borland.com/ - Excellence Endures
Enabling our customers to move into the future without abandoning their past
homepages.borland.com/aohlsson/disclaimer_ani.gif
 

Re:What to do with Kylix

Nick Hodges (TeamB) wrote:
Quote
www.lemanix.com/lemanix/lemanixisapi.dll/Entry
Stating Kylix as server builder product does not change Kylix position in
Linux world not a bit. Entrie Linux environment (techical, organizational
and social) has certain *requirements* for a product to be successfull.
When product does not satisfy that requirements it never be successfull. It
is clearly that Borland not has and does not have intent to satisfy that
requirements, so they automatically bury deep grave for Kylix.
 

Re:What to do with Kylix

Ender wrote:
Quote
Nick Hodges (TeamB) wrote:

>www.lemanix.com/lemanix/lemanixisapi.dll/Entry


Stating Kylix as server builder product does not change Kylix position in
Linux world not a bit. Entrie Linux environment (techical, organizational
and social) has certain *requirements* for a product to be successfull.
When product does not satisfy that requirements it never be successfull. It
is clearly that Borland not has and does not have intent to satisfy that
requirements, so they automatically bury deep grave for Kylix.
It all depends where you are coming from.
If you are deep in the Linux world then what you have said makes sense
BUT if you are a Delphi web developer ie you are coming from the Delphi
end and you want to move an existing Delphi web app to relatively low
cost and high stability of Linux then it make a great deal of sense!!!!
I would love to see this encouraged - then the developers of the Delphi
database engine I am using would quite likely provide a Linux port [it
has been done in part] and I would very gladly go that route.
Richard Wilson
 

Re:What to do with Kylix

Nick Hodges (TeamB) wrote:
Quote


www.lemanix.com/lemanix/lemanixisapi.dll/Entry
I think what you have suggested is a good idea. I have been developing a Client/server
app for a couple of years now. The intention was always to develop the GUI on windows with Delphi
and deploy the interbase database and server based appications on linux.
I am very disappointed to read that there will be no updates to kylix this year (the year where
I needed kylix) so I'm being forced to rethink my plans to deploy on Linux.
Initially a "server only" version of Kylix would be everything I need to get going. However, I
also plan to transfer the whole app to linux in the next year or so to make the cost of ownership
low enough to sell to some of my target customers.
In short, I would buy a server only version of Kylix, but Borland will have to move quickly to
reassure me that Kylix will not just be left for dead. I simply cannot afford to take that risk. I
have deadlines and will find alternatives if I have to.
Best Regards.
Will.
p.s. I have thought about waiting for mono so that .net is an option for me but I feel that
mono will always be behind microsoft and I would have to wait too long to see a decent GUI
release of mono. I personally would prefer to use a native way of compiling for linux.