Sign in Join

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

Mailing lists / lazarus / 1999-04

gtk

15 messages · 7 people ·

Reply by email Subscribe to this list Your subscription

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

Cliff Baeseman
to Michael Van Canneyt: Yes, but it's more than that, according to Sergio. The whole should be packaged *with*…

No I think the library should be available but it does not have to be packaged with the fcl.

Our library is very FCL dependant but the visual component should be swapable in lazarus between
gui tool kits. I intend to move towards a swapable component library in lazarus. My intent is
that lazarus does not care about the component library. Our ide is built from our GTK library but
I do not wish to preclude the use of other other toolkits.

Cliff

Earlier message 132 lines
-----Original Message----- From: Behalf Of Michael Van Canneyt Sent: Friday, April 30, 1999 8:53 AM To: Lazarus project Subject: RE: gtk On Fri, 30 Apr 1999, Cliff Baeseman wrote: > Not sure If I get the true meaning of all of this but if you are referring > to the visual components being seperated into toolkit specific directories I > have to tend to agree. At some point in time I see someone porting to other > toolkits such as QT etc and these should also desend from the FCL. It is > the component writers responsibility to interact with the FCL.. Yes, but it's more than that, according to Sergio. The whole should be packaged *with* the FCL, not just 'built on top of'. Michael. > > Cliff > > -----Original Message----- > From: Behalf Of Michael Van > Canneyt > Sent: Friday, April 30, 1999 3:07 AM > To: Sergio A. Kessler > Cc: Lazarus project > Subject: Re: gtk > > > > > On Thu, 29 Apr 1999, Sergio A. Kessler wrote: > > > Michael Van Canneyt el d�a Thu, 29 Apr 1999 > > 09:37:16 +0200 (W. Europe Daylight Time), escribi�: > > > > >> btw, Michael, I'm the only one that think that the FCL is the > > >> "rigth thing to do (tm)", and then (or parallely) building the > > >> IDE (call it Megido, Lazarus, etc) from the FCL ?? > > > > > >Lazarus builds on top of the FCL. > > >Megido will take a completely different approach. > > > > yes, I know this, but why I do not understand is why the FCL > > is not populated with GUI components from the Lazarus team > > (I understand the case for Megido :) > > see below > > > > > >> What is the future of the FCL if everyone and his brother > > >> are doing components separately from the FCL ? > > >> > > >> The FCL has a roadmap ? > > >Yes, it has. > > > > > >I see the FCL as a subset of VCL which is Non-GUI, non Toolkit > > >specific. So All non-gui components can go in the FCL. > > > > but ... it is a bad idea to put GUI components using the GTK > > in the linux directory, and put GUI components using the win > > API in the win32 directory and so on ?? > > > > thus making a real VCL clone > > > > Even you can divide the linux directory in GTK, QT, Motif, etc > > the people interested will fill up this directories. > > > > It is a bad idea ? > > Why no GUI components ? > > What is the intrinsic difference betwen a GUI component for > > linux and one unit of the RTL for linux ? > > Because GUI stuff depends not only on a OS, but also on toolkits > (Native Xlib, Qt, GTK, X-Forms, Fox etc) which is highly a matter > of personal taste. The non-gui stuff can be implemented relatively > OS-independent. > > > > Also I think this is good to prevent code forking, rigth now, > > there is Megido, Lazarus and Nico that want to go alone, > > tomorow you will have dozen teams doing the same, and yes, > > competition is good, but this is beginning to sound like > > nonsense, just because the FCL, *IMO* has left this hole. > > > > I'm missing something ?? > > Yes, if we do as you suggest > 1) the FCL will be much harder to maintain. > (Agreed, this is largely an organizatorial problem, > which can be solved ) > > 2) We then must take 1 project (e.g. Lazarus) and say > 'this is the one' > and I am not sure this is 'The right thing (c)' :) > > But I will speak with some other developers, because you seem quite > convinced that we should do this, and maybe the other core developers > agree more with you than with me... > > I will propose them your stuff from the mailing list: > > /fcl/win32 > /linux/gtk > /Qt > /x-forms > /Xlib > > I'll post any results to lazarus.com > > Michael. > > _________________________________________________________________ > To unsubscribe: mail with > "unsubscribe" as the Subject > > _________________________________________________________________ > To unsubscribe: mail with > "unsubscribe" as the Subject > _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject

