<snip>

My first point of confusion comes with controls.pp. Why are the glib.pp, gdk.pp and gtk.pp units in the Interface Uses section of this unit?

They shouldn't be and in the future won't be. They were still there while we progressed with moving everything over to the gtkint.pp and associated .inc's. If there are not more gtk calls in controls.pp then they can be removed.

Doesn't this break the toolkit independence?

Yes.

The same holds true for vclglobals.pp. Are they even used anywhere, or could they be leftovers?

Again this is just due to the progress of moving to the independent versions of the code.

Correct. They are a means to communicate between the lcl and the API GUI code with is the interface code. Each API's set of interface code will have to honor this constants and try to call the correct API routines to match what these constants represent.

The colors a simply a sequence of RGB values. We choose to represent the colors in the same fashion that Delphi and Windows does.

$00BBGGRR

No specific reason other than some compatibility with Delphi. A conversion routine will only be required if the API in question uses a different layout to represent a color. For instance GTK uses record which is made up of 3 shorts to represent Red, Green and Blue.

Those styles have not been created yet. Go for it. :-)

Michael A. Hess wrote

They shouldn't be and in the future won't be. They were still there while we progressed with moving everything over to the gtkint.pp and associated .inc's. If there are not more gtk calls in controls.pp then they can be removed.

I have found that the references in Controls.pp and VCLGlobals.pp can be removed. There are some unused variable declarations in Controls.pp that have to be removed as well. The ones in StdControls cannot, though.

Those styles have not been created yet. Go for it. :-)

If I could get a handle on Gtk, I would try. I don't have any books on the subject, though, and the Gtk tutorial web page gives me a headache (reading from screen always does). ;^) Once I get enough of Interfaces.pp and the WinAPIInt.pp (vs. GkInt.pp, anyone got a better name?) done, I shouldn't have trouble doing it in that section, but to do the same for Gtk is beyond me right now.

Jeff.

I was hoping to try ti get a first pass at a native Win32 form going this weekend, but I am at a wall of misunderstanding that makes the great wall of China look like a parking curb. Maybe someone can help me out here.

Sorry for the long message, but it's the only way I can keep all this straight. It won't fit into my head!

This is an attempt to figure out the heirarchy of forms.pp as it stands now:

Forms.pp

  Interface
    Uses
      controls.pp
        Interface
          Uses
            glib.pp - GUI Toolkit Specific (Why is this here?)
            gdk.pp - GUI Toolkit Specific (Why is this here?)
            gtk.pp - GUI Toolkit Specific (Why is this here?)
            sysutils.pp  - No GUI Toolkit specific dependencies
            Classes.pp  - No GUI Toolkit specific dependencies
            vclglobals.pp
              Interface
                Uses
                  glib.pp - GUI Toolkit Specific (Why is this here?)
                  gdk.pp - GUI Toolkit Specific (Why is this here?)
                  gtk.pp - GUI Toolkit Specific (Why is this here?)
              End vclglobals.pp
            Graphics.pp
              Interface
                Uses
                  sysutils.pp  - No GUI Toolkit specific dependencies
                  classes.pp - No GUI Toolkit specific dependencies
                  vclglobals.pp
                    Interface
                      Uses
                        glib.pp - GUI Toolkit Specific (Why is this here?)
                        gdk.pp - GUI Toolkit Specific (Why is this here?)
                        gtk.pp - GUI Toolkit Specific (Why is this here?)
                    End vclglobals.pp
              Implementation
                Uses
                  Interfaces.pp
                    Interface
                      Uses
                        GTK - gtk - GUI Toolkit Specific
                        GTK - gdk - GUI Toolkit Specific
                        GTK - glib - GUI Toolkit Specific
                        GTK - gtkint - GUI Toolkit Specific
                        GTK - Controls - Stop drilldown to prevent

