Board index » kylix » Re: Kylix - to be or not to be

Re: Kylix - to be or not to be


2003-11-08 02:25:55 AM
kylix0
RADU wrote:
Quote
We also could do smth. that Borland never did (in the last 2 years, at
least): we could "sponsor" a company or private person (AH perhaps, if
he's interested, of course)
No, please do not do that with me. I will help writing a Qt 3 wrapper but
I will not be payed for it because then I'm forced to write it as fast as
possible. But I have not that time to do that.
I think the qtintf70.dll is very usefull under Windows. And with theming
it looks very well.
Under Linux a Qt 3 support is needed because of antialised fonts, theming
and compatibiliy.
What is the problem with Qt 3 license under Linux? It is GPL/QPL. Kylix's
VisualCLX is GPL, too. And with the RTL from the FreeCLX project we have a
complete GPL'ed Kylix environment. (Where is my fault if any?). For
commercial application Qt should be LGPL'ed or another license. But
unfortunately it is not LGPL'ed.
For Qt 3 bindings I have a technique that makes it possible to dynamically
link against libqtmt.so directly without any C++->C wrapper shared object.
--
Regards
Andreas Hausladen
(www.kylix-patch.de.vu unofficial VisualCLX patches)
 
 

Re:Re: Kylix - to be or not to be

Andreas Hausladen wrote:
Quote
...I will help writing a Qt 3 wrapper...

For Qt 3 bindings I have a technique that makes it possible to dynamically
link against libqtmt.so directly without any C++->C wrapper shared object.

REALLY???
How does this work?
How can I contribute? When do we start? ;-)
How much time will it take?
Theo
 

Re:Re: Kylix - to be or not to be

Quote
What is the problem with Qt 3 license under Linux? It is GPL/QPL. Kylix's
VisualCLX is GPL, too.
Not true; Actually it's a dual license: GPL for the open source version of
Kylix plus a "no nonsense" license for Kylix prof./enterprise. Even the
FreeCLX has this dual license. (Which is good)
Quote
And with the RTL from the FreeCLX project we have a
complete GPL'ed Kylix environment. (Where is my fault if any?).
If you release a Qt 3.2 binding that is based on the GPLed Qt3/X11 lib, I
won't touch it, as everything else would have to be GPLed. Even the Kylix
IDE, if you link it to the free lib: What about all those IDE-Experts and
desgin time packages you need? Do we have to source for the IDE or am I
missing something here?
A compromise would be to make the QT 3.2 interface dual licensed (MPL/GPL or
LGPL/GPL or ...), so that with a commercial Qt license it would be possible
to make 'closed' source or non GPLed applications. But I'm no lawyer, so I
can not tell if this dual license thing would be "legal" - especially
combined with the Qt/X11 GPL version.
Only problem is, that Borland would probably have to change the FreeCLX
license too. But the (e.g.) LGPL should be acceptable. Especially as Kylix
(CLX) seems to be pretty dead now...
Honestly, I haven't bought Kylix (Prof.; 1,2 and 3) just to be able to
develop GPLed applications! Yes, I want to do some open source projects with
Kylix too, but in fact I favour MPL or LGPL for that purpose.
(www.dwscript.com and www.sf.net/projects/arkadios )
Quote
For
commercial application Qt should be LGPL'ed or another license. But
unfortunately it is not LGPL'ed.
Yes, because Trolltech wants to make money..
Quote
For Qt 3 bindings I have a technique that makes it possible to dynamically
link against libqtmt.so directly without any C++->C wrapper shared object.
Interesting.
Willi
 

{smallsort}

Re:Re: Kylix - to be or not to be

Andreas Hausladen wrote:
Quote

No, please do not do that with me. I will help writing a Qt 3 wrapper but
I will not be payed for it because then I'm forced to write it as fast as
possible. But I have not that time to do that.
OK. If you insist ... you won't get payed. Just kidding...

