[lazarus] Multiplataform

[Nicolas Aragon]

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 :)'

>> >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. 

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