Board index » kylix » Re: Cross Platform Development

Re: Cross Platform Development


2005-07-29 07:50:52 PM
kylix2
Hello.
The buggest problem of the writing Cross-Platfom code is to get rich GUI on
the different platforms.
The RTL it is not, as i think. This can be C++ or Pascal it is not so
important.
The one of the ways to create portable GUI is to use DINO (Gecko-Delphi
Framework).
www.kamasoftware.com/gdfoverview.php
No Qt, No VCL, No CLX. All GUI is describe as XML(XUL) and building on Linux
and Windows.
The application is looks like Netscape/Mozilla clons. As example look at the
application writing with DINO - HelpExplorer.
www.kamasoftware.com/gdfscreenshots.php
Dmitry
"Robby Tanner" < XXXX@XXXXX.COM >wrote in message
Quote
Hi there,

I know this has been debated before but I need a review (pointers for
further reading more than welcome).

With Kylix up in the air, what are the current options for Linux/Win32
development? I'm just looking at the CrossKylix website right now. Are
there other methods folks would care to comment on?

Regards,
Rob


 
 

Re:Re: Cross Platform Development

Quote
As I suppose he wants to find an RAD environment to write
"Delphi-language", you can add

- Chrome (They seem to claim claim it works professionally: development
in Windows using Microsoft's IDE "Visual Studio", create .NET
assemblies that run under Microsoft .NET on Windows, Mono on Windows and
Linux, and compact .NET framework on Windows CE.
You are right, I forgot about that. Chrome definately would be another route.
Of course with this route you have to live without VCL/CLX, and use the
..net classes directly.
Simon
 

Re:Re: Cross Platform Development

Quote
>I guess to give you a decent advice we'd need more info on what kind of
>applications
>you are after.

A variety actually. Servers, GUI clients, DB-aware, controls systems, etc,
etc.

Where does FreeCLX fit in to all this?
FreeCLX simply is going to be an updated CLX version with VCL compatibility
improved. It will work transparently with Delphi, Kylix, CrossKylix and
CrossFPC. It is not required for any of the platforms, but it will be an added
benefit for all of these.
What this means is: Whatever the future of Kylix might be, going the VCL/CLX
route will be safe, as there will be several compatible paths to take your
project to, with very high source compatiblity.
Simon
 

{smallsort}

Re:Re: Cross Platform Development

Quote
>Sadly I've been very busy with commercial projects during the last 2 month,

Sadly? Congratulations, Simon, you're making money! Something we all
hope to do!
Thanks ;)
Quote
I think it's amazing you work so {*word*156} this project you donate to us as
it is.
Well, as stated earlier my commercial future depends on the future of Delphi-Linux
target, so I'm doing this out of self-interest ;)
Also a lot of the work is done by other individuals/projects. For example CrossFPC
more or less is a simplified FPC distribution that automatically sets up Cross-
compilation and adds a thin compatibilty layer, plus the IDE integration. The main
work of course is done by the FPC team, doing a great job providing most of the
toolchain.
All in all what I'm trying to achieve is to simply bundle the best of the existing
seperate projects together to provide an easy and stable future path for Kylix
users.
Simon
 

Re:Re: Cross Platform Development

Quote
"Robby Tanner" < XXXX@XXXXX.COM >
>Either one, I guess. I'm a Delphi programmer pre{*word*109}ly, but if
>cross-platform means getting in to C++, I'll head that direction.
>
>C++ has a lot of things to offer so it wouldn't be such a bad thing to get
>in to.

I recommend C++ for cross-platform development. I'm switched on the C++
after Kylix failure. C++/STL/BOOST for console program development. Add here
Qt for GUI, and OCL for Oracle connectivity.
If you don't care about the language switch this might be the option. However,
this also has major drawbacks.
First of all, I wouldn't want to deploy QT apps for Windows. Windows applications
should have a native GUI. Using VCL/CLX as abstraction layer helps a lot here.
Also, I'd really miss the infrastructure Borland provides. Using dbexpress I
get database support for each and any database system on the market with a
standardized interface.
Besides that I highly prefer Pascal of C++. And I don't feel like spending
an hour to build a project on the console with gcc-build, when I'm able to
build my application inside a nice IDE in seconds in Delphi/Kylix/CrossKylix.
Simon
 