Reply by email

Cliff Baeseman
to Michael Van Canneyt: see below Because GUI stuff depends not only on a OS, but also on toolkits (Native Xlib,…

Not sure If I get the true meaning of all of this but if you are referring to the visual components being seperated into toolkit specific directories I have to tend to agree. At some point in time I see someone porting to other toolkits such as QT etc and these should also desend from the FCL. It is the component writers responsibility to interact with the FCL..

Cliff

Earlier message 95 lines
-----Original Message----- From: Behalf Of Michael Van Canneyt Sent: Friday, April 30, 1999 3:07 AM To: Sergio A. Kessler Cc: Lazarus project Subject: Re: gtk On Thu, 29 Apr 1999, Sergio A. Kessler wrote: > Michael Van Canneyt el d�a Thu, 29 Apr 1999 > 09:37:16 +0200 (W. Europe Daylight Time), escribi�: > > >> btw, Michael, I'm the only one that think that the FCL is the > >> "rigth thing to do (tm)", and then (or parallely) building the > >> IDE (call it Megido, Lazarus, etc) from the FCL ?? > > > >Lazarus builds on top of the FCL. > >Megido will take a completely different approach. > > yes, I know this, but why I do not understand is why the FCL > is not populated with GUI components from the Lazarus team > (I understand the case for Megido :) see below > > >> What is the future of the FCL if everyone and his brother > >> are doing components separately from the FCL ? > >> > >> The FCL has a roadmap ? > >Yes, it has. > > > >I see the FCL as a subset of VCL which is Non-GUI, non Toolkit > >specific. So All non-gui components can go in the FCL. > > but ... it is a bad idea to put GUI components using the GTK > in the linux directory, and put GUI components using the win > API in the win32 directory and so on ?? > > thus making a real VCL clone > > Even you can divide the linux directory in GTK, QT, Motif, etc > the people interested will fill up this directories. > > It is a bad idea ? > Why no GUI components ? > What is the intrinsic difference betwen a GUI component for > linux and one unit of the RTL for linux ? Because GUI stuff depends not only on a OS, but also on toolkits (Native Xlib, Qt, GTK, X-Forms, Fox etc) which is highly a matter of personal taste. The non-gui stuff can be implemented relatively OS-independent. > Also I think this is good to prevent code forking, rigth now, > there is Megido, Lazarus and Nico that want to go alone, > tomorow you will have dozen teams doing the same, and yes, > competition is good, but this is beginning to sound like > nonsense, just because the FCL, *IMO* has left this hole. > > I'm missing something ?? Yes, if we do as you suggest 1) the FCL will be much harder to maintain. (Agreed, this is largely an organizatorial problem, which can be solved ) 2) We then must take 1 project (e.g. Lazarus) and say 'this is the one' and I am not sure this is 'The right thing (c)' :) But I will speak with some other developers, because you seem quite convinced that we should do this, and maybe the other core developers agree more with you than with me... I will propose them your stuff from the mailing list: /fcl/win32 /linux/gtk /Qt /x-forms /Xlib I'll post any results to lazarus.com Michael. _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject

Reply by email

Sergio A. Kessler

"Michael A. Hess" el d�a Fri, 30 Apr 1999 11:10:53 -0400, escribi�:

Show quoted text 7 lines
Cliff Baeseman wrote: > > No I think the library should be available but it does not have to be > packaged with the fcl. Agreed, Free Pascal and the FCL should not be tied to a library, API, or whatever you want to call it.

exactly !

Show quoted text 10 lines
> Our library is very FCL dependant but the visual component should be > swapable in lazarus between gui tool kits. I intend to move towards > a swapable component library in lazarus. My intent is > that lazarus does not care about the component library. Our ide is > built from our GTK library but I do not wish to preclude the use of > other other toolkits. Excellent! That is what I was eluding to. At this point it is tied more to GTK but once the IDE is finished and we have something to work with we can generalize the components. Right now the IDE is the thing. :-)