I think the qtintf70.dll is very usefull under Windows. And with theming
it looks very well.
Under Linux a Qt 3 support is needed because of antialised fonts, theming
and compatibiliy.


What is the problem with Qt 3 license under Linux? It is GPL/QPL. Kylix's
VisualCLX is GPL, too. And with the RTL from the FreeCLX project we have a
complete GPL'ed Kylix environment. (Where is my fault if any?). For
commercial application Qt should be LGPL'ed or another license. But
unfortunately it is not LGPL'ed.
That's exactly what most Linux guys would need...One can also buy a
commercial license for Linux-QT but this won't work either because of
the FreeClx (released under GPL).
Quote


For Qt 3 bindings I have a technique that makes it possible to dynamically
link against libqtmt.so directly without any C++->C wrapper shared object.

Will you post it (the solution) on your site?
Thank you very much,
(and again)
Very well done!
Regards
RADU
 

Re:Re: Kylix - to be or not to be

theo wrote:
Quote
REALLY???
How does this work?
I have a program that parses all symbols from "readelf -s -w qtlibmt.so"
and compare it with "readelf -s -w qtlibmt.so | c++filt". Then it
generates a unit that contains lines like this:
I have posted this technique some time ago in this newsgroup (thread:
"will k4 be kde based".
class TBase {
public:
TBase();
virtual ~TBase();
};
class TDerived: public TBase {
private:
int value;
public:
virtual int getValue() const;
};
TBase::TBase() {}
TBase::~TBase() {}
int TDerived::getValue() const { return value; }
extern "C" {
TDerived* getDerived() { return new TDerived(); }
int getValue(TDerived* v) { return v->getValue(); }
void destroyBase(TBase* b) { delete b; }
}
------------------------------------------
gcc -shared test.cc -o test.so.1.0
------------------------------------------
program Test;
// gcc 3.x ABI
uses
GccClassHlp, SymbolImport_test_so_1_0;
type
TBase = class(TGccClassHelper)
private
procedure _Create; cdecl;
protected
procedure _DestroyD1; virtual; cdecl; // stack based delete
procedure _DestroyD0; virtual; cdecl; // heap based delete
class function GccInfo: TGccClassInfo; override;
public
constructor Create;
end;
TDerived = class(TBase)
private
procedure _Create; cdecl;
protected
value: Integer;
class function GccInfo: TGccClassInfo; override;
public
constructor Create;
function getValue: Integer; virtual; cdecl;
end;
// derive a Delphi class from TDerived
TMyDerived = class(TDerived)
private
FMeinWert: Integer;
public
constructor Create(AValue: Integer);
destructor Destroy; override;
function getValue: Integer; override;
end;
procedure TBase._Create; external TestLib name TBase__TBase_1;
procedure TBase._DestroyD1; external TestLib name TBase_x_TBase_1;
procedure TBase._DestroyD0; external TestLib name TBase_x_TBase_2;
procedure TDerived._Create; external TestLib name TDerived__TDerived;
function TDerived.getValue; external TestLib name TDerived__getValue;
// global function
function getValue(v: TDerived): Integer; cdecl; external TestLib;
function getDerived: TDerived; cdecl; external TestLib;
procedure destroyBase(b: TBase); cdecl; external TestLib;
{ TBase }
constructor TBase.Create;
begin
GccCreate; // returns a interface
_Create;
end;
class function TBase.GccInfo: TGccClassInfo;
begin
Result := GccClass_TBase;
end;
{ TDerived }
constructor TDerived.Create;
begin
GccCreate;
_Create;
end;
class function TDerived.GccInfo: TGccClassInfo;
begin
Result := GccClass_TDerived;
end;
{ TMyDerived }
constructor TMyDerived.Create(AValue: Integer);
begin
inherited Create;
FMeinWert := AValue;
end;
destructor TMyDerived.Destroy;
begin
WriteLn('I was here. Press ENTER to quit.');
ReadLn;
inherited Destroy;
end;
function TMyDerived.getValue: Integer;
begin
Result := FMeinWert;
end;
procedure Test2;
var v: TDerived;
begin
// TBase.Gcc.Register;
TDerived.Gcc.Register; // registers TBase automatically
{ Create instance by gcc code and free by Delphi code. }
v := getDerived;
try
WriteLn(getValue(v));
finally
v.Free;
end;
{ Create instance by Delphi code and free by gcc code. }
v := TMyDerived.Create;
try
WriteLn(getValue(v));
finally
destroyBase(v);
end;
{ Create instance by Delphi code and free by Delphi code. }
v := TDerived.Create;
try
WriteLn(v.getValue);
finally
v.Free;
end;
{ Create instance by gcc code and free by gcc code. }
v := getDerived;
try
WriteLn(v.getValue);
finally
destroyBase(v);
end;
end;
begin
Test2;
end.
-----------------------------------------------------------
{ Do not edit this file it is auto generated by SOSymbolImporter 0.2 }
uses SymbolImport_test_so_1_0;
interface
uses
GccClassHlp;
const
TestLib = '/home/andy/kylix/gcc/t2/test.so.1.0';
GccClass_TBase: TGccClassInfo = (
LibName: TestLib;
ClassName: 'TBase';
);
symTBase__TBase = '_ZN5TBaseC1Ev';
symTBase__TBase_2 = '_ZN5TBaseC2Ev';
symTBase_x_TBase = '_ZN5TBaseD0Ev';
symTBase_x_TBase_2 = '_ZN5TBaseD1Ev';
symTBase_x_TBase_3 = '_ZN5TBaseD2Ev';
GccClass_TDerived: TGccClassInfo = (
LibName: TestLib;
ClassName: 'TDerived';
);
symTDerived__TDerived = '_ZN8TDerivedC1Ev';
symTDerived__TDerived_2 = '_ZN8TDerivedC0Ev';
symTDerived_x_TDerived = '_ZN8TDerivedD0Ev';
symTDerived_x_TDerived_2 = '_ZN8TDerivedD1Ev';
symTDerived_x_TDerived_3 = '_ZN8TDerivedD2Ev';
symTDerived__getValue = '_ZNK8TDerived8getValueEv';
implementation
end.
---------------------------------------
Quote
How can I contribute? When do we start? ;-)
How much time will it take?
This will take a lot of time. All inline and macros must be rewritten in
Delphi. And there is no autogenerate tool for the classes and functions.
--
Regards
Andreas Hausladen
(www.kylix-patch.de.vu unofficial VisualCLX patches)
 