Re:Re: Cross Platform Development

Dmitry wrote:
Quote
Hello, why this technique doesn't works for Qt4? Can you share more
details?
The Qt3 for Kylix code was generared by the Qt# generator which I modified
a lot. It uses doxygen for parsing C++ files what is not bad but
unfortunatelly it is limited to doxygen 3.6 (we are now at 1.4x) and it
does a lot thing on demand (finding out if a method is overloaded,
virtual, override, ...). On the other had using doxygen limits you to one
directory structure. But Qt4 has QtCode, QtGui, QtXml, ... and the most
hurting one Qt3support. This causes types/function to be duplicated and
the hash tables in CGen (the Qt# generator) stops with an excpetion.
Furthermore it is not possible to add further APIs that are based on
another API like QtGui requires QtCore.
My new attempt still uses doxygen (writing a C++ parser is not that easy
and doxygen 1.41 returns good results). But it allows you to plug in
further depending APIs like QtGUI based on QtCore and then KDE4Lib. It
should also work with Qt3.
At the moment the new tool reads the xml files of doxygen and I'm
currently writing a framework that allows an easier usage of the
information (all symbols are resolved). So I'm at step 2 of 4 (1:read xml,
2:convert to internal data structs, 3:generate C++ wrapper files,
4:generate Delphi import unit)
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
(andy.jgknet.de/blog)
 

Re:Re: Cross Platform Development

Quote
The one of the ways to create portable GUI is to use DINO (Gecko-Delphi
Framework).
www.kamasoftware.com/gdfoverview.php
No Qt, No VCL, No CLX. All GUI is describe as XML(XUL) and building on Linux
and Windows.
The application is looks like Netscape/Mozilla clons. As example look at the
application writing with DINO - HelpExplorer.
www.kamasoftware.com/gdfscreenshots.php
While this is an interesting project, its website leaves me with a lot of questions:
- How about deployment? How is the gecko engine deployed? What versions are supported?
What are the terms of gecko redistribution?
- Do they provide sources of their framework?
- Who are the authors? Why haven't we heard of them? They don't seem to be
part of any of the various Kylix projects. They don't seem to post here.
It should be in there best interest to for example provide CrossKylix support
for their product.
- Is this thing still developed? Last site update is from last year, there are no
Forums to see if a developer community exists.
Point is: If you base your applications on a framework, you need to be able to trust in
it, it needs to be future-proof. If it's a commercial offering, then it needs to be
from a stable, known company (and as we know from Borland, this also doesn't always
give you enough security, sigh). If it's a community project, the team behind it should
look stable. And well, ideally it should be open source, so that in a worst-case scenerio
(the project dies) you are able to take over and maintain it yourself.
That's why I'm currently betting on the Kylix/CrossKylix/CrossFPC route. If Borland
decides to one day uptime Kylix, my applications will be fine. If they decide not to,
CrossFPC gives me a second layer of security. As the FPC project is going on for years
already, this looks pretty stable. And if FPC one day dies, it's open source and I'm
still able to secure the future of my Applications myself.
Simon
 

Re:Re: Cross Platform Development

Jonathan Benedicto wrote:
Quote
I'm trying to build a cross-platform library, that will incorporate a
GUI system similar to the VCL.
I have started a project some time months ago to write a layer that allows
the VCL to be used unter Linux natively. For this I use the Mono-WinForms
code. But this project is far far away from being compileable. It is only
a test to see how nead Mono-WinForms comes to Win32API. For example
Mono-WinForms has the function
GetMessage/PeekMessage/TranslateMessage/DispatchMessage for X11.
I don't know if I will ever finish this VCL for Linux project because it
is only a project that shows me that it meight be possible.
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
(andy.jgknet.de/blog)
 

Re:Re: Cross Platform Development