this is also my point ! (I'm so bad explaining things ? :)

I will try again:

Suppose you want to implement the ShowMessage function that is in dialogs unit.
And you want implemented in win32 and linux/gtk and linux/qt. Then you create a dialogs.pp in the fcl/win32 directory and implement ShowMessage using the win32 api, you do the same in fcl/linux/gtk (or should be just fcl/gtk ??) but using the gtk api, the same with fcl/linux/qt ...

My *only* difference with Lazarus is _very_ minimal and is only where the archives resides, just that. I think that stdcontrols and controls for example should be in fcl/linux/gtk. I don't think that a relocation of some archives slowdown the Lazarus project, all the contrary.

*Someone* interested in Lazarus for win32, just have to implement what is in fcl/linux/gtk in fcl/win32, recompile Lazarus and voil�, Lazarus for win32.
This also prevent working with a library full of ifdefs wich is a mess as Nico pointed out.

sound too bad ?

Sergio

Reply by email

Michael Van Canneyt
Sergio A. Kessler wrote 13 lines
Michael Van Canneyt el d�a Thu, 29 Apr 1999 09:37:16 +0200 (W. Europe Daylight Time), escribi�: >> btw, Michael, I'm the only one that think that the FCL is the >> "rigth thing to do (tm)", and then (or parallely) building the >> IDE (call it Megido, Lazarus, etc) from the FCL ?? > >Lazarus builds on top of the FCL. >Megido will take a completely different approach. yes, I know this, but why I do not understand is why the FCL is not populated with GUI components from the Lazarus team (I understand the case for Megido :)

see below

Show quoted text 23 lines
>> What is the future of the FCL if everyone and his brother >> are doing components separately from the FCL ? >> >> The FCL has a roadmap ? >Yes, it has. > >I see the FCL as a subset of VCL which is Non-GUI, non Toolkit >specific. So All non-gui components can go in the FCL. but ... it is a bad idea to put GUI components using the GTK in the linux directory, and put GUI components using the win API in the win32 directory and so on ?? thus making a real VCL clone Even you can divide the linux directory in GTK, QT, Motif, etc the people interested will fill up this directories. It is a bad idea ? Why no GUI components ? What is the intrinsic difference betwen a GUI component for linux and one unit of the RTL for linux ?

Because GUI stuff depends not only on a OS, but also on toolkits (Native Xlib, Qt, GTK, X-Forms, Fox etc) which is highly a matter of personal taste. The non-gui stuff can be implemented relatively OS-independent.

Show quoted text 7 lines
Also I think this is good to prevent code forking, rigth now, there is Megido, Lazarus and Nico that want to go alone, tomorow you will have dozen teams doing the same, and yes, competition is good, but this is beginning to sound like nonsense, just because the FCL, *IMO* has left this hole. I'm missing something ??

Yes, if we do as you suggest
1) the FCL will be much harder to maintain.
(Agreed, this is largely an organizatorial problem, which can be solved )

2) We then must take 1 project (e.g. Lazarus) and say 'this is the one'
and I am not sure this is 'The right thing (c)' :)

But I will speak with some other developers, because you seem quite convinced that we should do this, and maybe the other core developers agree more with you than with me...

I will propose them your stuff from the mailing list:

/fcl/win32
/linux/gtk
/Qt
/x-forms
/Xlib

I'll post any results to lazarus.com

Michael.

Reply by email

Michael A. Hess
to Cliff Baeseman: No I think the library should be available but it does not have to be packaged with the…
Cliff Baeseman wrote
No I think the library should be available but it does not have to be packaged with the fcl.

Agreed, Free Pascal and the FCL should not be tied to a library, API, or whatever you want to call it.

Show quoted text 6 lines
Our library is very FCL dependant but the visual component should be swapable in lazarus between gui tool kits. I intend to move towards a swapable component library in lazarus. My intent is that lazarus does not care about the component library. Our ide is built from our GTK library but I do not wish to preclude the use of other other toolkits.

Excellent! That is what I was eluding to. At this point it is tied more to GTK but once the IDE is finished and we have something to work with we can generalize the components. Right now the IDE is the thing. :-)

==== Programming my first best destiny! ==== Michael A. Hess Miracle Concepts, Inc. http://www.miraclec.com

Reply by email

