Hello all,

Working from memory (I am at work now, away from the code) the GTK stuff right now is localized to the GTKINT.PP file. I assume that when QT, Win32 native, etc. are put in, that they will be likewise in a QTINT.PP and a WIN32INT.PP file. Will these files be located in the LCL directory, or will the LCL have further subdirectories for each of these? Also, the GTK files are in \pp\source\gtk right now. I assume there will be a \pp\source\qt and \pp\source\win32 as well? Or will WIN32 stay as it is under RTL and FCL? I am a bit curious, but I would like to look at the WIN32 API this weekend, as I am a lot more familiar with it than GTK. I want to know where to put things, and where to access things that are already there.

Jeff.

Makes perfect sense to me..

I can bang in a few qt widgets once in a while also this way.

Cliff

Well I need to draw up what we need here but this is the way it needs to go.

1. I have to implement the anchors concept in the controls that are supposed to have them.

2. I have to implement the align property in controls that are supposed to have them.

3. Only certain types of controls, containers are allowed to contain widgets. This means that I will have to implement some type of logic to determine when and to what controls to apply the fixed widget.

something like in the control load a fixed widget if one does not yet exist and the parent control is a container type widget.

4. The properties for the heigth width top and left are somehow getting hosed. I have not tracked the source of that one as of yet. This should go away once I redo all of that stuff.

5. a control without a anchor set or an align set should not fire a resize event or have one fired for it. For instance a button does not have a published resize event. It does in the existing implementation but it should not for delphi compatibility reasons.

Cliff

I would also like to re-hammer the alignment code tonight which is well, all hosed..

Cliff

Sounds good.

I have made some changes to Lazarus that I would like to commit. I can compile so I know they compile but I can't run so I'm not sure what they do. I'll commit anyways.

Of course this goes against everything I've been saying in the last few days but I have no choice.

Shane

>> "Michael A. Hess" 07/30 12:12 PM >>>

Shane Miller wrote

That sounds fine Michael. Rename the gtkint.pp file to Interface.pp and we can use it like that. I was planning on doing a IFDEEF, but it would be better adjusting our path.

OK. I'll do some of that rearranging tonight. I'll also look at consolidating the IntSendMessage into one routine. Maybe a combination of 2 and 3. It sends Self and a pointer for whatever. I'll have to look at that.

Cliff,

You might take a look at the Notebook component that I created. It is interesting because the alignment problem exists with the notebook component on a form, but it doesn't exist with a button on a page. I can put a button anywhere on the notebook page and it works fine. But the notebook component seems to want to align itself on a form in the upper left hand corner and I can't move it. So I don't know what the difference is between the way the normal alignment code works and the alignment code for the TPage control that the notebook is using. But there is something different. Might be somewhat helpful.

BTW, I won't get any coding done this weekend. I am going camping with my family. But I will finish moving the gtk code to the gtkint units Sunday or Monday evening and commit it.

Curtis

----------------------------------
Curtis White
Curtis White
http://www.teleport.com/~osiriz/
----------------------------------

Having the independent code also in a directory looks more cleaner, in the base lcl dir you can place then some readme and a main Makefile. Look at the fcl which also has the independent part in a inc/ directory. And when needed you can even then make a i386/ alpha/ etc. dir like in the RTL ;)

That sounds fine Michael. Rename the gtkint.pp file to Interface.pp and we can use it like that. I was planning on doing a IFDEEF, but it would be better adjusting our path.

Shane

>> "Michael A. Hess" 07/30 10:41 AM >>>

You beat me to it. :-)

I was going to talk with Cliff about this very thing. Since we have already broken out the source into .pp's and .inc's and separated the component library into lcl I think it is also a good time to separate the API stuff.

The /pp/source/gtk should probably stay as it is and we would add /pp/source/qt /pp/source/gnome etc.

However in the lcl we should break out the gtk code into separate directories lcl/gtk lcl/qt lcl/gnome etc.
We should do this before we get to much further along.