I can't provide answer for all questions which you has to ask.
But some of the questions be able to resolve easy:
Quote
>- How about deployment?
I think the deployment of this framework is not deffer sharply from
deployment the DevExpress components for instance.
Quote
>How is the gecko engine deployed?
Gecko has no limits to deploy if you don't build your own version of it.
>What versions are supported?
The framework has xpidl2pas compiler and it is make it possible don't
depended from version of the GRE.
Quote
>What are the terms of gecko redistribution?
Goto Gecko web (www.mozilla.com) site and you will know :)
Quote
>Do they provide sources of their framework?
I don't know the components/frameworks for Delphi/Kilix for which the
sources is not available, only DCU.
Quote
>
Point is: If you base your applications on a framework, you need to be able
to trust in
it, it needs to be future-proof. If it's a commercial offering, then it
needs to be
from a stable, known company (and as we know from Borland, this also doesn't
always
give you enough security, sigh). If it's a community project, the team
behind it should
look stable. And well, ideally it should be open source, so that in a
worst-case scenerio
(the project dies) you are able to take over and maintain it yourself.
Quote
>
Agree with you.
Quote
>
That's why I'm currently betting on the Kylix/CrossKylix/CrossFPC route. If
Borland
decides to one day uptime Kylix, my applications will be fine. If they
decide not to,
CrossFPC gives me a second layer of security. As the FPC project is going on
for years
already, this looks pretty stable. And if FPC one day dies, it's open source
and I'm
still able to secure the future of my Applications myself.
Quote
>
If you have a 750BMW and the BMW factory is down and your gear-box is down
too, you
in theory can to produce spares by file but it is not possible as you
understand :))
So if your project is based on FPC and FPC is die, you project die too.
"Simon Kissel" < XXXX@XXXXX.COM >wrote in message
Quote
The one of the ways to create portable GUI is to use DINO (Gecko-Delphi
Framework).
www.kamasoftware.com/gdfoverview.php
No Qt, No VCL, No CLX. All GUI is describe as XML(XUL) and building on
Linux
and Windows.
The application is looks like Netscape/Mozilla clons. As example look at
the
application writing with DINO - HelpExplorer.
www.kamasoftware.com/gdfscreenshots.php
While this is an interesting project, its website leaves me with a lot of
questions:
- How about deployment? How is the gecko engine deployed? What versions are
supported?
What are the terms of gecko redistribution?
- Do they provide sources of their framework?
- Who are the authors? Why haven't we heard of them? They don't seem to be
part of any of the various Kylix projects. They don't seem to post here.
It should be in there best interest to for example provide CrossKylix
support
for their product.
- Is this thing still developed? Last site update is from last year, there
are no
Forums to see if a developer community exists.
Point is: If you base your applications on a framework, you need to be able
to trust in
it, it needs to be future-proof. If it's a commercial offering, then it
needs to be
from a stable, known company (and as we know from Borland, this also doesn't
always
give you enough security, sigh). If it's a community project, the team
behind it should
look stable. And well, ideally it should be open source, so that in a
worst-case scenerio
(the project dies) you are able to take over and maintain it yourself.
That's why I'm currently betting on the Kylix/CrossKylix/CrossFPC route. If
Borland
decides to one day uptime Kylix, my applications will be fine. If they
decide not to,
CrossFPC gives me a second layer of security. As the FPC project is going on
for years
already, this looks pretty stable. And if FPC one day dies, it's open source
and I'm
still able to secure the future of my Applications myself.
Simon
 

Re:Re: Cross Platform Development

