As you've probably seen, we are interested in talking about a LOT of different idea's and subjects. If you'd like to start it out with your thoughts, feel free...

Shane

I have been lurking only for a few days, as is my norm when joining a new list.

But, I wanted to say that I joined the list in hopes of becoming a part of the project.

This project has the potential of becoming one of the hottest things in terms of development for the next few years. I mean that. If you looking at the directions things are developing and when other key elements are, this project will play a critical role is determining the viability of Linux and even Open Source in general. A solid (read "not like V.B.") RAD tool can make Linux a core platform for new development by developers.

When I say "developer", I mean someone who takes core elements and ties them together to make specific solutions. When I say "programmer", I mean someone who creates core elements.

Developers work at a higher level than "programmers". They need to be separated from the details a little to allow them to look at the problem.

Linux is a solid platform for "programming". There is a lot of support in this area. But there needs to be one good tool for "Developers" to rapidly tie the core elements together to make specific solutions. It would be nice if that tool also encouraged efficient programming (Like Delphi does).

Anyway, this project will open the doors to the Linux platform for people who only want to be developers. I believe that adding these developers to the Linux and Open Source communities will be a big benefit to Linux and Open Source in general. (IMHO). And, the quality of this project, will lend credibility to their presence.

Anyway, I believe this is a great project and hope to find a place in it! (returning to lurk mode for a few more days,...) :)

AMEN BROTHER! You are absolutely right!

Message text written by

I have been lurking only for a few days, as is my norm when joining a new

list.

But, I wanted to say that I joined the list in hopes of becoming a part of the project.

This project has the potential of becoming one of the hottest things in terms of development for the next few years. I mean that. If you looking at the directions things are developing and when other key elements are, this project will play a critical role is determining the viability of Linux and even Open Source in general. A solid (read "not like V.B.") RAD tool can make Linux a core platform for new development by developers.

When I say "developer", I mean someone who takes core elements and ties them
together to make specific solutions. When I say "programmer", I mean someone
who creates core elements.

Developers work at a higher level than "programmers". They need to be separated from the details a little to allow them to look at the problem.

Linux is a solid platform for "programming". There is a lot of support in this area. But there needs to be one good tool for "Developers" to rapidly tie the core elements together to make specific solutions. It would be nice if that tool also encouraged efficient programming (Like Delphi does).

Anyway, this project will open the doors to the Linux platform for people who only want to be developers. I believe that adding these developers to the Linux and Open Source communities will be a big benefit to Linux and Open Source in general. (IMHO). And, the quality of this project, will lend credibility to their presence.

Anyway, I believe this is a great project and hope to find a place in it! (returning to lurk mode for a few more days,...) :) <

Hello,

I've been following the recent thread where you've been discussing Java chances... I only would want to add that I find odd to talk about Java multiplatform after trying to use the same applet from different browsers. Sun is going to charge (and it's said that a lot of money) for the next version of their VM called "HotSpot", that BTW it's said to change many things (once more) to achieve a better performance.

I'm happy to see that I'm not the only one that's interested not only in a Linux RAD, but also in a cross-platform one. It reminds me the discussions in the early Megido days about the ways of using the same code for different libs/os'es, by isolating the portable classes from the ones that deal with the windowing lib.

I wonder if someone is interested in talking about it...

greetings

Nico

http://www.clubdelphi.com/nico/

I really apprciate everyone's comments about Lazarus and the project in general and I know Cliff feels the same.
This WILL be a great IDE and a big step into getting more developers over to the Linux OS. We simply need more controls written.

With all the latest comments on Lazarus it has really gotten me more exicted about the entire thing again and I will start cranking it up again soon.

Anyone interested in helping, feel free. We still need the TControls class to keep track on the child components on a parent so when it gets resized it can notify it's children in case they need to resize. This is a big deal so I would appreciate someone looking at the Controls.pp unit and seeing if they can find a way (similiar to Delphi's method) to keep track of the children when a control is added to a parent. Also, you would need to determine a method to send the child controls a resize message...

