The Conclusion

Anders

kylix Developer

The Conclusion

2004-02-12 09:37:28 AM
kylix0
"Ender" < XXXX@XXXXX.COM >wrote in message

Quote

A>How big will be one sumple Application with one {*word*192} form "Hellow
A>World" written on J Swing, and the same App witten on C++ with Linked
A>Qt's ?

Personally i'm not make statical linking of Qt, it was done by my
colleague.
I should ask him. AFAIR it was something like 3MB application which use Qt
for GUI and other application subsystems.

So, what is the conclusion ?

There is not programming tool under Linux that to fit of every user
requirements - Small, Fast and Native.
It seems that if you want to be fast, small and native C++ and something
like KDevelop, but you loose that to be run on all Linux distorts. If you
want to be run to all Linux distorts - you use Java "Something", but you
receive something big and slow as a application.
So, the result:
Obviously, I'll keep my app on Kylix, cause at least will be native, fast,
and I'll carry with me one lib for all my Apps. Well it's big, but 3 my apps
use it, and with the compression is not so big : )
Thank you for your attention ...

Marc Collin

kylix Developer

2004-02-12 11:49:37 AM

Re:The Conclusion

Anders wrote:

Quote

"Ender" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...

>A>How big will be one sumple Application with one {*word*192} form "Hellow
>A>World" written on J Swing, and the same App witten on C++ with Linked
>A>Qt's ?
>
>Personally i'm not make statical linking of Qt, it was done by my

colleague.

>I should ask him. AFAIR it was something like 3MB application which use Qt
>for GUI and other application subsystems.
>
>

So, what is the conclusion ?

There is not programming tool under Linux that to fit of every user
requirements - Small, Fast and Native.
on any other system it's the same thing
It seems that if you want to be fast, small and native C++ and something
like KDevelop, but you loose that to be run on all Linux distorts. If you
want to be run to all Linux distorts - you use Java "Something", but you
receive something big and slow as a application.
So, the result:
Obviously, I'll keep my app on Kylix, cause at least will be native, fast,
and I'll carry with me one lib for all my Apps. Well it's big, but 3 my apps
use it, and with the compression is not so big : )

Thank you for your attention ...

--

Borland rulez pages.infinit.net/borland

pnichols

kylix Developer

2004-02-12 01:03:59 PM

Re:The Conclusion

Quote

There is not programming tool under Linux that to fit of every user
requirements - Small, Fast and Native.
There are, but you are possibly not looking at them :)

Quote

It seems that if you want to be fast, small and native C++ and something
like KDevelop, but you loose that to be run on all Linux distorts. If you
want to be run to all Linux distorts - you use Java "Something", but you
receive something big and slow as a application.
Not so. As per your requirements (aka Hello World) the Java application will

be 3K and using 1.4.2 start in 430 ms., in 1.5 start in 230 ms. and in C++
the app is approx. 430K and starts in 192 ms. So how does that make Java
big and slow? Of course the system will make a difference. In the case of
these numbers:
1800 Athlon
512 meg Ram
2.4.23 Kernel
KDE 3.1.4
Suse Linux

{smallsort}

pnichols

kylix Developer

2004-02-12 01:39:23 PM

Re:The Conclusion

"Anders" <Anders'at'cosmo.nl>wrote:
BTW,
Check out Gambas and Visual TCL for pretty good Linux RAD IDEs that are not
based on Java.
Visual TCL is based on the TCL language, while Gambus is based on Basic, but
compiles to C/C++.
I wish someone had a real C++ RAD IDE, like Gambus, or Visual TCL. I do not
like the idea of programming per se in Basic, but Gambus works better than
anything else I have used as a native RAD IDE, except Kylix. Gambus keeps
up with Distros however, while the QT 2.0 based CLX of Kylix, does not.
Both are open source and freely available
For Gambus: gambus.sourceforge.net
Visual TCL: vtcl.sourceforge.net/

theo

kylix Developer

2004-02-13 03:38:31 AM

Re:The Conclusion

Quote

I wish someone had a real C++ RAD IDE, like Gambus, or Visual TCL. I do not
like the idea of programming per se in Basic, but Gambus works better than
anything else I have used as a native RAD IDE, except Kylix. Gambus keeps
up with Distros however, while the QT 2.0 based CLX of Kylix, does not.

Agree. It looks really good. Why is it Basic??????

Quote

For Gambus: gambus.sourceforge.net

pnichols

kylix Developer

2004-02-13 04:23:04 AM

Re:The Conclusion

theo wrote:

Quote

>
>I wish someone had a real C++ RAD IDE, like Gambus, or Visual TCL. I do
>not like the idea of programming per se in Basic, but Gambus works better
>than anything else I have used as a native RAD IDE, except Kylix. Gambus
>keeps up with Distros however, while the QT 2.0 based CLX of Kylix, does
>not.
>

Agree. It looks really good. Why is it Basic??????

I would suspect because they are targeting the Visual Basic crowd. Not a bad

idea, since this would cover the majority of the Windows developer market.
Why someone doesn't create a similar INTEGRATED IDE for C++ is beyond me.
KDeveloper is pretty good, but it also weak in several areas. QT Designer
is a step in the right direction, but doesn't go far enough.
I do join others in bemouning the fact that Borland did not do Kylix right
(Would not fix bugs, would not keep it up to date, would not allow us to
bind it to newer QT components, etc). I wish they would open source it and
let the OS community make it shine.

R.F. Pels

kylix Developer

2004-02-13 04:53:22 AM

Re:The Conclusion

pnichols wrote:

Quote

Why someone doesn't create a similar INTEGRATED IDE for C++ is beyond me.
KDeveloper is pretty good, but it also weak in several areas. QT Designer
is a step in the right direction, but doesn't go far enough.
Then why doesn't Borland create the killer kpart that really makes kdevelop