Re:Re: Kylix - to be or not to be

Willibald Krenn wrote:
Quote
Honestly, I haven't bought Kylix (Prof.; 1,2 and 3) just to be able to
develop GPLed applications! Yes, I want to do some open source projects
with Kylix too, but in fact I favour MPL or LGPL for that purpose.
What we need is a widget framework that can be used for closed code, too.
Perhaps something like lptk.sourceforge.net/ could be used as a
"lowlevel" widget framework under the CLX.
--
Regards
Andreas Hausladen
(www.kylix-patch.de.vu unofficial VisualCLX patches)
 

Re:Re: Kylix - to be or not to be

For wxWindows I found the wx.NET sub project
(wxnet.sourceforge.net/). This project generates C++->C wrapper
dlls. Maybe this is some work that had to be done for Kylix, too. I think
it would be easier to modify the wx.NET source files to compile with gcc
and then write a binding unit for Kylix.
This does not mean that I will do this job.
--
Regards
Andreas Hausladen
(www.kylix-patch.de.vu unofficial VisualCLX patches)
 

Re:Re: Kylix - to be or not to be

Quote

This will take a lot of time. All inline and macros must be rewritten in
Delphi. And there is no autogenerate tool for the classes and functions.

What do you think? Is it just a dream or can we make it to v 0.1 for
christmas? ;-)
Theo
 