I will fix the compile error tonight or tomorrow (hopefully) and update CVS. I have people coming over tonight so if I have to much fun I may not be able to write any code. :-)

Thanks for the comments

Shane

Hello,

As you've probably seen, we are interested in talking about a LOT of different idea's and subjects. If you'd like to start it out with your thoughts, feel free...

Here it goes: months ago, when Lazarus was starting, I sent a couple of messages to Cliff, asking what was more important to you. If creating an inmediate port over gtk or a more complex lib, but keeping the chance to port it to run under any other OS and to use any other available lib.

I like the second option. You chose the first one and you have done what you planned: an IDE based on gtk. I've been reading that you have had some problems with ansistring stuff and changing gtk version, however I have no doubt you will solve them.

Anyway now, for whatever the reason, you seem to be wondering if it would be practical to keep an eye on portability. There is some people in the list and out there that are very interested in a tool wich allow to share code between Linux, Windows and everywhere FPC runs and bindings for some graphical lib are available.

The deal is how much does it cost, in terms of design complexity and lines of code, to write and maintain a reasonably portable library.

The way of doing it was discussed time ago at Megido mail list. Writing high level classes that don't "know" about the actual lib used, but instead talk with it through an opaque interface.

There would be at least TWO parallel classes trees. One for the high-level plataform and library independent classes and another for wrappers classes for the gtk, qt, Xlib, winapi or whatever.

TControl------TButton
| |
TGtkControl----TGtkButton

The high level classes would only see other high level classes and would only use a TWidgetLib object as a factory to build the low level objects (the wrappers for concrete library controls).

The only problem is to send commands from high level portable classes to low level wrapper classes. There are several ways of doing this. Implementing a messaging system or creating a third tree that acts as an abstract interface between both other trees.

The commands from low level to portable classes would be implemented as callbacks.

Using this approach, and KCL people seems to go this way, it's possible to write both trees independently. And when you want to add support for another library, say you have gtk and you want to include Xlib, you just have to write a new implementation of the low level, non portable classes, while the high level classes will remain untouched.

I have code in order to do this. This code is a little more complex than what I've said here, in fact there are four set of classes (but not four levels of indirection). That's because I wanted, not only to be capable of recompile the code and go, but also using the same compiled code to work with different dlls (sort of Delphi packages).

Why haven't I published this code? Because it doesn't work!! Michael Van Canneyt, I've read a message from you saying that it isn't worth to blame the compiler of work undone.

I must disagree a bit: I've been waiting a long time for "procedure of object" bugs to be solved. I come back to the code once a month. No luck yet.

I thought I could use a workaround but the code would be full of them, bad thing for a sample that should show that it's easy to go this way.

Some time has passed from the last time I tested. 0.99.12 has been released and maybe it's time to try once more.

On the other hand, something is changing at Megido's list. Sybil way has shown to go nowhere. Here and there people demands a multiplataform environment, in this list I see fans of gtk, qt, Xlib, winapi... why don't we return to discuss it (OK, looking for a QUICK decission, no more long discussions) and return to be only one big project.

Following this scheme and since there are people that likes different base libs, we could work in parallel and release multiplataform from the very beginning.

I can't see real reasons to not doing it!

greetings

Nico

http://www.clubdelphi.com/nico/

Shane Miller wrote

Nicolas, I basically agree with you. I think we should design this in GTK first and then move it apart so we can develop later in QT or whatever. We can create units that do all the tool specific stuff and allow the user to link to whatever tools they want.

You have to be careful about how you break things apart. If you design based around one toolkit, you may find that the method you employ causes implementing another toolkit to be very hard. At the very least, you have to be thinking ahead about how the code can be split.

I just think that we should concentrate on GTK first and try to gete the basic classes complete.

It's too bad there aren't a few hundred more people. Then you could just say "Joe is doing TForm for GTK and Bill is doing TForm for QT and Bob is doing TForm for WinAPI and ...

Oh well.

In the meantime, check out the following site.

http://www.ma.utexas.edu/~mzou/EZWGL/

Jeff.

