Sign in Join

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

Mailing lists / fpc-pascal / 2003-01

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

9 messages · 4 people ·

Reply by email Subscribe to this list Your subscription

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

Unknown author
Show quoted text 12 lines
From: Michael Van Canneyt To: Subject: Re: [fpc-pascal]motif bindings. Reply-To: > I tried using h2pas on the headers but it bombed when encountering > the Cardinal typedef in the headers. X11 and Xt lib bindings exist already in the packages (extra/x11) Motif is not yet translated; Maybe someone can start translating the Open motif header sources.

I checked the CVS tree and could not find the bindings for Xt lib. Only X11 is found/bound. IIRC, its Xt that defines the Cardinal type. How do I workaround this problem ?

I'm thinking of a UI toolkit along the lines of Eclipse's SWT.

btw, what happened to the fpgfx/fpgui effort ?

cheers,
-Krish

Reply by email

Michael Van Canneyt
to Unknown author
Show quoted text 15 lines
> From: Michael Van Canneyt > To: > Subject: Re: [fpc-pascal]motif bindings. > Reply-To: > > I tried using h2pas on the headers but it bombed when encountering > > the Cardinal typedef in the headers. > > X11 and Xt lib bindings exist already in the packages (extra/x11) > Motif is not yet translated; Maybe someone can start translating the > Open motif header sources. > I checked the CVS tree and could not find the bindings for Xt lib. Only X11 is found/bound. IIRC, its Xt that defines the Cardinal type. How do I workaround this problem ?

Prepend it with _

I'm thinking of a UI toolkit along the lines of Eclipse's SWT.

We've looked at that, but the problem with that is that the streaming support will be hard to implement.

btw, what happened to the fpgfx/fpgui effort ?

This is delayed, but will be picked up again really soon.

Michael.

Reply by email

Unknown author
Show quoted text 7 lines
> > From: Michael Van Canneyt > I'm thinking of a UI toolkit along the lines of Eclipse's SWT. We've looked at that, but the problem with that is that the streaming support will be hard to implement.

Pardon me if this is a stupid question: why should streaming support be implemented at all for a gui toolkit ?

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

On a different subject: why do interfaces in FPC inherit from IUnknown ? Is this for supporting COM ? If objects are not reference counted why then interfaces are ?

> > btw, what happened to the fpgfx/fpgui effort ? This is delayed, but will be picked up again really soon.

This is good news. The screenshots looked nice.

cheers,
-Krish
-----------------------
First they ignore you. Then they they fight you
and then you win
- "Mahatma" Gandhi.
-----------------------

Reply by email

Michael Van Canneyt
to Unknown author
Show quoted text 11 lines
> > > From: Michael Van Canneyt > > I'm thinking of a UI toolkit along the lines of Eclipse's SWT. > > We've looked at that, but the problem with that is that the streaming > support will be hard to implement. > 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.) 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.

Show quoted text 5 lines
> > > > btw, what happened to the fpgfx/fpgui effort ? > > This is delayed, but will be picked up again really soon. This is good news. The screenshots looked nice.

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

Michael.

Reply by email

Unknown author
Show quoted text 7 lines
> 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.

Show quoted text 8 lines
> 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.

Show quoted text 6 lines
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

Reply by email

Unknown author
Show quoted text 7 lines
wrote: > On a different subject: why do interfaces in FPC inherit from IUnknown ? Is this for supporting COM ? If objects are not reference counted why then interfaces are ? If you declare corba interfaces, they won't be ref. counts. {$interfaces corba} does the trick, it applies to all interfaces declared after that switch.

Ha!. thx for the enlightenment. So to obtain Java/Objective-C like interfaces, I just need to put {$interfaces corba}. right ?

cheers,
-Krish

Reply by email

Sebastian Günther
to Unknown author: XML streaming should be easy. Every widget just implements the streaming interface (how…
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.

generally speaking, this is correct. OTOH many people want to port things with minimal effort, so compatiblity *is* important, and done in FPC, where possible.

Show quoted text 9 lines
>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.

The CVS version is quite outdated, but while my local version has some more features, other things are broken. Development will continue, but not within the next few weeks, as other things have to be done first. But I'm already planning the next new features and changes.

- Sebastian

Reply by email

Sebastian Günther
to Unknown author: Ha!. thx for the enlightenment. So to obtain Java/Objective-C like interfaces, I just…
Ha!. thx for the enlightenment. So to obtain Java/Objective-C like interfaces, I just need to put {$interfaces corba}. right ?

I personally would recommend to use IUnknown, as it is a semi-standard by now. It adds only 3 methods for reference counting and typecasting support, and not only COM uses it. (e.g. Mozilla's internal components use IUnknown compatible interfaces as well)

- Sebastian

Reply by email