[lazarus] Multiplataform

[Nicolas Aragon]

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/