Nicolas Aragon wrote

Using this approach, and KCL people seems to go this way, it's possible to write both trees independently.

no, it uses a different approach: at the moment KCL is a single big unit
(only the signal/slot stuff is separated, as this isn't platform
dependent). Its interface and implementation parts are a bunch of
include files.
e.g. kcl_gtk/kcl.pp looks about the following:
  unit kcl;
  interface
  <some GTK specfic declarations>
  {$INCLUDE kcl_h.inc}
  implementation
  {$INCLUDE kcl_impl.inc}  // platform-independent method
implementations
  {$INCLUDE gapp.inc}
  {$INCLUDE gdrawing.inc}
  {$INCLUDE gform.inc}
  ...
  end.
kcl_h.inc basically does the following stuff:
  {$INCLUDE hkeys.inc}
  {$INCLUDE hdrawing.inc}
  {$INCLUDE hguibase.inc}
  ...

So all implementations share the same interface part; the only thing you have to do is to define some target-dependend types at the beginning of the interface part. For example, a TWidget has a member called 'Handle'. Under GTK, this is defined as a PGtkWidget, unter Win32 it is a HWindow, and so on.

I must disagree a bit: I've been waiting a long time for "procedure of object" bugs to be solved.

you're not alone...

- Sebastian

Nicolas Aragon wrote

I see. But this way needs recompilation. I hope that the same code could be used without even re-link.

Yes, I've been thinking of this for some time now, as there are some quite good reason to support this; and maybe we will find a solution some day. But at first we need a concept for building component libraries which are dynamically loadable; I will have a closer look on this topic very soon. (as KCL is LGPL'ed, I think it is required to support dynamic linking)
There is no reason why KCL shouldn't be able to support such techniques, as the memory layout of all classes are identically for all platforms. (take a look at the source and you know why, although in the current snapshot there may be some exceptions of this. I will fix this soon.)

If you don't plan to do any of what I said, it's OK. But even then, I think that it's more difficult to maintain: at some point you could want to introduce a feature that may not be implemented in other sections. Using inheritance almost forces you to stay compatible.

you can use dummy implementations

I've found FPC people very responsive in most cases. This seems to be a very tough problem.

yes, obviously. As Michael said before, these bugs prevent me from releasing the first official KCL and IDE snapshots, but as there is enough other work to do, I have no problem in waiting more than the usual 12-24 hours for bug fixes. At least they will have to fix them before the 1.0 release... ;-)

- Sebastian

Nicolas, I basically agree with you. I think we should design this in GTK first and then move it apart so we can develop later in QT or whatever. We can create units that do all the tool specific stuff and allow the user to link to whatever tools they want.

I just think that we should concentrate on GTK first and try to gete the basic classes complete.

Shane

There should be no problem with this from the compiler point of view; which doesn't mean that it isn't difficult. Since both win32 and linux support dynamical loading of libraries, it should be possile to do this in a platform independent way.

It should be fixed now. at least the test programs we got from you, and our own, seem to work correctly. Get the latest version from CVS to test.

Michael.

Hello,

I see. But this way needs recompilation. I hope that the same code could be used without even re-link. I think in an IDE written on gtk that produces programs that could run on qt, in programs that could check what library is available... of course I don't intend to write all this myself X'D

But I can think of more simple examples: an installer.

If you don't plan to do any of what I said, it's OK. But even then, I think that it's more difficult to maintain: at some point you could want to introduce a feature that may not be implemented in other sections. Using inheritance almost forces you to stay compatible.

> I must disagree a bit: I've been waiting a long time for "procedure of > object" bugs to be solved. you're not alone...

I've found FPC people very responsive in most cases. This seems to be a very tough problem.

greetings

Nico

Don't forget that procedure of object is in the compiler since March. And since then we only did bugfixing and not adding new features (which is procedure of object).

Peter

Hello,

want to use abstract widget classes and implementation classes for each platform, which are derived from these abstract widgets, you will not be able to add widgets in your own applications or libraries. Perhaps you mean something totally different?