Michael Van Canneyt
to Cliff Baeseman: Not sure If I get the true meaning of all of this but if you are referring to the visual…
Cliff Baeseman wrote 5 lines
Not sure If I get the true meaning of all of this but if you are referring to the visual components being seperated into toolkit specific directories I have to tend to agree. At some point in time I see someone porting to other toolkits such as QT etc and these should also desend from the FCL. It is the component writers responsibility to interact with the FCL..

Yes, but it's more than that, according to Sergio. The whole should be packaged *with* the FCL, not just 'built on top of'.

Michael.

Show quoted text 103 lines
Cliff -----Original Message----- From: Behalf Of Michael Van Canneyt Sent: Friday, April 30, 1999 3:07 AM To: Sergio A. Kessler Cc: Lazarus project Subject: Re: gtk On Thu, 29 Apr 1999, Sergio A. Kessler wrote: > Michael Van Canneyt el d�a Thu, 29 Apr 1999 > 09:37:16 +0200 (W. Europe Daylight Time), escribi�: > > >> btw, Michael, I'm the only one that think that the FCL is the > >> "rigth thing to do (tm)", and then (or parallely) building the > >> IDE (call it Megido, Lazarus, etc) from the FCL ?? > > > >Lazarus builds on top of the FCL. > >Megido will take a completely different approach. > > yes, I know this, but why I do not understand is why the FCL > is not populated with GUI components from the Lazarus team > (I understand the case for Megido :) see below > > >> What is the future of the FCL if everyone and his brother > >> are doing components separately from the FCL ? > >> > >> The FCL has a roadmap ? > >Yes, it has. > > > >I see the FCL as a subset of VCL which is Non-GUI, non Toolkit > >specific. So All non-gui components can go in the FCL. > > but ... it is a bad idea to put GUI components using the GTK > in the linux directory, and put GUI components using the win > API in the win32 directory and so on ?? > > thus making a real VCL clone > > Even you can divide the linux directory in GTK, QT, Motif, etc > the people interested will fill up this directories. > > It is a bad idea ? > Why no GUI components ? > What is the intrinsic difference betwen a GUI component for > linux and one unit of the RTL for linux ? Because GUI stuff depends not only on a OS, but also on toolkits (Native Xlib, Qt, GTK, X-Forms, Fox etc) which is highly a matter of personal taste. The non-gui stuff can be implemented relatively OS-independent. > Also I think this is good to prevent code forking, rigth now, > there is Megido, Lazarus and Nico that want to go alone, > tomorow you will have dozen teams doing the same, and yes, > competition is good, but this is beginning to sound like > nonsense, just because the FCL, *IMO* has left this hole. > > I'm missing something ?? Yes, if we do as you suggest 1) the FCL will be much harder to maintain. (Agreed, this is largely an organizatorial problem, which can be solved ) 2) We then must take 1 project (e.g. Lazarus) and say 'this is the one' and I am not sure this is 'The right thing (c)' :) But I will speak with some other developers, because you seem quite convinced that we should do this, and maybe the other core developers agree more with you than with me... I will propose them your stuff from the mailing list: /fcl/win32 /linux/gtk /Qt /x-forms /Xlib I'll post any results to lazarus.com Michael. _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject

Reply by email

