Board index » kylix » will k4 be kde based?

will k4 be kde based?


2003-07-30 08:11:55 PM
kylix1
It is clear now that when Borland chosen Qt as the ba{*word*224}t for VisualCLX
they did a mistake.
Political/market review:
Might have made sense at the time of the Kylix 1 announcement, but not
anymore: did you notice that all the new desktop oriented distributions are
KDE based? You can disagree with me, but I think Gnome is going niche now.
It has only a ~25% use as a desktop use now, KDE takes the lions part, and
the other GUIs fill the rest (they were always niche GUIs and now they are
only used to be able to run a GUI on old machines). Even RedHat needed to
approach to the KDE camp: BlueCurve. Of course, they can't simply go KDE and
instantaneously forget the past, this is just the first step.
Technical review:
Who uses Delphi with Qt (VisualCLX over Windows)? No one does, we all use
VCL on Windows and CLX (no other choise available) on Linux, coupled with
some "nice" IFDEFs. We integrate poorly with the rest of the GUI (did you
try to build a KPart with Kylix?). We have to drag those
special-qt-libs-for-kylix everywhere...
It seems that Kylix 4 it's not in the near future. I hope that when it
finally appears it will have solved the issues that made it fail until now,
and between them this one.
Just my 2 cents... What do you think? Do you agree or am I wrong?
K.M.
 
 

Re:will k4 be kde based?

<K.M.>wrote:
Quote
It is clear now that when Borland chosen Qt as the ba{*word*224}t for VisualCLX
they did a mistake.
The KDE classes are derived from Qt classes.
With Qt 3.1 (gcc 3.x compiled) it is possible to translate the Qt and KDE
headers to Delphi language. OK it is not easy but possible.
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu unofficial VisualCLX patches)
 

Re:will k4 be kde based?

Quote
I also don't see why a KDE based
Kylix would be superior to a plain QT based Kylix.

If you want a succesful desktop app you need one that interacts nicely with
the environment (KDE) and the rest of the apps. Your app should use the
standard services that the environment offers: the standard file
open/save/copy dialogs, standard url interpretation (kio slaves), standard
look and feel, you need to support kparts, for example to embed konqueror
for web-browsing (instead of mozilla as Kylix does!), etc, etc, etc.
Not having that, means that there are a whole range of apps that cannot be
build using Kylix.
E.B.
 

{smallsort}

Re:will k4 be kde based?

<K.M.>wrote:
Quote
>I also don't see why a KDE based
>Kylix would be superior to a plain QT based Kylix.