When you write a new widget, you must decide if it will be generally available or just for the lib you're using. If your new component is just a light modification of an existing portable component that doesn't use anything but portable calls, you won't need anything else.

You can also write a particular component, from a portable one, introducing some particular calls through casting. Or you can write a brand new portable component, in which case, you'll need to define several classes.

The last one is the case for basic components that should be widely available. How to do it? You point that there's a problem with inheritance and that's right. Bridge pattern as described by Gamma and company deals with the problem of having one portable class. This case is a little more complex, because we have to keep portable a whole tree.

Now you gotta choose between:

TControl---TButton---TQtButton

This way, you use the inheritance for the portable classes, but you miss it for the concrete library classes. The other option:

TControl---TQtControl---TQtButton

Now you loose the inheritance for the portable classes, but you have it for the native classes.
Of course the solution is easy with multiple inheritance:

TControl---TButton
\
--- TQtButton
TQtControl /

But we don't have multiple inheritance!!
In Delphi it would be possible to implement it anyway through interfaces. Since interfaces are classes theirselves, you can define portable classes as a tree of interface classes and make your concrete classes implement them.

FPC is intended to be completely Delphi compatible in the future, but as of now, there aren't interfaces. Anyway there is a workaround. If you wait a few days, I hope I'll be able to write a complete example, now that procedure of object seems to be working at last :)'

Yes, you can.

should be in 'the background', normal users (developers) shouldn't see any difference. Delphi uses some dirty hacks to implement its modules;

What do you mean "dirty hacks"?

we'll see what is the best for our purposes. Currently I'm playing around with external methods, libraries etc.; perhaps you can convince if you have a working demo of your concept.

If you know how to write a dll in Linux, you could test something like this:

unit general;
interface
type
  TGeneral = class
    procedure SayHello; virtual; abstract;
  end;
implementation
end.

___

unit dllinterface;
interface
uses General;
function GetGeneral: TGeneral;
implementation
function GetGeneral: TGeneral; external;
// there should be a $linklib somwhere
end.

___

library TheDll;
uses General;
type
  TConcrete = class( TGeneral )
    procedure SayHello; override;
  end;
function getGeneral; TGeneral; export...
// I don't remember the exact syntax
// of library and exports, sorry
// I think you'll understand what
// I want to do, though
implementation
procedure TConcrete.SayHello;
begin
  Writeln( 'Hello from DLL' );
end;
function GetGeneral: TGeneral;
begin
  Result := TConcrete.Create
end;
end.

This is NOT the intended code. But if it works, my solution would also work.

greetings

Nico

Hello,

Why not using mine? It's already there. If you want details, you just have to ask for them.

But at first we need a concept for building component libraries which are dynamically loadable;

I have it. And it's very simple: component libraries are objects. You just need to define an abstract ancestor for them and inherit from it for every library that is to be dynamically loaded.

(take a look at the source and you know why, although in the current snapshot there may be some exceptions of this. I will fix this soon.)

Sorry, I can't. I'm envolved in another time consuming project (not talking of my job) :(

> want to introduce a feature that may not be implemented in other > sections. Using inheritance almost forces you to stay compatible. you can use dummy implementations

Inheritance seems to be the natural way in *Object* Pascal.

enough other work to do, I have no problem in waiting more than the usual 12-24 hours for bug fixes. At least they will have to fix them before the 1.0 release... ;-)

Yes but, getting it solved sooner would help to ship an already working RAD along with thar release.

greetings

Nico

Nicolas Aragon wrote

>It should be fixed now. at least the test programs we got from you, and our >own, seem to work correctly. Get the latest version from CVS to test. Are you sure?

Yes, at least I am sure, as our IDE works now!!! (ok, there are still other bugs, but _this_ stuff is working now). Thanks, Michael!