Sergio Kessler
to Sergio A. Kessler: "Michael A. Hess" el d�a Fri, 30 Apr 1999 11:10:53 -0400, escribi�: exactly ! this…
"Sergio A. Kessler" wrote 50 lines
"Michael A. Hess" el d�a Fri, 30 Apr 1999 11:10:53 -0400, escribi�: >Cliff Baeseman wrote: >> >> No I think the library should be available but it does not have to be >> packaged with the fcl. > >Agreed, Free Pascal and the FCL should not be tied to a library, API, or >whatever you want to call it. exactly ! >> Our library is very FCL dependant but the visual component should be >> swapable in lazarus between gui tool kits. I intend to move towards >> a swapable component library in lazarus. My intent is >> that lazarus does not care about the component library. Our ide is >> built from our GTK library but I do not wish to preclude the use of >> other other toolkits. > >Excellent! That is what I was eluding to. At this point it is tied more >to GTK but once the IDE is finished and we have something to work with >we can generalize the components. Right now the IDE is the thing. :-) this is also my point ! (I'm so bad explaining things ? :) I will try again: Suppose you want to implement the ShowMessage function that is in dialogs unit. And you want implemented in win32 and linux/gtk and linux/qt. Then you create a dialogs.pp in the fcl/win32 directory and implement ShowMessage using the win32 api, you do the same in fcl/linux/gtk (or should be just fcl/gtk ??) but using the gtk api, the same with fcl/linux/qt ... My *only* difference with Lazarus is _very_ minimal and is only where the archives resides, just that. I think that stdcontrols and controls for example should be in fcl/linux/gtk. I don't think that a relocation of some archives slowdown the Lazarus project, all the contrary. *Someone* interested in Lazarus for win32, just have to implement what is in fcl/linux/gtk in fcl/win32, recompile Lazarus and voil�, Lazarus for win32. This also prevent working with a library full of ifdefs wich is a mess as Nico pointed out. sound too bad ?

well, after re-reading my mail, I think I have left some holes.

My question is: can the FCL acommodate GUI components ?

I think, at least, is worth trying.

I don't know how it should be organized, but if could be done, it may be a great thing.

how 'bout:

fcl/
linux/
win32
inc/ (the more code here, the better, of course) ...
gui/
gtk/
win32/
qt/
...

Of course, I'm saying that fcl/gui/win32 must be filled by someone interested, not for anybody else.
The lazarus team (and eventually me, but I'm at the learning stage) can work in the fcl/gui/gtk.
When someone ask: 'there is a Lazarus for qt ?' one can say: 'yes, implement all the remaining parts in fcl/gui/qt and you should be able to make a Lazarus for qt'

Sergio

| Sergio A. Kessler http://perio.unlp.edu.ar/~sergio -O_O- Keep working at it... you will either succeed, or become an expert.

Reply by email

Shane Miller

So what we are saying it that we should create generic units. For example in the TForms class, instead of referencing a fcomponent which is a pgtkwidget (pointer to a GTRK widget) we should simply make it a pointer, then in the gtk directory, we would create another unit that actually sets the pointer to point to a gtk widget. In the qt directory, we would create a unit to set the pointer to point to a qt form. Is that the idea? If so, I think we still should first create an editor (Lazarus) THEN move the code to the appropriate units. I agree that this should be kept in mind though when coding.

I say lets concentrate on getting an IDE out (we could use some help) and then we'll start pulling code out and seperating everything so it's easy to implement with qt and others...

Shane

The other members of the Free Pascal team seem to agree with you. The question is then 'how' and 'what' to place 'where' ?

WHERE:
fcl/
linux/
win32
inc/ (the more code here, the better, of course) ...
gui/
gtk/
win32/
qt/
inc/ (independent toolkit parts, as Peter pointed out) ...

this is just a proposed implementation, feel free to modify or change it as desired.

WHAT: I think this will require Lazarus cooperation, there is a good amount of code to be put under fcl/gui/gtk and fcl/gui/inc already.

HOW: cp stdcontrols.pp fcl/gui/gtk ... and so on :) if you have mc is even more easy :)

btw, attached is a patch to makefile.fpc, it solve the error "dirname: too may arguments" in my StarBuck 5.9.7 (aka RedHat 6.0 beta), RedHat do not install gcc, it install egcs (will be renamed gcc in the future according to rms). Should work with gcc installed (I hope).

this is the rigth mailing list to post this kind of patchs ? Isn't there a mailing list for FPC ?

Sergio

Reply by email