"Andreas Hausladen" < XXXX@XXXXX.COM >wrote in message
Quote
I will not shorten your hope but you cannot simply import a C++ class
into
a Pascal program. For this you must flatten the C++ class (C++ wrapper).
And that is a lot of work as you can see how long it has taken until I
could make the first release of Qt3 for Kylix. And the worst thing is
that
this technique doesn't work for Qt4 anymore. So I'm currently writing a
new conversion tool. (this time in Delphi not C#).
When you say "flatten", do you mean it must be redone into C ? Eg:
class Test
{
public:
Test();
void One();
void Two();
};
Must become something like:
void Test_Test();
void Test_One();
void Test_Two();
Jonathan
 

Re:Re: Cross Platform Development

"Andreas Hausladen" < XXXX@XXXXX.COM >wrote in message
Quote
I have started a project some time months ago to write a layer that
allows
the VCL to be used unter Linux natively. For this I use the Mono-WinForms
code. But this project is far far away from being compileable. It is only
a test to see how nead Mono-WinForms comes to Win32API. For example
Mono-WinForms has the function
GetMessage/PeekMessage/TranslateMessage/DispatchMessage for X11.
I don't know if I will ever finish this VCL for Linux project because it
is only a project that shows me that it meight be possible.
I have been thinking about making my library a open-source LGPL or Mozilla
licenced project on SF. If I can get developers to agree with my ideas. <g>
Jonathan
 

Re:Re: Cross Platform Development

"Andreas Hausladen" < XXXX@XXXXX.COM >wrote in message
Quote
I will not shorten your hope but you cannot simply import a C++ class
into
a Pascal program. For this you must flatten the C++ class (C++ wrapper).
And that is a lot of work as you can see how long it has taken until I
could make the first release of Qt3 for Kylix. And the worst thing is
that
this technique doesn't work for Qt4 anymore. So I'm currently writing a
new conversion tool. (this time in Delphi not C#).
PS. <g>When I said a shared library, I meant, under Windows .dll, under
Linux .so, that has been compiled in C++. The library is written in C++,
but so that Pascal can use it, I make an import library, and a Pascal
header file.
I thought that all one needed to do is this. My library exports a "extern
C" Application function, that returns a pointer to the application instance
class created by another "extern C" CreateApplication function.
I had to do this so that the library would work across c++ compilers.
I'm afraid that I'm completely ignorant when it comes to Pascal.
Jonathan
 

Re:Re: Cross Platform Development

Jonathan Benedicto wrote:
Quote
Must become something like:

void Test_Test();
void Test_One();
void Test_Two();
You must do all the things the compiler does for you:
# void Test::Test();
must become something like:
# Test* Test_Test() { return new Test(); }
And methods must become this:
# int Test_getValue(Test* t) { return t->getValue(); }
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
(andy.jgknet.de/blog)
 

Re:Re: Cross Platform Development

"Andreas Hausladen" < XXXX@XXXXX.COM >wrote in message
Quote
You must do all the things the compiler does for you:
# void Test::Test();
must become something like:
# Test* Test_Test() { return new Test(); }

And methods must become this:
# int Test_getValue(Test* t) { return t->getValue(); }
So I would have to make the library export all these a extern "c"
functions, then I'd have to write Pascal "wrapper" classes ?
Jonathan
 

Re:Re: Cross Platform Development

Quote
At the moment the new tool reads the xml files of doxygen and I'm
currently writing a framework that allows an easier usage of the
information (all symbols are resolved). So I'm at step 2 of 4 (1:read xml,
2:convert to internal data structs, 3:generate C++ wrapper files,
4:generate Delphi import unit)
If i right undestand your tool, in theory, make it possible to port ANY C++
Framework to flat API and it
will may use in Delphi-Kylix? If it so, that is create!
"Andreas Hausladen" < XXXX@XXXXX.COM >wrote in message
Quote
Dmitry wrote:

>Hello, why this technique doesn't works for Qt4? Can you share more
>details?

The Qt3 for Kylix code was generared by the Qt# generator which I modified
a lot. It uses doxygen for parsing C++ files what is not bad but
unfortunatelly it is limited to doxygen 3.6 (we are now at 1.4x) and it
does a lot thing on demand (finding out if a method is overloaded,
virtual, override, ...). On the other had using doxygen limits you to one
directory structure. But Qt4 has QtCode, QtGui, QtXml, ... and the most
hurting one Qt3support. This causes types/function to be duplicated and
the hash tables in CGen (the Qt# generator) stops with an excpetion.
Furthermore it is not possible to add further APIs that are based on
another API like QtGui requires QtCore.

My new attempt still uses doxygen (writing a C++ parser is not that easy
and doxygen 1.41 returns good results). But it allows you to plug in
further depending APIs like QtGUI based on QtCore and then KDE4Lib. It
should also work with Qt3.
At the moment the new tool reads the xml files of doxygen and I'm
currently writing a framework that allows an easier usage of the
information (all symbols are resolved). So I'm at step 2 of 4 (1:read xml,
2:convert to internal data structs, 3:generate C++ wrapper files,
4:generate Delphi import unit)

--
Regards,

Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
(andy.jgknet.de/blog)