recursion
QT - messages - ???
End interfaces.pp
lmessages.pp

                    Interface
                      Uses
                        Classes - No GUI Toolkit specific dependencies
                        vclglobals
                          Interface
                            Uses
                              glib.pp - GUI Toolkit Specific (Why is this

here?)
gdk.pp - GUI Toolkit Specific (Why is this
here?)
gtk.pp - GUI Toolkit Specific (Why is this
here?)
End vclglobals.pp
End lmessages.pp
controls.pp - Stop drilldown to prevent recursion
Includes
graphicsobject.inc
graphic.inc
bitmap.inc
pen.inc
brush.inc
font.inc
canvas.inc
End grphics.pp
LMessages.pp
utrace.pp

        Implementation
          Uses
            Interfaces.pp
              Interfaces.pp
                Interface
                  Uses
                    GTK - gtk - GUI Toolkit Specific
                    GTK - gdk - GUI Toolkit Specific
                    GTK - glib - GUI Toolkit Specific
                    GTK - gtkint - GUI Toolkit Specific
                    GTK - Controls - Stop drilldown to prevent recursion
                    QT - messages - ???
                End interfaces.pp
          Includes
            controlsproc.inc
            contolcanvas.inc
            scrolledwindow.inc
            wincontrol.inc
            control.inc
            customcontrol.inc
        End Controls.pp
      vclglobals.pp
        Interface
          Uses
            glib.pp - GUI Toolkit Specific (Why is this here?)
            gdk.pp - GUI Toolkit Specific (Why is this here?)
            gtk.pp - GUI Toolkit Specific (Why is this here?)
        End vclglobals.pp
      classes.pp - No GUI Toolkit specific dependencies
      sysutils.pp - No GUI Toolkit specific dependencies
      graphics.pp
        Interface
          Uses
            sysutils.pp  - No GUI Toolkit specific dependencies
            classes.pp - No GUI Toolkit specific dependencies
            vclglobals.pp
              Interface
                Uses
                  glib.pp - GUI Toolkit Specific (Why is this here?)
                  gdk.pp - GUI Toolkit Specific (Why is this here?)
                  gtk.pp - GUI Toolkit Specific (Why is this here?)
              End vclglobals.pp
        Implementation
          Uses
            Interfaces.pp
              Interface
                Uses
                  GTK - gtk - GUI Toolkit Specific
                  GTK - gdk - GUI Toolkit Specific
                  GTK - glib - GUI Toolkit Specific
                  GTK - gtkint - GUI Toolkit Specific
                  GTK - Controls - Stop drilldown to prevent recursion
                  QT - messages - ???
              End interfaces.pp
            lmessages.pp
              Interface
                Uses
                  Classes - No GUI Toolkit specific dependencies
                  vclglobals
                    Interface
                      Uses
                        glib.pp - GUI Toolkit Specific (Why is this here?)
                        gdk.pp - GUI Toolkit Specific (Why is this here?)
                        gtk.pp - GUI Toolkit Specific (Why is this here?)
                    End vclglobals.pp
              End lmessages.pp
            controls.pp - Stop drilldown to prevent recursion
          Includes
            graphicsobject.inc
            graphic.inc
            bitmap.inc
            pen.inc
            brush.inc
            font.inc
            canvas.inc
        End grphics.pp
      lMessages.pp
        Interface
          Uses
            Classes - No GUI Toolkit specific dependencies
            vclglobals
              Interface
                Uses
                  glib.pp - GUI Toolkit Specific (Why is this here?)
                  gdk.pp - GUI Toolkit Specific (Why is this here?)
                  gtk.pp - GUI Toolkit Specific (Why is this here?)
              End vclglobals.pp
        End lmessages.pp
  Implementation
    Uses
      interfaces.pp
        Interface
          Uses
            GTK - gtk - GUI Toolkit Specific
            GTK - gdk - GUI Toolkit Specific
            GTK - glib - GUI Toolkit Specific
            GTK - gtkint - GUI Toolkit Specific
            GTK - Controls - Stop drilldown to prevent recursion
            QT - messages - ???
        End interfaces.pp
    Includes
      form.inc
      CustomForm.inc
      application.inc
  End Forms.pp

My first point of confusion comes with controls.pp. Why are the glib.pp, gdk.pp and gtk.pp units in the Interface Uses section of this unit? Doesn't this break the toolkit independence? The same holds true for vclglobals.pp. Are they even used anywhere, or could they be leftovers?

The second area is also in vclglobals. The csxxxxx (Class Style ???) constants defined there are, I assume, lazarus specific. The interface for each toolkit will have to map these constants to corresponding toolkit contants, where there is a match. Is this correct?

Next in the list is the graphics.pp file. Are all of the colors defined there meant to be Delphi compatible, and therefore native win32 color definitions? Since the gtk color conversion routines in gtkint.pp are private, a win32 version (WinInt.pp??) will not need an equivalent color conversion method, correct?

Lastly, in Forms.pp. I take it that none of the windows concepts of Window Style (the WS_xxxxxx constants such as WS_POPUP, WS_DLGFRAME, etc.) have been implemented yet? I noticed that to get to CreateWindow through the Win32 tree, you had to go all the way to funcs.inc in the fcl.

In closing, it seems I have answered some of my own questions just by writing all of this out. With the exception of the questions about controls.pp and vclglobals.pp using the gtk lib files without going through Interfaces.pp, it would seem I can truly let Interfaces.pp handle this, as long as I can manage without using anything not implemented already in gtk (such as the WS_xxxx window styles). It's only a matter of defining the correct InterfaceObject (no small task, it seems the GTK DLL's are doing a _lot_ of the work I'll need to do by hand).

I'll get the hang of this someday ;^)

Jeff.

I think you can download a postscript version and print it. In about another 3-4 weeks Havoc Pennington's book will be coming out. It was mainly written for Gnome/GTK but since Gnome is 90% GTK it will be very helpful for our purposes as well. I read the 2 chapters that he were previewed online and they were great. Very, Very helpful. This is the first book being published as "Open Source". You will be able to buy it at the book store but they whole thing will also be available on the net for download.

WinAPIInt.pp (vs. GkInt.pp, anyone got a better name?)

I originally had named it GUIAPI in my version before we incorporated it with Shanes stuff. I personally would prefer that since it is generic and indicates what it is used for. Either that or it will become interface since I will be combining the current interface.pp and gtkint.pp code together into one file.

If anyone has a name preference let me know.

I think I get it. Once the toolkit code is branched out under lcl, then in lcl the interfaces.pp will have a Uses GUIAPI line, and the linker will know from the makefile to get the version that is in the lcl/gtk or lcl/qt or whatever directory, and then GUIAPI can use whatever units it needs to use for that toolkit. Is this the idea?

Jeff.