Peter Vreman
to Sergio A. Kessler: "Michael A. Hess" el d�a Fri, 30 Apr 1999 11:10:53 -0400, escribi�: exactly ! this…
you wrote 74 lines
"Sergio A. Kessler" wrote: > > "Michael A. Hess" el d�a Fri, 30 Apr 1999 11:10:53 > -0400, escribi�: > > >Cliff Baeseman wrote: > >> > >> No I think the library should be available but it does not have to be > >> packaged with the fcl. > > > >Agreed, Free Pascal and the FCL should not be tied to a library, API, or > >whatever you want to call it. > > exactly ! > > >> Our library is very FCL dependant but the visual component should be > >> swapable in lazarus between gui tool kits. I intend to move towards > >> a swapable component library in lazarus. My intent is > >> that lazarus does not care about the component library. Our ide is > >> built from our GTK library but I do not wish to preclude the use of > >> other other toolkits. > > > >Excellent! That is what I was eluding to. At this point it is tied more > >to GTK but once the IDE is finished and we have something to work with > >we can generalize the components. Right now the IDE is the thing. :-) > > this is also my point ! (I'm so bad explaining things ? :) > > I will try again: > > Suppose you want to implement the ShowMessage function that is in > dialogs unit. > And you want implemented in win32 and linux/gtk and linux/qt. > Then you create a dialogs.pp in the fcl/win32 directory and > implement ShowMessage using the win32 api, you do the same in > fcl/linux/gtk (or should be just fcl/gtk ??) but using the > gtk api, the same with fcl/linux/qt ... > > My *only* difference with Lazarus is _very_ minimal and is only > where the archives resides, just that. I think that stdcontrols > and controls for example should be in fcl/linux/gtk. > I don't think that a relocation of some archives slowdown the > Lazarus project, all the contrary. > > *Someone* interested in Lazarus for win32, just have to implement > what is in fcl/linux/gtk in fcl/win32, recompile Lazarus and voil�, > Lazarus for win32. > This also prevent working with a library full of ifdefs wich > is a mess as Nico pointed out. > > sound too bad ? well, after re-reading my mail, I think I have left some holes. My question is: can the FCL acommodate GUI components ? I think, at least, is worth trying. I don't know how it should be organized, but if could be done, it may be a great thing. how 'bout: fcl/ linux/ win32 inc/ (the more code here, the better, of course) ... gui/ gtk/ win32/ qt/ ...

I think that there should also be a gui/inc/ if there are toolkit independent parts. Then all the required things for FCL GUI components are in the fcl/gui directory.

Reply by email

Sergio A. Kessler

Michael Van Canneyt el d�a Mon, 3 May 1999
08:57:30 +0200 (W. Europe Daylight Time), escribi�:

Show quoted text 9 lines
> well, after re-reading my mail, I think I have left > some holes. > > My question is: can the FCL acommodate GUI components ? > > I think, at least, is worth trying. The other members of the Free Pascal team seem to agree with you. The question is then 'how' and 'what' to place 'where' ?

WHERE:
fcl/
linux/
win32
inc/ (the more code here, the better, of course) ...
gui/
gtk/
win32/
qt/
inc/ (independent toolkit parts, as Peter pointed out) ...

this is just a proposed implementation, feel free to modify or change it as desired.

WHAT: I think this will require Lazarus cooperation, there is a good amount of code to be put under fcl/gui/gtk and fcl/gui/inc already.

HOW: cp stdcontrols.pp fcl/gui/gtk ... and so on :) if you have mc is even more easy :)

btw, attached is a patch to makefile.fpc, it solve the error "dirname: too may arguments" in my StarBuck 5.9.7 (aka RedHat 6.0 beta), RedHat do not install gcc, it install egcs (will be renamed gcc in the future according to rms). Should work with gcc installed (I hope).

this is the rigth mailing list to post this kind of patchs ? Isn't there a mailing list for FPC ?

Sergio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bin00000.bin
Type: application/octet-stream
Size: 497 bytes
Desc: "makefile.fpc.patch"
Url : http://localhost/pipermail/lazarus/attachments/19990503/b7d5080e/bin00000.bin

Reply by email