If you want a succesful desktop app you need one that interacts nicely
with the environment (KDE) and the rest of the apps. Your app should use
the standard services that the environment offers: the standard file
open/save/copy dialogs, standard url interpretation (kio slaves), standard
look and feel, you need to support kparts, for example to embed konqueror
for web-browsing (instead of mozilla as Kylix does!), etc, etc, etc.
Well, then you might also loose portability (one of the major points of
Kylix). IMO one should not be forced to write a KDE application but maybe
have the option to do so (though I wouldn't use it).
Felix
 

Re:will k4 be kde based?

Felix E. Klee wrote:
Quote
But then you need to write an additional C interface because, as you
surely know, a gcc built QT is not ABI compatible with Kylix. When using
C++ you can use my Kylix QT Port
No I meant that I can import gcc 3.2 generated classes directly into Kylix
Delphi. No C wrapper shared object. The following code is just my first
"Delphi wapper". It is a start but not the end of simple wrapper.
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
------------------------------------------
------------------------------------------
unit SymbolImport_test_so;
interface
{ I've modified the file }
// Auto generated by SOSymbolImporter 0.1 do not edit.
const
TestLib = '/home/andy/kylix/gcc/t2/test.so.1.0';
const
TBase__TBase_1 = '_ZN5TBaseC1Ev'; // TBase::TBase()
TBase_x_TBase_1 = '_ZN5TBaseD1Ev'; // TBase::~TBase()
TBase_x_TBase_2 = '_ZN5TBaseD0Ev'; // TBase::~TBase()
TDerived__TDerived = '_ZN8TDerivedC1Ev'; // TDerived::TDerived()
TDerived__getValue = '_ZNK8TDerived8getValueEv'; // TDerived::getValue()
implementation
end;
------------------------------------------
program Test
{$APPTYPE CONSOLE}
uses Libc, SysUtils, SymbolImport_test_so;
type
TPointerArray = array[0..65535] of procedure(Self: Pointer); cdecl;
PVMT = ^TVMT;
TVMT = packed record Items: TPointerArray; end;
function GetVMT(Self: Pointer): PVMT; asm mov eax, [eax]; end;
procedure SetVMT(Self, VMT: Pointer); asm mov [eax], edx; end;
type
TDefaultConstructor = procedure of object; cdecl;
TBase = class
private
procedure _Create; cdecl; // gcc constructor
protected
procedure _DestroyD1; virtual; cdecl; // stack based delete
procedure _DestroyD0; virtual; cdecl; // heap based delete
constructor GccCreate(DefaultConstructor: TDefaultConstructor);
public
constructor Create;
destructor Destroy; override;
procedure Free;
end;
TDerived = class(TBase)
protected
value: Integer;
procedure _Create; cdecl;
public
function getValue: Integer; virtual; cdecl;
end;
// this is our derived class
TMyDerived = class(TDerived)
public
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;
function getValue(v: TDerived): Integer; cdecl; external TestLib;
function getDerived: TDerived; cdecl; external TestLib;
function destroyBase(b: TBase): TDerived; cdecl; external TestLib;
constructor TBase.GccCreate(DefaultConstructor: TDefaultConstructor);
var MyVMT: PVMT;
begin
// gcc constructor sets its VMT so we restore our
MyVMT := GetVMT(Self);
try
DefaultConstructor;
finally
SetVMT(Self, MyVMT);
end;
end;
constructor TBase.Create;
begin
GccCreate(_Create);
end;
destructor TBase.Destroy;
var MyVMT: PVMT;
begin
// gcc destructor restores its VMT. So we restore our
MyVMT := GetVMT(Self);
try
_DestroyD1; // stack based destroy;
finally
SetVMT(Self, MyVMT);
end;
end;
procedure TBase.Free;
var Index: Integer;
begin
if Self <>nil then
begin
Index := -2; // Delphi: @FreeInstance | gcc: nil
if Assigned(GetVMT(Self)^.Items[Index]) then
Destroy
else
_DestroyD0; // heap based destroy;
end;
end;
procedure Test;
var v: TDerived;
begin
v := getDerived; // test.so creates a TDerived* instance
try
WriteLn(getValue(v)); // prints '0'
finally
v.Free; // Delphi's destructor
end;
v := TMyDerived.Create; // Delphi created instance
try
WriteLn(getValue(v)); // prints '100'
finally
destroyBase(v); // test.so destroys the instance.
end;
end;
function TMyDerived.getValue: Integer;
begin
Result := 100;
end;
begin
Test;
ReadLn;
end.
-------------------------------------------------------
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu unofficial VisualCLX patches)
 

Re:will k4 be kde based?

And here is a better code that uses a helper class.
program Test;
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;
TMyDerived = class(TDerived)
private
FMeinWert: Integer;
public
constructor Create(AValue: Integer);
destructor Destroy; override;
function getValue: Integer; override;
end;
{ TBase }
constructor TBase.Create;
begin
GccCreate;
_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.
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu unofficial VisualCLX patches)
 

Re:will k4 be kde based?

So you extract the symbol table with SOSymbolImporter 0.2 (which, I
suppose, you are the author of) so that you can interface with gcc
generated C++ libraries directly.
This looks like a very clever solution (I must admit that I don't
understand the code very well since I'm neither a Delphi programmer
nor do I know how the gcc 3.2 ABI for C++ libs is designed). I see that
you still have to write part of the C++-Delphi interface by hand. Do you
plan on automating that as well or would that be nearly impossible (e.g.
because there are too many differences between C++ and Delphi that are
better tackled by hand)?
Something similar could probably be forged to interface
with gcc C++ libraries from Kylix BCB but I don't know if that makes
much sense. It's probably easier to just wait for Kylix 4 (which
hopefully is ABI compatible with gcc 3.2) or try to compile
C++ libraries with Kylix BCB.
Felix
--
To contact me in private don't reply but send mail to
felix DOT klee AT inka DOT de
 

Re:will k4 be kde based?

Felix E. Klee wrote:
Quote
So you extract the symbol table with SOSymbolImporter 0.2 (which, I
suppose, you are the author of) so that you can interface with gcc
generated C++ libraries directly.
Yes I'm the author of this tool. But it is far far away from an ALPHA
version. And I have no time for it.
Quote
I see that you still have to write part of the C++-Delphi interface by
hand. Do you plan on automating that as well or would that be nearly
impossible (e.g. because there are too many differences between C++
and Delphi that are better tackled by hand)?
Yes I must convert the header files by hand. C++ syntax is to flexible
because of macros. Maybe the header files can be preprocessed before
parsing but this is still a lot of work to do.
Quote
Something similar could probably be forged to interface
with gcc C++ libraries from Kylix BCB but I don't know if that makes
much sense. It's probably easier to just wait for Kylix 4 (which
hopefully is ABI compatible with gcc 3.2) or try to compile
C++ libraries with Kylix BCB.
It is not really a usable code. I was just interested in the techniques.
--
Regards
Andreas Hausladen
(www.kylix-patch.de.vu unofficial VisualCLX patches)