[fpc-pascal]Re: fpc-pascal digest, Vol 1 #1646 - 4 msgs

[vkrish at vkrish.cjb.net]

> > Pardon me if this is a stupid question: why should streaming support be implemented at all for a gui toolkit ?
> 
> For use in an IDE, and for easy designing/changing of forms.
> 
> >
> > If you are talking about the persistence of gui forms, then a suitable XML DTD can be designed for saving them. (eg: glade, Qt and recently GNUstep are all doing that successfully.)
> >
XML streaming should be easy. Every widget just implements the streaming interface (how good is the interface support ?). Forms can be loaded simply by traversing the DOM tree and widgets created on the fly. XML streaming also allows one to generate code for the form and compile it statically.

> > On a different subject: why do interfaces in FPC inherit from IUnknown ?
> 
> They don't *have* to inherit from IUnknown, as far as I know.
> 
> > Is this for supporting COM ? If objects are not reference counted why then interfaces are ?
> 
> It is for Delphi compatibility, which probably does it for COM purposes.
> 
Just a question: why should FPC always "chase" delphi ? Is Delphi the only standard for object pascal ? FPC should choose and implement what is best for it. IMO, FPC has two advantages: portability and price (a big thx for the FPC team). So it can afford to go in its own way.

> You can always check out the code and play with it:
> (log in on cvs)
> cvs co projects/fpgfx
> cvs co projects/fpimg
> cvs co projects/fpgui
> 
Yeah... I do have them in the tree. Only that I did'nt build them.
I'm looking at the event handling code there.

cheers,
-Krish