Names make little difference to me. I just like to write lots of code.

I am also a community oriented fella so whatever the masses wishes is fine by me.

BTW I will be cranking back up tonight. I had to knock off development for a few weeks while cranking something out at my boring day job.

I just built another machine devoted to development. It will probably take me tonight to get the final configuration together and rejoin the effort. What do we think about the current direction with the GTK+ widgets. Does anyone have ideas about anything better. These widgets are ok to put something quick out but there are also many problems in the way in which they work. First of all the call back methods they use are flexible but they also cause execution to have to be directed back and forth from the C libs so that the code does not fall through. Another problem is that the widgets do not lend themselves to XY widget placement. I have not looked to closely at it but should we be implementing at the glib level? Maybe totaly define our component structures based from glib vs the already defined widgets. This would maybe be more work but allow us to move the code to a more delphi like implementation?.

What does everyone think? Suggestions Welcome.

In any case we need to work the flat IDE a little to make it just a bit more productive.

Cliff

I think that you should code as API independent as possible. Experience with the compiler shows that people like two things:
1) Borland compatibility. Be it TP or Delphi.
2) Cross-platform indenpendence.
Bearing this in mind, I propose to make API independent structures, (After all, you are writing an API of your own) possibly with GLIb (or whatever) descendents.

The people writing KCL have made it ready to be ported to native win32 and Qt. I think Lazarus should not do less.

Michael.

I have thought about this in the past. If we were intending on making Lazarus (aka the FCL) GUI API dependent then coding directly to glib would be the best idea. Then all compenents would be designed within the FCL and would make inheritence of components and the ability to redesign components based on a parent much easier.

However, that would tie us more closely to GTK. It might make using other APIs such as QT for KDE much more difficult. By not going stright to glib we will be able to make interfaces directly to the GNOME widget set which gives our FPC code immediate D&D, Corba, etc. etc. without our having to add any of that into the FCL. So it is a trade off. I think setting up interfaces to the various GUI APIs is the best way to go. It removes that headache from our shoulders.

First C++ linking needs to be working before a beos port can be started

Peter

el d�a Sun, 27 Jun 1999 20:00:47 +0200
(MEST), escribi�:

2) Cross-platform indenpendence.

if one of the goals of FPC is this, why not use gcc as backend, instead of assembly ?

Sergio

1) We want to be completely independent of C.
2) We're not writing 'p2c' here :)

Once we had a proposition from a commercial company to support a dialect of their pascal compiler (development of which was being discontinued). In the end they wanted a Pascal to C converter.
It was the end of our conversations :-)

Michael.

Anyone know of any intentions of heading this way :)

If FPC is moved to beos, I'd more the gladly help maintain a beos version of lazarus.

Keep up the good work!

Jon Gilkison
inneraktive nettwerx.

"Baeseman, Cliff" el d�a Sun, 27 Jun 1999
11:30:58 -0500, escribi�:

What do we think about the current direction with the GTK+ widgets. Does anyone have ideas about anything better.

Gnome

These widgets are ok to put

something quick out but there are also many problems in the way in which they work. First of all the call back methods they use are flexible but

they

also cause execution to have to be directed back and forth from the C libs so that the code does not fall through. Another problem is that the widgets do not lend themselves to XY widget placement.

have you seen GtkTable ?

Sergio

el d�a Tue, 29 Jun 1999 00:02:19 +0200
(MEST), escribi�:

you like more assembly than C ?

I think you are not understanding me..

gcc support more platforms than FPC, rigth ?

so instead of making assembly code, FPC could be integrated with gcc, using it like the backend compiler to generate code in _any_ platform that is supported by gcc
(wich is /lots/ of platforms).

Sergio

No I think you don't.

You don't get p2c.

gcc's backend compiler compiles RTL, not C.

gcc's frontend converts C to RTL.
gpc's frontend converts Pascal to RTL. How come you mention how gpc was done without being aware of how things are designed?

I had the impression that the reason you didn't use gpc was because it didn't have enough Borlandisms, not because of any compiler bigotry. Was I wrong?

Whow ! telepathy at work here :-)

Yes you do. READ the sentence: "using it like the backend compiler." not "use it's backend".

gcc's backend compiler compiles RTL, not C.

I know. So do GPC and G77 too I think, although I'm not sure of the latter.

gcc's frontend converts C to RTL.

I know. That is why they can port to new platforms quite easily,. All that needs to be changed is the RTL->assembly converter. We've studied the RTL mechanism to see how it is done. Impressive piece of work. Hats off for the GCC people !!

gpc's frontend converts Pascal to RTL. How come you mention how gpc was done without being aware of how things are designed?

Hey, I studied GPC in it's very early stages! I even managed to compile it under DOS-EMX. Quite a feat at that stage of development. I then had lots of contact with Peter Gerwinsky, one of the maintainers.

I had the impression that the reason you didn't use gpc was because it didn't have enough Borlandisms, not because of any compiler bigotry. Was I wrong?

Yes you are wrong. In the end I had more luck running FPC than GPC. Then I ported FPC to linux, and I was hooked :-)

Anyway, the first week of august, the FPC developers will meet. The big point is then the redesign of the code generator: In principle, we'll redesign it using OOP so that porting to a new processor will essentially be reduced to the overriding of a limited number of abstract methods. (disregarding processor specific optimization routines) We believe that:
1. This will be a easier to grasp method than the RTL used by GCC.
2. We'll be able to use a better data flow analyzer, resulting in better parallelism.
2. It is more in line with the rest of the compiler, which is also OOP. The code generator now is essentially linear procedure based now.

I you don't mind, I'd say 'Discussion closed, there is work to do' :-)

Michael.

I dislike C more than assembly.

Oh, I do, don't worry :)

Then you have p2c. We don't want p2c !
GPC was made this way. We don't want it either :-)

You can discuss whatever you like, but it's a done deal: FPC writes it's own assembler. It even has a binary writer. If this means that we have less platforms, so be it. We'll get there one day.

Michael.