Shane,

Another thing we should probably do now is adjust how the interface.pp and gtkint.pp interaction works. I mentioned this before. We should eliminate the interface.pp file and just rename the gtkint.pp class to be the same as found in the interface unit. Then we place these files into the lcl/gtk directory with it's own make file. As we move along fewer and fewer changes will be required of the interface files and they could be compiled separately from the lcl. Then when a user needs to build their app they set make to include the lcl/gtk directory and compile their program.

Now when we make the qt, motif, gnome, whatever, ports we use the exact same name for the .pp file but place this and the specific .inc's into their individual directories again with their own makefiles. Now when a user wants to build a version of their app for qt all they need to do is adjust their make file to point to the correct lcl subdirectory to use the correct unit. No code will be needed to be changed and no {$ifdef} is required. We can even make up a template make file that you type

make gtk

or

make qt

and it will build the users application and use the correct api units to link the program.

Then as we add more GUI APIs we don't need to change any code all we need to do is write the interface code for that API. Place it into an appropriate subdirectory and link against those units. No modifications to the lcl are required. The lcl wouldn't even need to be recompiled to use different API's.

I second or third (or whatever) that :-)

Curtis

----------------------------------
Curtis White
Curtis White
http://www.teleport.com/~osiriz/
----------------------------------

That is a good idea. We may want to consider creating a directory structure similar to the RTL and FCL, where we have a directory for each platform (or in our case, each different type of api). So we would have a lcl/gtk, lcl/qt, and lcl/win32 directories that contain the gtkint code for each of those api's. This will help us keep things organized as to what code is platform independent and what code isn't. All the code in the lcl directory would be platform independent. Then when we want to port to another platform, we just have to port the code from either the gtk, qt, or win32 directory, whichever is closest to the new platform. What do you all think?

Curtis

----------------------------------
Curtis White
Curtis White
http://www.teleport.com/~osiriz/
----------------------------------

Shane Miller wrote

That sounds fine Michael. Rename the gtkint.pp file to Interface.pp and we can use it like that. I was planning on doing a IFDEEF, but it would be better adjusting our path.

OK. I'll do some of that rearranging tonight. I'll also look at consolidating the IntSendMessage into one routine. Maybe a combination of 2 and 3. It sends Self and a pointer for whatever. I'll have to look at that.

You beat me to it. :-)

I was going to talk with Cliff about this very thing. Since we have already broken out the source into .pp's and .inc's and separated the component library into lcl I think it is also a good time to separate the API stuff.

The /pp/source/gtk should probably stay as it is and we would add /pp/source/qt /pp/source/gnome etc.

However in the lcl we should break out the gtk code into separate directories lcl/gtk lcl/qt lcl/gnome etc.
We should do this before we get to much further along.

Shane,

Another thing we should probably do now is adjust how the interface.pp and gtkint.pp interaction works. I mentioned this before. We should eliminate the interface.pp file and just rename the gtkint.pp class to be the same as found in the interface unit. Then we place these files into the lcl/gtk directory with it's own make file. As we move along fewer and fewer changes will be required of the interface files and they could be compiled separately from the lcl. Then when a user needs to build their app they set make to include the lcl/gtk directory and compile their program.

Now when we make the qt, motif, gnome, whatever, ports we use the exact same name for the .pp file but place this and the specific .inc's into their individual directories again with their own makefiles. Now when a user wants to build a version of their app for qt all they need to do is adjust their make file to point to the correct lcl subdirectory to use the correct unit. No code will be needed to be changed and no {$ifdef} is required. We can even make up a template make file that you type

make gtk

or

make qt

and it will build the users application and use the correct api units to link the program.

Then as we add more GUI APIs we don't need to change any code all we need to do is write the interface code for that API. Place it into an appropriate subdirectory and link against those units. No modifications to the lcl are required. The lcl wouldn't even need to be recompiled to use different API's.

Is a overloaded function what we need here?

Cliff