Michael Van Canneyt
to Sergio Kessler: well, after re-reading my mail, I think I have left some holes. My question is: can the…
Sergio Kessler wrote 60 lines
"Sergio A. Kessler" wrote: > > "Michael A. Hess" el d�a Fri, 30 Apr 1999 11:10:53 > -0400, escribi�: > > >Cliff Baeseman wrote: > >> > >> No I think the library should be available but it does not have to be > >> packaged with the fcl. > > > >Agreed, Free Pascal and the FCL should not be tied to a library, API, or > >whatever you want to call it. > > exactly ! > > >> Our library is very FCL dependant but the visual component should be > >> swapable in lazarus between gui tool kits. I intend to move towards > >> a swapable component library in lazarus. My intent is > >> that lazarus does not care about the component library. Our ide is > >> built from our GTK library but I do not wish to preclude the use of > >> other other toolkits. > > > >Excellent! That is what I was eluding to. At this point it is tied more > >to GTK but once the IDE is finished and we have something to work with > >we can generalize the components. Right now the IDE is the thing. :-) > > this is also my point ! (I'm so bad explaining things ? :) > > I will try again: > > Suppose you want to implement the ShowMessage function that is in > dialogs unit. > And you want implemented in win32 and linux/gtk and linux/qt. > Then you create a dialogs.pp in the fcl/win32 directory and > implement ShowMessage using the win32 api, you do the same in > fcl/linux/gtk (or should be just fcl/gtk ??) but using the > gtk api, the same with fcl/linux/qt ... > > My *only* difference with Lazarus is _very_ minimal and is only > where the archives resides, just that. I think that stdcontrols > and controls for example should be in fcl/linux/gtk. > I don't think that a relocation of some archives slowdown the > Lazarus project, all the contrary. > > *Someone* interested in Lazarus for win32, just have to implement > what is in fcl/linux/gtk in fcl/win32, recompile Lazarus and voil�, > Lazarus for win32. > This also prevent working with a library full of ifdefs wich > is a mess as Nico pointed out. > > sound too bad ? well, after re-reading my mail, I think I have left some holes. My question is: can the FCL acommodate GUI components ? I think, at least, is worth trying.

The other members of the Free Pascal team seem to agree with you. The question is then 'how' and 'what' to place 'where' ?

Michael

Reply by email

Cliff Baeseman
to Shane Miller: So what we are saying it that we should create generic units. For example in the TForms…

Yep I agree the IDE should take precedence for now. I am very tired of using a text editor to work on files what a pain in the For now I see the big hang up in control resizing and placement. We have to figure out some generic routines to
handle the object placement. The fixed object works but GTK is supposed to resize the children for us. Somehow we are losing this functionality.

Cliff

Earlier message 71 lines
-----Original Message----- From: Shane Miller Sent: Monday, May 03, 1999 1:48 PM To: ; ; Subject: Re: gtk So what we are saying it that we should create generic units. For example in the TForms class, instead of referencing a fcomponent which is a pgtkwidget (pointer to a GTRK widget) we should simply make it a pointer, then in the gtk directory, we would create another unit that actually sets the pointer to point to a gtk widget. In the qt directory, we would create a unit to set the pointer to point to a qt form. Is that the idea? If so, I think we still should first create an editor (Lazarus) THEN move the code to the appropriate units. I agree that this should be kept in mind though when coding. I say lets concentrate on getting an IDE out (we could use some help) and then we'll start pulling code out and seperating everything so it's easy to implement with qt and others... Shane >The other members of the Free Pascal team seem to agree with you. >The question is then 'how' and 'what' to place 'where' ? WHERE: fcl/ linux/ win32 inc/ (the more code here, the better, of course) ... gui/ gtk/ win32/ qt/ inc/ (independent toolkit parts, as Peter pointed out) ... this is just a proposed implementation, feel free to modify or change it as desired. WHAT: I think this will require Lazarus cooperation, there is a good amount of code to be put under fcl/gui/gtk and fcl/gui/inc already. HOW: cp stdcontrols.pp fcl/gui/gtk ... and so on :) if you have mc is even more easy :) btw, attached is a patch to makefile.fpc, it solve the error "dirname: too may arguments" in my StarBuck 5.9.7 (aka RedHat 6.0 beta), RedHat do not install gcc, it install egcs (will be renamed gcc in the future according to rms). Should work with gcc installed (I hope). this is the rigth mailing list to post this kind of patchs ? Isn't there a mailing list for FPC ? Sergio _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject

Reply by email

Peter Vreman
to Sergio A. Kessler: Michael Van Canneyt el d�a Mon, 3 May 1999 08:57:30 +0200 (W. Europe Daylight Time),…
Show quoted text 39 lines
>> well, after re-reading my mail, I think I have left >> some holes. >> >> My question is: can the FCL acommodate GUI components ? >> >> I think, at least, is worth trying. > >The other members of the Free Pascal team seem to agree with you. >The question is then 'how' and 'what' to place 'where' ? WHERE: fcl/ linux/ win32 inc/ (the more code here, the better, of course) ... gui/ gtk/ win32/ qt/ inc/ (independent toolkit parts, as Peter pointed out) ... this is just a proposed implementation, feel free to modify or change it as desired. WHAT: I think this will require Lazarus cooperation, there is a good amount of code to be put under fcl/gui/gtk and fcl/gui/inc already. HOW: cp stdcontrols.pp fcl/gui/gtk ... and so on :) if you have mc is even more easy :) btw, attached is a patch to makefile.fpc, it solve the error "dirname: too may arguments" in my StarBuck 5.9.7 (aka RedHat 6.0 beta), RedHat do not install gcc, it install egcs (will be renamed gcc in the future according to rms). Should work with gcc installed (I hope).

