The remaining content in this section has not been updated since July 2002. It's likely be very outdated in some parts.
The program starts from the function
        “main” in the module
        “main”: this creates an instance of
        wxGlade (a subclass of wxApp), which in turn
        creates a wxGladeFrame: this is the main window
        of the app, i.e. the one with the palette of buttons. The
        initialization of wxGladeFrame consists of
        three steps:
Creation of the three frames of the app, the palette itself, the tree and the property window
Loading of the code generator modules. The
            “codegen/” subdirectory is
            scanned to find the available code generators: when a python
            module is found, the app tries to load it and to access its
            'writer' attribute: if this is successfully accomplished, such
            'writer' object is considered a valid code generator, and is
            inserted into the 'common.code_writers' dictionary (the key used
            is the 'language' attribute of the writer itself)
Loading of the widget and sizer modules. To load the
            widgets, the file
            “widgets/widgets.txt” is read,
            and the app tries to import every widget module listed on such
            file. For every module successfully imported, the
            “initialize” function is
            then called: this function sets up the builder and code generator
            functions for a particular widget (explained later), and returns a
            wxBitmapButton instance to be added to the
            main palette. The loading of the sizers is more or less the same,
            except that all the sizers are in the same module,
            “edit_sizers”, and the
            initialization function (called
            “init_gui”) returns a list of
            wxBitmapButton objects
When the user clicks on a button of a top-level widget (a Frame
        or a Dialog), the method
        “add_toplevel_object” of
        wxGladeFrame is called: this is responsible for
        the addition of the widget to the application. This happens in this
        way:
the name of the class of the widget to add is obtained: this
            is done with the use of the
            “common.refs” dictionary, which maps the
            ids of the buttons of the palette to the class names of the
            widgets.
with the name just obtained, the appropriate factory
            function for the widget to add is got from the
            “common.widgets” dictionary. This
            function must accept three parameters: a reference to the parent
            widget (None in this case), a reference to the sizer
            to which the widget will be added (again None for
            top-level windows) and the zero-based position inside the sizer
            (once again, this is unused for top-level windows)
the call of the factory function actually builds the widgets
            and inserts it in the “common.app_tree”
            tree with a call to its method
            “insert”. The
            “__init__” method of the widget
            also builds all the Properties of the object and stores them in
            the 'self.properties' dictionary
This is similar to the addition of a top-level widget, but the action is performed in two steps:
when the user clicks on the button in the palette, the
            method “add_object” of
            wxGladeFrame is called: this sets the
            global variables “common.adding_widget”
            and “common.adding_sizer” to
            True, and stores the class name of the sizer to add
            in the global “common.widget_to_add”
            (the name is obtained from the
            “common.refs” dictionary as described
            above)
when the user left-clicks the mouse inside the previously
            added top-level widget, its “drop_sizer”
            method is called, which is responsible of the addition of the
            sizer: it calls the factory function for the sizer (passing self
            as the first argument), which will build the object and add it to
            the tree
This step is more or less the same as step 3:
“wxGladeFrame.add_object” is
            called in response to a button click
when the user ``drops'' the widget inside a slot in a sizer,
            the method “on_drop_widget” of
            edit_sizers.SizerSlot is called, which in turn calls
            the appropriate factory function with arguments
            “self.parent”,
            “self.sizer” and
            “self.pos” (i.e. the parent, sizer and
            position inside the sizer of the slot that will be replaced).
            Factory functions of non-top-level objects call, apart from
            “common.app_tree.insert” to insert the
            object in the tree, the method
            “add_item” of
            “edit_sizers.SizerBase”, to
            add the object to the sizer and to remove the slot. For managed
            widgets/sizers, the
            “__init__” method also
            builds the Properties which control the layout of the object
            inside a sizer, and stores them in the
            “self.sizer_properties”
            dictionary.
When the user selects a widget the property window changes to
        display the properties of the selected object: this is done by the
        functions “show_properties” of
        edit_windows.EditBase and
        edit_sizers.SizerBase, which are called inside
        two event handlers for focus and tree selection events.
When the value of a Property is changed, its setter function is
        called to update the aspect/layout of the widget the Property belongs
        to: such function is obtained from a call to the widget's
        “__getitem__” method, which must
        return a 2-tuple (getter, setter) for the Property
This operation is performed by the
        “common.app_tree” Tree: for every Node of
        the tree, an “object” XML element is generated, with the
        following attributes: name, class, base (class). Each object contains
        an element for each Property (generated by the
        “write” method of Property) and
        then an “object” element for all its sub-widgets and/or
        sizers. Properties in the “sizer_properties”
        dictionary are treated in a different way, as well as the children of
        a sizer, which are sub-elements of
        “sizeritem” objects: see the source code for
        details.
This is done by
        “xml_parse.XmlWidgetBuilder”, a
        subclass of
        xml.sax.handler.ContentHandler.
Basically, the steps involved are the following:
when the start of an “object” element is
            reached, a XMLWidgetObject instance is
            created and pushed onto a stack of the objects created: such
            object in turn calls the appropriate ``XML builder'' function (got
            from the “common.widgets_from_xml”
            dictionary) that creates the widget: this function is similar to
            the factory function used to build the widget during an
            interactive session, see the code for details and
            differences
when the end of an “object” element is reached,
            the object at the top of the stack is removed, and its widget (see
            the source of XmlWidgetObject) is laid
            out
when the end of a Property element is reached, the
            appropriate setter function of the owner of the Property is
            called. This is the default behaviour, suitable for simple
            properties. For more complex properties, whose XML representation
            consists of more sub-elements, each widget can define a particular
            handler: see for example FontHandler in
            edit_windows.WindowBase
This section is the result of a cut & paste of the comment
        at the beginning of
        “codegen/py_codegen.py”. It is
        *VERY* incomplete. The ContentHandler subclass
        which drives the code generation is
        xml_parse.CodeWriter.
How the code is generated: every time the end of an object is
        reached during the parsing of the XML tree, either the function
        “add_object” or the function
        “add_class” is called: the
        latter when the object is a top-level one, the former when it is not.
        In the last case, “add_object”
        calls the appropriate ``writer'' function for the specific object,
        found in the “obj_builders” dictionary. Such
        function accepts one argument, the CodeObject
        representing the object for which the code has to be written, and
        returns 3 lists of strings, representing the lines to add to the
        “__init__”,
        “__set_properties” and
        “__do_layout” methods of the
        parent object.
The lines in the
          “__init__” list will be added
          in reverse order.