a GUI RAD environment, I ask you... I would want them to do that. Borland
shines in that respect. They know how to do on-the-fly code generation. For
the rest, almost everything else is already in kdevelop as it is now:
multiple language support, automake support, makefile support, code
insight, etcetera, etcetera.

Quote

I do join others in bemouning the fact that Borland did not do Kylix right
(Would not fix bugs, would not keep it up to date, would not allow us to
bind it to newer QT components, etc). I wish they would open source it and
let the OS community make it shine.
Hmmmm. Rip it apart, graft the ObjectPascal compiler on the gcc RTL backend,

extend gcc with the necessary C++ extensions, introduce C++ name mangling
to external references to functions, kpartify the GUI RAD stuff and create
a very thin VCL like layer in both languages to support design time
component stuff, and last-but-not-least rewrite the docs in DocBook.
--
Ruurd

pnichols

kylix Developer

2004-02-13 06:07:50 AM

Re:The Conclusion

R.F. Pels wrote:

Quote

pnichols wrote:

>Why someone doesn't create a similar INTEGRATED IDE for C++ is beyond me.
>KDeveloper is pretty good, but it also weak in several areas. QT Designer
>is a step in the right direction, but doesn't go far enough.

Then why doesn't Borland create the killer kpart that really makes
kdevelop a GUI RAD environment, I ask you... I would want them to do that.
Borland shines in that respect. They know how to do on-the-fly code
generation. For the rest, almost everything else is already in kdevelop as
it is now: multiple language support, automake support, makefile support,
code insight, etcetera, etcetera.

Hey you are preaching to the choir :)

Quote

Hmmmm. Rip it apart, graft the ObjectPascal compiler on the gcc RTL
backend, extend gcc with the necessary C++ extensions, introduce C++ name
mangling to external references to functions, kpartify the GUI RAD stuff
and create a very thin VCL like layer in both languages to support design
time component stuff, and last-but-not-least rewrite the docs in DocBook.

I do not really care if it is Pascal or C/C++... I think they are on the

right track with Builder X, but it is a baby project right now.
I certainly do not UNDERSTAND why in the world they would start out with a
PREVIEW of wxDesigner that is only accessible for those using WINDOWS. That
makes no sense, IMHO.

R.F. Pels

kylix Developer

2004-02-14 07:46:52 PM

Re:The Conclusion

pnichols wrote:

Quote

I do not really care if it is Pascal or C/C++... I think they are on the
right track with Builder X, but it is a baby project right now.
Hmmm. As a cross-platform development environment, yes, true.

Quote

I certainly do not UNDERSTAND why in the world they would start out with a
PREVIEW of wxDesigner that is only accessible for those using WINDOWS.
That makes no sense, IMHO.
What makes even less sense is the switch from Qt to wxWindows, IMHO. I'd

rather see dual support for Qt and GTK.
--
Ruurd

pnichols

kylix Developer

2004-02-15 05:27:00 AM

Re:The Conclusion

R.F. Pels wrote:

Quote

pnichols wrote:

>I certainly do not UNDERSTAND why in the world they would start out with
>a PREVIEW of wxDesigner that is only accessible for those using WINDOWS.
>That makes no sense, IMHO.

What makes even less sense is the switch from Qt to wxWindows, IMHO. I'd
rather see dual support for Qt and GTK.

I agree. Actually, you could do both, but it would require QT Designer and

then using the designer files as you would on say KDeevelop, so that would
not seem to make it more attractive than say KDevelop.

R.F. Pels

kylix Developer

2004-02-15 08:13:46 AM

Re:The Conclusion

pnichols wrote:

Quote

R.F. Pels wrote:

>pnichols wrote:
>
>>I certainly do not UNDERSTAND why in the world they would start out with
>>a PREVIEW of wxDesigner that is only accessible for those using WINDOWS.
>>That makes no sense, IMHO.
>
>What makes even less sense is the switch from Qt to wxWindows, IMHO. I'd
>rather see dual support for Qt and GTK.
>
I agree. Actually, you could do both, but it would require QT Designer and
then using the designer files as you would on say KDeevelop, so that would
not seem to make it more attractive than say KDevelop.
You know, this whole business boils down to the fact that I would like to

see a kpartified/OLEfied designer that manages to write code for the major
desktop libraries available:
Win32
NotDead
Qt
GTK
wxWindows
in such a fashion that I can plug in other code generators I write myself.
Hell, that even could mean that if they use the proper patterns that it
would be possible to generate the Win32 code on a Linux box. Just check out
the stuff on a Windoes box and compile only the Windows specific stuff.
Proper application of the Decorator pattern I would guess would do wonders.
And the whole thing would even become better if they could manage this
without compiler extensions...
--
Ruurd

Peter Agricola

kylix Developer

2004-02-16 03:32:10 PM

Re:The Conclusion

"R.F. Pels" wrote:

Quote

You know, this whole business boils down to the fact that I would like to
see a kpartified/OLEfied designer that manages to write code for the major
desktop libraries available:

Win32
NotDead
Qt
GTK
wxWindows

in such a fashion that I can plug in other code generators I write myself.
Hell, that even could mean that if they use the proper patterns that it
would be possible to generate the Win32 code on a Linux box. Just check
out
the stuff on a Windoes box and compile only the Windows specific stuff.
Proper application of the Decorator pattern I would guess would do
wonders.

Who knows? CBX is supposed to be framework agnostic.

Quote

And the whole thing would even become better if they could manage this
without compiler extensions...
Who knows. Stroustrup is working on a C++ reflection system. The problem is

NotDead. This doesn't understand C++.
Peter