I already fixed it, i've now a partly debian 2.2 system, with also egcs as gcc ;)

this is the rigth mailing list to post this kind of patchs ? Isn't there a mailing list for FPC ?

There are even 4 lists ;)

See:

http://vekoll.saturnus.vein.hu/mailman/listinfo/fpc-pascal http://vekoll.saturnus.vein.hu/mailman/listinfo/fpc-devel http://vekoll.saturnus.vein.hu/mailman/listinfo/fpc-other http://vekoll.saturnus.vein.hu/mailman/listinfo/fpc-announce

Peter

Reply by email

Sergio A. Kessler

"Shane Miller" el d�a Mon, 03 May 1999 13:47:32 -0500, escribi�:

So what we are saying it that we should create generic units. For example

in the TForms class, instead of referencing a fcomponent which is a pgtkwidget (pointer to a GTRK widget) we should simply make it a pointer, then in the gtk directory, we would create another unit that actually sets the pointer to point to a gtk widget. In the qt directory, we would create a unit to set the pointer to point to a qt form. Is that the idea?

Nope, *I* don't think so ... (at least for now)

If so, I think we still should first create an editor (Lazarus) THEN move

the code to the appropriate units. I agree that this should be kept in mind though when coding.

my idea was just to move some files to the fcl/gui/gtk, just that for now.

I say lets concentrate on getting an IDE out (we could use some help) and

then we'll start pulling code out and seperating everything so it's easy to implement with qt and others...

ok ...

Show quoted text 38 lines
>The other members of the Free Pascal team seem to agree with you. >The question is then 'how' and 'what' to place 'where' ? WHERE: fcl/ linux/ win32 inc/ (the more code here, the better, of course) ... gui/ gtk/ win32/ qt/ inc/ (independent toolkit parts, as Peter pointed out) ... this is just a proposed implementation, feel free to modify or change it as desired. WHAT: I think this will require Lazarus cooperation, there is a good amount of code to be put under fcl/gui/gtk and fcl/gui/inc already. HOW: cp stdcontrols.pp fcl/gui/gtk ... and so on :) if you have mc is even more easy :) btw, attached is a patch to makefile.fpc, it solve the error "dirname: too may arguments" in my StarBuck 5.9.7 (aka RedHat 6.0 beta), RedHat do not install gcc, it install egcs (will be renamed gcc in the future according to rms). Should work with gcc installed (I hope). this is the rigth mailing list to post this kind of patchs ? Isn't there a mailing list for FPC ? Sergio

Reply by email

Michael A. Hess
to Shane Miller: So what we are saying it that we should create generic units. For example in the TForms…
Shane Miller wrote 8 lines
So what we are saying it that we should create generic units. For example in the TForms class, instead of referencing a fcomponent which is a pgtkwidget (pointer to a GTRK widget) we should simply make it a pointer, then in the gtk directory, we would create another unit that actually sets the pointer to point to a gtk widget. In the qt directory, we would create a unit to set the pointer to point to a qt form. Is that the idea?

Exactly. This was probably the best description yet.

If so, I think we still should first create an editor (Lazarus) THEN move the code to the appropriate units. I agree that this should be kept in mind though when coding.

I totally agree. As I have said before let's get a working IDE, which at this point seems to mean you and Cliff, and then and only then do we backup and move things around.

I say lets concentrate on getting an IDE out (we could use some help) and then we'll start pulling code out and seperating everything so it's easy to implement with qt and others...

Again I totally agree. I wish I could give you some more direct help but my time and efforts are being absorbed elsewhere at the moment. :-(

==== Programming my first best destiny! ==== Michael A. Hess Miracle Concepts, Inc. http://www.miraclec.com

Reply by email