Shane, what do you think about where to do object creation ?

I made it clear, IMO, that should be done in the components themselves and not in a inner class (too many problems).

Also, note that there are some problems with TWinControls, if the user choose the close button of the wm, the widget is destroyed, yes, destroyed. So we need to simulate the Delphi behavior like in dialogs.pp, wich is recreated if it is destroyed.

Sergio

Not that I am aware of. What are you talking about???

"Shane Miller" el d�a Thu, 20 May 1999 15:45:59 -0500, escribi�:

I believe each component should do it's own object creation. I know that

it was put in that one spot for ease of use initially.

We have to seperate it from the classes eventually anyway if we are going

to make this work with QT and the like. I would say that there should be an external file that we call to do all the creates.

it's not only the create of the widget, it also all the signaling, see dialogs.pp

Each class (tform, tbutton, tsomething) would call a procedure to create it's gtk/qt/lmnop widget and assign the appropriate events. That way the source is seperate and we could act like we are doing a WINAPI call if we want.

Shouldn't be that difficult, and if someone wants to move them, that's fine

by me.

ok, I will do some hacks tonigth in controls.pp and in forms.pp (and a little dialogs.pp)

I don't see any problem for people constructing their own components

because they will simply fake a winapi (or whatever) call that will construct the widget. If they are going real "low" level and creating a new gtk_widget, it simply gets added to the lazarus_gtk file (where the widgets are created)

don't count on this, it's not that simple (I will try, but don't hold your breath)

and they create a class called TCustomNewWidget where "NewWidget" is the name of their new widget.

I haven't really spent much time on this. I think instead of throwing out

this info, perhaps we could get our strategy documented in HTML and displayed on the Lazarus site? Any volunteers? A nice Component/Class structure tree would be cool. That way we all see what the plan is and can talk about something concrete.

(get me talking and you can't shut me up)

please, please, use the enter key :(

Once I have that working I planned on going gtk procedure by gtk procedure moving them out into the GUIAPI. Thus making the FCL usable by other APIs.

Michael, if you are doing what I think, you are doing the same that is done by now, just in another file.

Sergio

I believe each component should do it's own object creation. I know that it was put in that one spot for ease of use initially.

We have to seperate it from the classes eventually anyway if we are going to make this work with QT and the like. I would say that there should be an external file that we call to do all the creates. Each class (tform, tbutton, tsomething) would call a procedure to create it's gtk/qt/lmnop widget and assign the appropriate events. That way the source is seperate and we could act like we are doing a WINAPI call if we want.

Shouldn't be that difficult, and if someone wants to move them, that's fine by me.

I don't see any problem for people constructing their own components because they will simply fake a winapi (or whatever) call that will construct the widget. If they are going real "low" level and creating a new gtk_widget, it simply gets added to the lazarus_gtk file (where the widgets are created) and they create a class called TCustomNewWidget where "NewWidget" is the name of their new widget.

I haven't really spent much time on this. I think instead of throwing out this info, perhaps we could get our strategy documented in HTML and displayed on the Lazarus site? Any volunteers? A nice Component/Class structure tree would be cool. That way we all see what the plan is and can talk about something concrete.

(get me talking and you can't shut me up)

Shane

>> "Sergio A. Kessler" 05/20 3:30 PM >>>

Shane, what do you think about where to do object creation ?

I made it clear, IMO, that should be done in the components themselves and not in a inner class (too many problems).

Also, note that there are some problems with TWinControls, if the user choose the close button of the wm, the widget is destroyed, yes, destroyed. So we need to simulate the Delphi behavior like in dialogs.pp, wich is recreated if it is destroyed.

Sergio

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

Shane Miller wrote

Shouldn't be that difficult, and if someone wants to move them, that's fine by me.

This is what I am trying to do with the GUIAPI file. I am trying to separate the FCL classes from the gtk widget routines. At this point I only have the TApplication stuff done and am now working on the callback stuff. If the DispatchStr stuff can get working then that will be moved out completely. I have it all coded in my version of the GUIAPI I just haven't commited anything since DispatchStr doesn't work yet.

Once I have that working I planned on going gtk procedure by gtk procedure moving them out into the GUIAPI. Thus making the FCL usable by other APIs.

To answer Sergios question, yes all component creation should not be done in the low level classes as it is done now but in the base class that is using it.

Sergio Kessler wrote

if you are going to put all gtk calls (not only signaling) in one file, the only thing you are doing is complicating my life for no real gain as far I can see.

How you were the one originally talking about making sure that the classes could work with different GUIs and have some sort of directory structure

FPC/GUI/GTK
FPC/GUI/QT

etc. etc. etc.

How do expect to do that if you don't remove the dependence of the GUI out of the class tree structure? The gain is that a developer would be able to rebuild their application for Gnome, KDE, Motif, whatever just by linking with the guiapi unit that supported their library.

If we are going to leave all of the gtk calls in all of the class tree well then just say we are making a gtk product and be done with it.

Otherwise the only way you will be GUI independent is to rewrite all of the class each time you want to use a new or different GUI. It also means changing all of the class code when gtk 1.3 comes out instead of just changing one file.

It's very simple. Delphi uses a similar mechanism in TWinControl. TWinControl sets a bunch of options (depening on properties) and then calls something like CreateWindowControl which createss the actual control. This method is overridden by all specific controls. (I'm using a slight simplification here)

You could do the same: Implement a abstract CreateWindowControl which creates the actual GUI object. Call it from TControl and voila...

A component chart exists in the FPC docs. It's in PostScript (really easy) and displays at the moment the classes in the FCL, together with their status.

The look is more or less the look of the Delphi Class Chart.

(get me talking and you can't shut me up)

Sure we can. Just throw you out of the mailing list :-) Not very refined, but it would do the job :-)

Michael V.

if you are going to put all gtk calls (not only signaling) in one file, the only thing you are doing is complicating my life for no real gain as far I can see.

Sergio