Re:Re: Kylix - to be or not to be

theo wrote:
Quote
What do you think? Is it just a dream or can we make it to v 0.1 for
christmas? ;-)
If we work on this as a full time job, it may be possible. The other
possibility would be to write autogenerating tools. But here the C++
syntax is a pain with it's templates and macros.
--
Regards
Andreas Hausladen
(www.kylix-patch.de.vu unofficial VisualCLX patches)
 

Re:Re: Kylix - to be or not to be

And here another problem:
If the Qt 3.x have interface changes in the ".x" we must rewrite the
classes. Updating a wrapper C shared object would be easier.
--
Regards
Andreas Hausladen
(www.kylix-patch.de.vu unofficial VisualCLX patches)
 

Re:Re: Kylix - to be or not to be

Andreas Hausladen wrote:
Quote
And here another problem:
If the Qt 3.x have interface changes in the ".x" we must rewrite the
classes. Updating a wrapper C shared object would be easier.

I understand.
I'm new to this matter but willing to help.
It's no question that you are the Guru.
Where would you start?
Here? cvs.sourceforge.net/viewcvs.py/freeclx/freeclx/qt/
Do you have a full understanding of how this was done?
Theo
 

Re:Re: Kylix - to be or not to be

theo wrote:
Quote
Where would you start?
Here? cvs.sourceforge.net/viewcvs.py/freeclx/freeclx/qt/
Do you have a full understanding of how this was done?
I don't know how they build the libqtintf.so file. I think this is a job
for a C++ programmer.
--
Regards
Andreas Hausladen
(www.kylix-patch.de.vu unofficial VisualCLX patches)
 

Re:Re: Kylix - to be or not to be

Quote
For wxWindows I found the wx.NET sub project
(wxnet.sourceforge.net/). This project generates C++->C wrapper
dlls. Maybe this is some work that had to be done for Kylix, too. I think
it would be easier to modify the wx.NET source files to compile with gcc
and then write a binding unit for Kylix.
This does not mean that I will do this job.
Well, none of us will probably do this.
As I understand it, you'll eventually make the Qt 3.x binding. Given that
all the components will be GPL based, how do you want to integrate it in the
Kylix IDE?
I mean all the designtime packages will be covered by the GPL and the Kylix
IDE will load and use these packages. As I understand it, the GPL forces you
to distribute the Kylix IDE under the GPL too! So what do you plan to do
about this? Or am I misunderstanding here something..
Willi
 

Re:Re: Kylix - to be or not to be

Willibald Krenn wrote:
Quote
As I understand it, you'll eventually make the Qt 3.x binding.
No. I will not do this. Maybe I will help the team doing this.
Quote
Given that all the components will be GPL based, how do you want to
integrate it in
the Kylix IDE?
I mean all the designtime packages will be covered by the GPL and the
Kylix IDE will load and use these packages. As I understand it, the GPL
forces you to distribute the Kylix IDE under the GPL too! So what do you
plan to do about this? Or am I misunderstanding here something..
The IDE packages may not be modified (as done by the unofficial vclx
patch). The IDE should use the original libborqt.so but the programs
produced by Kylix should bind to Qt 3.
--
Regards
Andreas Hausladen
(www.kylix-patch.de.vu unofficial VisualCLX patches)
 

Re:Re: Kylix - to be or not to be

Quote
>As I understand it, you'll eventually make the Qt 3.x binding.

No. I will not do this. Maybe I will help the team doing this.
Of course :-)
Quote
The IDE packages may not be modified (as done by the unofficial vclx
patch). The IDE should use the original libborqt.so but the programs
produced by Kylix should bind to Qt 3.
I understand. Unfortunately that makes RAD like development with new Qt3
classes/objects very difficult.. (nice understatement, isn't it?)
Anyhow - good luck with this project and thanks for your great work on
fixing Kylix bugs. Perhaps I can contribute something in future,
Willi