Yes, we're using procedures of objects for the new keyboard handling code, and I can assure you that it works now.
(BTW, if you are interested: The editor widget I wrote (TSHTextEdit) holds a list of keyboard actions (method address (!) and human-readable description for this action) and a list of key assignments (keycode+modifiers -> keyboard action). So it's possible to change nearly all keyboard shortcuts, and to build a configuration dialog in which you see a list of all keyboard actions and their associated keyboard shortcut.

- Sebastian

Most definitely. : the following crucial test programs work:

--------------------8<-----------------------
{$MODE objfpc}
program procofobject_arg;
type
  TProcOfObject = procedure of object;
  TTestClass = class
    constructor Create;
    procedure SomeMethod;
  end;
procedure CrashProc(i1: Integer; method: TProcOfObject; i2: Integer);
begin
  WriteLn('i1 is :', i1);
  method;
  WriteLn('i2 is :', i2);
end;
constructor TTestClass.Create;
begin
  CrashProc(123, @SomeMethod, 456);
end;
procedure TTestClass.SomeMethod;
begin
  WriteLn('In SomeMethod');
end;
var
  instance: TTestClass;
begin
  instance := TTestClass.Create;
end.
--------------------8<-----------------------

Output is:

home: >ppc386 testpo
home: >testpo
i1 is :123
In SomeMethod
i2 is :456
home: >

And then the following program:

--------------------8<-----------------------
{$MODE objfpc}
program procofobject_arg;
type
  TProcOfObject = procedure of object;
  TTestClass = class
    constructor Create;
    procedure SomeMethod;
  end;
  TProcOfObjectInternal = packed record
    method: Pointer;
    obj: TObject;
  end;
constructor TTestClass.Create;
var
  method: TProcOfObject;
begin
  method := @Self.SomeMethod;
  WriteLn('In Constructor:');
  WriteLn('  Self = ', Integer(Self));
  WriteLn('  Method = ',
    longint(TProcOfObjectInternal(method).method), '/',
    longint(TProcOfObjectInternal(method).obj));
end;
procedure TTestClass.SomeMethod;
var
  method: TProcOfObject;
begin
  method := @SomeMethod;
  WriteLn('In SomeMethod:');
  WriteLn('  Self = ', Integer(Self));
  WriteLn('  Method = ',
    Longint(TProcOfObjectInternal(method).method), '/',
    Longint(TProcOfObjectInternal(method).obj));
end;
var
  instance: TTestClass;
  method: TProcOfObject;
begin
  instance := TTestClass.Create;
  method := @instance.SomeMethod;
  WriteLn;
  WriteLn('In main program:');
  WriteLn('  instance = ', Integer(instance));
  WriteLn('  Method = ',
    Longint(TProcOfObjectInternal(method).method), '/',
    Longint(TProcOfObjectInternal(method).obj));
  WriteLn;
  instance.SomeMethod;
end.
--------------------8<-----------------------

output is:

home: >ppc386 testp
home: >testp
In Constructor:
Self = 134552384
Method = 134544316/134552384

In main program:
instance = 134552384
Method = 134544316/134552384

In SomeMethod:
Self = 134552384
Method = 134544316/134552384
home: >

I hope this convinces everyone :-)

Michael.

Nicolas Aragon wrote

When you write a new widget, you must decide if it will be generally available or just for the lib you're using.

yes, of course. But I see one big disadvantage in your approach: It won't be possible to derive an existing (and fully implemented) widget class. As said before, in KCL there's this TSHTextEdit widget. TSHTextEdit is generally available, but it is derived from TScrollBox, which has to be implemented differently for each target. I still don't know why this shouldn't work

Of course the solution is easy with multiple inheritance:

[...]

This would be possible; but I think the solution we found in KCL is simple enough...

I've thought about all this dynlinking stuff (see other postings), and I think it is possible if all methods are external. When you have a class with external constructor, this external constructor will set up the VMTs and RTTI tables. But I don't know what will happen if you want to derive an external class, as the VMTs and RTTI stuff can't be declared as external - the code FPC generates would have to call the inherited constructor and to use the information it has set up. Perhaps one of the compiler experts here knows if external classes would be possible without restrictions?

>should be in 'the background', normal users (developers) shouldn't see >any difference. Delphi uses some dirty hacks to implement its modules; What do you mean "dirty hacks"?

