Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 1999-05

multiplataform ?

3 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Jeff Wormsley
to Sergio A. Kessler: Putting all the gtk calls in one file ? I think you are reinventing the wheel here. This…
Sergio A. Kessler wrote 7 lines
fpc/ fcl/ -> base classes (multiplataform) gui/ inc/ -> gui high level (toolkit independent) gtk/ -> gui base level (toolkit dependent) qt/ gnome/

win32 -> Even if gtk has a Win32 port, a direct solution might be nice...

How would you implement switching from one GUI to the other? If each GUI has it's own unit, with a non-implementation specific calling interface, then a simple construct as follows in the GUI header would work and would only have to be done in one place.

{$IFDEF GTK}
Uses GTKLIB;
{$ELSEIF QT}
Uses QTLIB;
{$ELSEIF GNOME}
Uses GNOMELIB;
{$ELSE
Uses WIN32LIB;
{$ENDIF}

If you embed the GUI code into each component, then you will have to have something like this for each and every unit. Or worse, each component would need this construct for each GUI function it performed, which would be the GUI toolkit functions at a level below the FCL seems to make a lot more sense, and should be easier to use in the long run. Unfortunately, in the short term, it will be a pain in the rump, especially when we get to the point of implementing the next GUI toolkit, such as qt. I would bet dollars to doughnuts that the abstraction needed for GTK will be different for QT, so that our nice CreateComponent that calls the GTK function can't be done that way for QT, so that implementing QT means rewriting GTK also to define a new abstraction layer that is suitable for both. Arrrghhh. As much trouble is that is, though, when all is said and done, the GUI independence will be well worth the effort.

I shudder to think what implementing a GUI independent TCanvas with OnPaint events would be like. <cringe, shudder>

Jeff.

Jeff.

Reply by email

Sergio A. Kessler

Putting all the gtk calls in one file ?

I think you are reinventing the wheel here.
This is complicated, unnecesary and requires a lot of coordination and sinchronization betwen developers.

You are forgetting that the VCL *IS* an API that could be done with various toolkits.

It doesn't make sense to do an api over an api (gtk) over an api (vcl).

You want multiplataform ?, look at this:

fpc/
fcl/ -> base classes (multiplataform)
gui/
inc/ -> gui high level (toolkit independent)
gtk/ -> gui base level (toolkit dependent)
qt/
gnome/

look at this picture for a minute and your brain will do the rest.

You have gtk/ done, want qt ?, just copy all the files to qt/ and replace every gtk_* with qt counterpart.

KISS (Keep It Simple, Stupid)

Of course, this is my opinion, not sane, intelligent or necesarely usefull.

Sergio

Reply by email

Baeseman, Cliff

Hmmmmmmm Not a bad idea.

More along with what I think.

Cliff

Earlier message 47 lines
-----Original Message----- From: Sergio A. Kessler Sent: Thursday, May 20, 1999 11:56 PM To: Lazarus mailing list Subject: [lazarus] multiplataform ? Putting all the gtk calls in one file ? I think you are reinventing the wheel here. This is complicated, unnecesary and requires a lot of coordination and sinchronization betwen developers. You are forgetting that the VCL *IS* an API that could be done with various toolkits. It doesn't make sense to do an api over an api (gtk) over an api (vcl). You want multiplataform ?, look at this: fpc/ fcl/ -> base classes (multiplataform) gui/ inc/ -> gui high level (toolkit independent) gtk/ -> gui base level (toolkit dependent) qt/ gnome/ look at this picture for a minute and your brain will do the rest. You have gtk/ done, want qt ?, just copy all the files to qt/ and replace every gtk_* with qt counterpart. KISS (Keep It Simple, Stupid) Of course, this is my opinion, not sane, intelligent or necesarely usefull. Sergio _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.miraclec.com/list_archives/lazarus

Reply by email