At least Delphi 4 is capable of using this BPL libraries (DLLs with an extra function which returns a list of included units): The compiler won't link units into your app/DLL, if they are part of one BPL in a user-provided list of BPL files.

If you know how to write a dll in Linux, you could test something like this:

[...]

you won't have to export your functions, as you can compile a unit as library, so all the stuff in the interface part will be exported automatically. I think it is possible to merge several libraries using libtool, but I'm not sure about this.
I've played around this recently, and had some problems regarding the linking stage, as ld, when called from fpc, won't find my library. I will have another look at this soon.

- Sebastian

Nicolas Aragon wrote

Why not using mine? It's already there. If you want details, you just have to ask for them.

[...]

Inheritance seems to be the natural way in *Object* Pascal.

Yes, and that's the reason why we _cannot_ use inheritance for this purpose.
For example, TSHTextEdit (my editor widget with syntax highlighting etc.) is derived from KCL.TScrollBox; the implementations for a TScrollBox are different for different targets/platforms. If you really want to use abstract widget classes and implementation classes for each platform, which are derived from these abstract widgets, you will not be able to add widgets in your own applications or libraries. Perhaps you mean something totally different?

>But at first we need a concept for building component >libraries which are dynamically loadable; I have it. And it's very simple: component libraries are objects.

Can I do something like:
TScrollBox.Create
within my application? I don't think so. IMHO this dynamic loading stuff should be in 'the background', normal users (developers) shouldn't see any difference. Delphi uses some dirty hacks to implement its modules; we'll see what is the best for our purposes. Currently I'm playing around with external methods, libraries etc.; perhaps you can convince if you have a working demo of your concept.

- Sebastian

Can I do something like: TScrollBox.Create within my application?

Wouldn't this create an object of type TScrollBox that during it's constructor in turn created a Gtk/Gnome/Qt/Win32 equivalent, depending on which environment it was compiled for?

Jeff.

This only works with the latest compiler from the main CVS tree, not the release 0.99.12a compiler.

Peter

Well, see the other mails. It's OK now.

Michael.

Hello,

It should be fixed now. at least the test programs we got from you, and our own, seem to work correctly. Get the latest version from CVS to test.

Are you sure?

Having;
type
  TProcedureOfObject = procedure of object;

Will this work?

procedure Blah( a: TProcedureOfObject );

And give the expected results, of course :))

BTW, does changing from 0.99.11 to next version through CVS need some dir/scripts/whatever rename? Is it better to get a brand new tree?

greetings

Nico

Hello,

Don't forget that procedure of object is in the compiler since March.

Are we talking about the same beast? I mean variables that holds a mathod (code+self). I think what you introduced recently is the new method type with string message and self included in any place of the parameter list. Or am I wrong?

since then we only did bugfixing and not adding new features (which is procedure of object).

I think it would really speed up things very much to have this feature early available. Please, please, please... O:-)

greetings

Nico

Jeff Wormsley wrote:

[...]

Let me know if have completely missed the boat on what you are trying to do...

Basically, the main goal is to have this implemented without adding any overhead to application developers, and it should be as efficient as possible.
If you want to do something dynamically, you will have to use ELF libraries or DLL's, of course.
Now there are two possibilities:
a) you have a toolkit which 'only' supports source-code compatiblity (and one lib file per target), or
b) you have a set of lib files which are binary compatible, and you have some kind of mechanism which allows you to decide at run time which lib to use.

a) is quite simple, this is what all libraries are doing, and which is a little bit difficult to handle in Pascal: you have an interface unit, the implementation part consists of 'external' directives; and the implementation tries to implement the interfaces you have declared... in KCL for example this wouldn't be too hard to add, as it uses C-like header files (includes), which could be shared between both parts. Currently I'm playing around with this approach, and I'm not sure if it is really possible to have a totally external class, which can be used without noticing any difference from a programmers point of view. But I'm quite optimistic that this will be possible, as VCL supports this, too, for a long time.

b) would be _much_ more difficult to implement, as you would have to provide some kind of indirection layer, i.e. a unit or library which you can link against and which dyn.loads an appropiate implementation library.
I'm proposing to do the following:
You start with approach a) and add an additional library as indirection layer. All those libraries share the same interface, so you are free to link your applications against a specific library. I'll give an example now, please forgive me to choose KCL again in the Lazarus mailing list: In the near future, there may be two libs called 'libkcl_gtk.so' and libkcl_qt2.so' (perhaps there will be a 'libkcl.so' with all platform-independent stuff, I don't know yet). In a) you would have to choose if you link to libkcl_gtk or libkcl_qt. Now we're introducing this indirection layer called 'libkcl_dyn.so'. If you link to this library, it will decide which target to choose automatically, you won't have to change the code of your application for that. In KCL,
- all methods (except constructors) have to be virtual, as virtual methods don't generate any relocation information
- there should be as few global procs/functions as possible; no global vars

As speed it not really an issue here, it would be no problem to use only virtual methods, which are suboptimal in most cases. This approach has a big advantage: It can be added sometimes later without requiring changes to the 'real' implementations. Basically, it allows three different linking modes:
1. static linking: One target library is included in the application's binary file
2. semi-dynamic linking: Application is linked against a specific target library
3. real dynamic linking: Application is linked against libkcl_dyn.so/kcl_dyn.dll, the same binary will run with different target libraries.
Application which use the internally used handles probably won't run using (3), of course.

I can only speak for KCL here: Its current state is (1), (2) is planned to be added very soon, and (3) will be added as soon as there are more than 1 targets available on a single platform. This will be the case when it is possible for Win32 KCL applications to use GTK or the native win32 implementation (kcl_gtk.dll and kcl_w32.dll).

At least it is possible to handle Win32 DLLs and Linux ELF libs the same way, as the dynamic loading APIs are very similar. (we only need 3 functions: Load library, get address of procedure, and unload library).

- Sebastian

On 7/1/99, at 9:12 PM, Sebastian G�nther wrote:

Thanks, Sebastian.

I think this may be where I missed the most of the picture. I had not considered runtime linking of the code. That may be because I still think Win32 PE format vs. linux executables. But I can see where it would be advantageous to have one executable that on load, would detect whether the Qt or Gtk were available and act accordingly. I had been thinking the developer would check a radio in the IDE for the platform of choice, click a button, and the IDE would build an executable in the appropriate directory for the platform. So my idea of platform independence was from the developers point of view, not the executables.

Jeff.

Nicolas Aragon wrote

I don't fully understand what's the problem.

ok, please wait and see. The pros of this approach will be quite obvious as soon as we have more than one target implemented.

Are you suggesting to make a class whose methods are implemented in some other place?

Basically, yes.

- Sebastian

Hello,

I can't see why.

s said before, in KCL there's this TSHTextEdit widget. TSHTextEdit is generally available, but it is derived from TScrollBox, which has to be implemented differently for each target.

I don't fully understand what's the problem. Surely because I don't know these classes. But one thing is clear: implementation is completely separated from interface, in fact this is the main purpose of my idea.

> Of course the solution is easy with multiple inheritance: This would be possible; but I think the solution we found in KCL is simple enough...

If you mean using defines, it can do the trick. But not all. OK. Wait to see the code and you'll judge by yourself.

Are you suggesting to make a class whose methods are implemented in some other place?

VMTs and RTTI tables. But I don't know what will happen if you want to derive an external class, as the VMTs and RTTI stuff can't be declared as external - the code FPC generates would have to call the inherited constructor and to use the information it has set up.

I think you are missing the main point: both sides includes an uses to the abstract ancestor. It's enough to make the objects compatible.

Moreover, it works. Delphi uses this technique in several places since version 2.

greetings

Nico

Sebastian G�nther el d�a Sat, 03 Jul 1999 20:17:45 +0200, escribi�:

> Are you suggesting to make a class whose methods are implemented in > some other place? Basically, yes.

I've been insisting on this for almost two months, oh well ...

Sergio