Index


1.0 EVERGLADE ABSTRACT

Top

EverGlade is a metacybernetics design and manufacturing system which manages the evolutionary fabrication of Glade generated GUI programs. It implements scaffolding to facilitate three levels of design expression and evolution (or editing):

Level Name Where design is: Purpose
top metaphoric created by graphical assembly of GUI widgets using Glade implement and remember GUI layout of widgets
intermediate meta-source augmented and regenerated by Perl programming remember and reproduce previous C source code
bottom source the GTK+ API articulation in C of GUI action or semantics fill in C callback stubs

EverGlade introduces intermediate Perl scaffolding between Glade and the GTK+ API to facilitate adaptation and evolution of GUI semantics by editing API calls and reconciling them of visual changes via Glade. Evolution therefore proceeds in two dimensions:

Evolution DImension Called Implemented by:
System User Interface mutation visual metaphor via Glade artwork
GTK+ API code editing surgery editing of new design versus old or baselined design

The editing of source code can be synchronized or unsynchronized. Synchronized editing is where two versions are visible side by side for comparison with differences highlighted automatically and are scrolled in lockstep. Unsynchronized editing is where the two or more panes of the gang editor do not scroll in lockstep and differences are not highlighted.

Evolution in both dimensions is facilitated concurrently by an archive-tree assembly-line, where each archive-tree contains a sequential mutation, and each archive in its time sequence is paired with a permanent baseline tree, which is maintained under version control.

Whenever a new mutation is created by Glade, its generated code must be reconciled with the prior archive-tree (old surgery) by comparative editing, to update the baseline tree before new surgery can continue. The very first time Glade generated C code is created, e.g. for GTK+ callbacks, the editing (or surgery) is to insert the semantics of what is to be done by each callback function.

EverGlade also generates the files needed to build (make, compile, and link) the resulting GUI program.

2.0 INTRODUCTION

Top

2.1 The Problem: GUI Design Evolution

Glade is an incomplete design tool that converts visual GUI images created by (drag and drop parameterized) artwork into Gtk+ interface code and callback code stubs that must be filled in and evolved by programming at a different level of design. As a visual specification tool, it is adequate to start a design at a visual level and then transfer that design to the implementation-code level.

If it is desired to evolve a whole design on both levels, there is no mechanism for maintaining synchronization of both levels of design, top (visable artwork) and bottom (code). In other words, once the generated C code has been edited, Glade has no way to know about and retain those changes and correlate them with the widgets that have been graphically created or modified.

In Metacybernetic terms, evolution of the program introduces conflicts between graphical user interface level design changes (mutations of a metaphoric process of generating code from artwork), and implementation design changes by code editing (surgery).

EverGlade solves this problem of having to abandon the ability to continue to use Glade to Graphically edit the user interface once the C code generated by Glade has been edited. EverGlade remembers these C code edits and allows for the comparison of current vs. previous code states, and regenerates the changes so that Glade can continue to be used to graphically (or metaphorically) edit the GUI.

2.2 Simple End-to-end Examples

Rather than explain the details of the process now, it is better to have two simple demonstrations of the end-to-end steps of using EverGlade to create a GUI program.

The first example is the expected "Hello World" which is a GUI program that puts up the message "Hello World". This trivial example has no interactivity, it only has a simple label widget which has no callbacks. The value of this example is it show the simplest possible flow from start to finish resulting in an executable GUI program (even if it does nothing useful).

The second example extends the "Hello World" example to have trivial interactivity with a menu bar to show the additional steps needed when callbacks are edited.

2.2.1 "Hello World" Example

Steps:

  1. Run EverGlade, which will result in "Figure 2.2.1:1"


    Figure 2.2.1:1

  2. Fill in "Project Name" field with "HELLO", click on the "Glade Processing" radio button label "Initialization", then click on the "Execute Glade" button to run Glade, which which will bring up Glade for the new project "HELLO" as shown in "Figure 2.2.1:2"


    Figure 2.2.1:2

  3. If you are familiar with Glade, then perform the Glade steps to create the "Hello World" dialog box shown in Figure 2.2.1:3. If you are not familiar with Glade then click here.


    Figure 2.2.1:3

  4. Click on "Save" (Figure 2.2.1:4) to save the Glade project in the xml file hello.grade in the ~/EVERGLADE/GladeWork/HELLO tree. Then exit Glade.


    Figure 2.2.1:4

    This will return to the EverGlade window as shown in Figure 2.2.1:5.


    Figure 2.2.1:5

    Note that the GUI Editing radio button is now activated, so that if the Execute Glade button is clicked, the already created xml file will be loaded for updating by any changes made through Glade. This process can be repeated indefinitely.

  5. When current Glade editing of this GUI widgets is done, then click on the Assembly Line tab to set up the next steps involving the generation of C-code. The Assembly-Line page is illustrated in Figure 2.2.1:6.


    Figure 2.2.1:6

  6. Code generation begins with creation of the first assembly-line archive (the first mutation) of the HELLO project. To proceed, a Final Path--the destination of the final GUI program must be defined. Clicking the Mutate Archive button without defining the Final path will result in a popup reminder, as in Figure 2.2.1:7.


    Figure 2.2.1:7

    When the Final Path is entered, it is checked for existence. If it does not exist another popup (Figure 2.2.1:8) notifies this as a reminder. In such a case this path will be created in the first mutation.


    Figure 2.2.1:8

    This first mutation is produced when the Mutate Archive button is clicked (Figure 2.2.1:9). It executes Glade internally via the command line execising an option causing Glade to generate C-source code in the ~/EVERGLADE/GladeWork/HELLO/src directory, which it creates. This will also cause Glade to generate all of the configuration files and data needed to create make files via the GNU tools autoconf and automake.


    Figure 2.2.1:9

    Next the initial project assembly-line architecture is created in the ~/EVERGLADE/Assembly/HELLO tree. This includes the first archive tree, ~/EVERGLADE/Assembly/HELLO/HELLO_090418A and the baseline tree ~/EVERGLADE/Assembly/HELLO/VC/HELLO_base.

    Next the Glade generated C-source code from ~/EVERGLADE/GladeWork/HELLO/src is copied to the two source subdirectories in ~/EVERGLADE/Assembly/HELLO/HELLO_090418A, namely

    • isrc - the container for input-from-Glade/generated source (upstream source), and
    • tsrc - the container for tagged/surgery source (downstream source).

    Glade-generated source is only copied to the downstream subdirectory tsrc for the first mutation. This allows downstream processes (which take their source input from tsrc) to proceed, if the GUI design is simple enough that no tagging or surgery is required (certainly true of "Hello World").

    The next operation of the first mutation is execution of the Glade-generated script autogen.sh, which executes autoconf and automake to generate the makes files in ~/EVERGLADE/GladeWork/HELLO.

    The final operation of the first mutation is the creation of the GUIbuild subdirectory in the final path, in this case ~/HELLO/GUIbuild. This is the final downstream staging area for building GUI source code into the binary executable program.

  7. The generated C-source code may now be viewed and edited, if required, by the first two buttons on the top right of the Assembly-Line page. This can be skipped in this case, but if you want to see the code, click here.

  8. With this simple source code, no editing is required, so we can send the source to the GUIbuild subdirectory in ~/HELLO in preparation for the make operation to follow. Clicking the Send Source to Baseline/Build button, accomplishes this by copying the source files from ~/EVERGLADE/Assembly/HELLO/HELLO_090418A/tsrc to ~/HELLO/GUIbuild and also copies these files to ~/EVERGLADE/Assembly/HELLO/VC/HELLO_base/tsrc in case this source is to be sent to the SVN version control repository.


    Figure 2.2.1:13

  9. Now we are ready to generate and run the HELLO executable file 'hello'. We prepare for this by clicking the Generation tab, then clicking the install and run check buttons followed by clicking the Make button. Figures 2.2.1:14 and 2.2.1:15 show the results.


    Figure 2.2.1:14


    Figure 2.2.1:15

2.2.2 "Hello World" plus Button Popup Extensions Example

Now extend the "Hello World" program by adding two simple buttons which generate popup messages as follows.

Steps:

  1. We will continue the HELLO project, but first creating a new archive mutation. We go back to the Assembly Line page and click on the Mutate Archive button as in Figure 2.2.1:9. This creates the archive ~/EVERGLADE/Assembly/HELLO/HELLO_090420A effectively cloning the previous archive. Now all development work shifts to this archive.

  2. We return to the Glade Design page (Figure 2.2.2:1) and click the Execute Glade button. We are going to modify the Hello World GUI to add two buttons that will invoke popup descriptions of the roles of Glade and EverGlade. The labels of the two buttons will be "Glade Evolves GUI Images" and "EverGlade Evolves GUI Code", as shown in Figure 2.2.2:2T.


    Figure 2.2.2:1


    Figure 2.2.2:1T

    To follow the Glade session to create this GUI image, Click here

  3. Now we are ready to begin evolving the code generated by Glade, including the additions to the original Hello World interface.c file, and the empty callbacks.c file. This is where the Meld editor comes into play as a powerful aid in evolutionary design. To start the process, we go to the EverGlade Assembly Line page and click on the Meld Glade Code Update button (Figure 2.2.2:2). This button will invoke seven sequential meld sessions which compare the files having the same name, from the two source directories of the current archive. These seven sessions are illustrated in the next sixteen figures.


    Figure 2.2.2:2

    The first session (Figure 2.2.2:2A) compares the main.c routines which are the same.


    Figure 2.2.2:2A

    The next seven figures illustrate the meld session for the interface.c changes resulting from the previous Glade session on the right side melded with the source on the left side moved from the previous archive (original Hello World design).

    Figure 2.2.2:2B shows the addition of the three new widgets highlighted in green.


    Figure 2.2.2:2B

    Figure 2.2.2:2B1 shows the meld reconciliation of the old design to match the new design as the result of having clicked the left-pointing arrow in Figure 2.2.2:2B, resulting in the pasting of the green highlighted lines. These now show up shaded on the left with text matching on the right.


    Figure 2.2.2:2B1

    Figure 2.2.2:2B2 shows the addition of three more blocks of code for the three added widgets, constituting their GTK API calls for creation, display, and packing; the callback signal connection calls for the two buttons, and object hookup calls.


    Figure 2.2.2:2B2

    Figure 2.2.2:2B3 shows the meld reconciliation of the old design to match the new design as the result of having clicked the first left-pointing arrow in Figure 2.2.2:2B2,resulting in the pasting of the green highlighted lines. These now show up shaded on the left with text matching on the right.


    Figure 2.2.2:2B3

    Figure 2.2.2:2B4 shows the meld reconciliation of the old design to match the new design as the result of having clicked the middle left-pointing arrow in Figure 2.2.2:2B2,resulting in the pasting of the green highlighted lines. These now show up shaded on the left with text matching on the right.


    Figure 2.2.2:2B4

    Figure 2.2.2:2B5 shows the meld reconciliation of the old design to match the new design as the result of having clicked the last left-pointing arrow in Figure 2.2.2:2B2,resulting in the pasting of the green highlighted lines. These now show up shaded on the left with text matching on the right.


    Figure 2.2.2:2B5

    Figure 2.2.2:2B6 shows the final step of the second meld session, saving the left-side file to update interface.c in the new archive. This is followed by guitting the session, either by the quit item in the File menu, or by clicking the X in the upper right corner.


    Figure 2.2.2:2B6

    Figure 2.2.2:3 shows the session for melding of the interface.h files, which are identical in both versions. So this session is exiting without saving.


    Figure 2.2.2:3

    The next three figures describe the callbacks.c meld session. They illustrate the major downstream design work that Glade leaves undone, as it only generates callback stub functions that have to be fleshed-out by surgical editing. Figure 2.2.2:4 shows the Glade-generated code on the right, and nothing on the left, because the 'Hello World' GUI had no callbacks.


    Figure 2.2.2:4

    Figure 2.2.2:4A shows the generated code moved to the left by clicking the left-pointing arrows in Figure 2.2.2:4, to start the design editing process.


    Figure 2.2.2:4A

    Figure 2.2.2:4B shows the final design of the button1 and button2 callback functions, each containing a popup dialog explaining what is meant by the button titles.


    Figure 2.2.2:4B

    Figure 2.2.2: shows the start of the fifth meld session to update the callbacks.h file. Surgery here consists of clicking the left-pointing arrow on the right side, and saving the resulting left-side file.


    Figure 2.2.2:5

    Figured 2.2.2:6 and 2.2.2:7 show the sixth and seventh meld sessions, of the support.c and support.h files respecitively, neither of which require any changes.


    Figure 2.2.2:6


    Figure 2.2.2:7

  4. Now we are ready to deliver the source files to the final path make staging directory ~/HELLO/GUIbuild, and to the baseline tree source container ~/EVERGLADE/Assembly/HELLO/VC/HELLO_base/tsrc. As shown in Figure 2.2.3, this is accomplished by clicking the Send Source to Baseline/Build button.


    Figure 2.2.3

  5. The next step is a trial make. We click on the Generation tab, and then click on the install and run check buttons and then click the Make button (Figure 2.2.4).


    Figure 2.2.4

    But as shown in Figure 2.2.4A, the make failed. In this case, the makeout file is popped up in the Kwrite editor for viewing make output. The problem is that the GTK dialog functions must reference their parent window (the dialog1 widget), but this widget is is declared local to the create_dialog1 function (line 32 in the interface.c file). It needs to be a global variable.


    Figure 2.2.4A

    So the next step is to fix the interface.c and callback.c file in ~/HELLO/GUIbuild, in preparation for the remake. This can be accomplished by gang editing, so first we must select the gang editor on the upper right combo box. In Figure 2.2.4B, we select jedit as the gang editor, and in Figure 2.2.4C we click the Gang Edit GUIbuild Source button to invoke gang editing.


    Figure 2.2.4B


    Figure 2.2.4C

    Now looking at Figure 2.2.4D we highlight line 32 of interface.c which needs to be moved up to file scope.


    Figure 2.2.4D

    In Figure 2.2.4E we have moved up the dialog1 declaration to line 29 in file scope, and have placed an extern reference to it at line 11 in callbacks.c.


    Figure 2.2.4E

    Now we are ready to do the remake. So in Figure 2.2.4F, we click the install and run check buttons, and then the make button.


    Figure 2.2.4F

    Then in Figure 2.2.4G, we see that the make worked and the GUI appeared, so we clicked the first button, and observed the popup as expected. In Figure 2.2.4H, we clicked the second button, and saw its popup. But neither of the popups were very satisfactory because the lines were too long. They were folded by the limits of the built-in dialog display. So we counted the longest lines, and found them to be about 60 characters.


    Figure 2.2.4G


    Figure 2.2.4H

    To fix the line length problem, we went back to the jedit gang editor (Figure 2.2.4I) and selected its buffer options to set its line folding column to 60, where it will draw a vertical line to help frame the text. Then in Figure 2.2.4J, we shortened all the lines so as to conform to the 60-character limit in the GTK dialog.


    Figure 2.2.4I


    Figure 2.2.4J

    Then we did the remake/run, and the final results are shown in Figures 2.2.4K and 2.2.4L.


    Figure 2.2.4K


    Figure 2.2.4L

  6. With the new program complete, the last step is to update the latest assembly-line archive to reflect the changes made in GUIbuild during the make cycle. Meld is used for this to provide a final inspection of the source changes that were made, clicking the Meld Archive to GUIbuild Source button in the Generation page, as shown in Figure 2.2.5


    Figure 2.2.5

    No changes to main.c (Figure 2.2.5A) - not saved.


    Figure 2.2.5A

    Bug that caused initial make failure (Figure 2.2.5B).


    Figure 2.2.5B

    Fix moved to left file and saved (Figure 2.2.5C).


    Figure 2.2.5C

    No changes to interface.h (Figure 2.2.5D) - not saved.


    Figure 2.2.5D

    Extern declaration and line length changes (Figure 2.2.5E).


    Figure 2.2.5E

    Changes moved from right to left and saved (Figure 2.2.5F)


    Figure 2.2.5F

    No changes to callbacks.h (Figure 2.2.5G) - not saved.


    Figure 2.2.5G

    No changes to support.c (Figure 2.2.5H) - not saved.


    Figure 2.2.5H

    No changes to support.h (Figure 2.2.5I) - not saved.


    Figure 2.2.5I

2.3 EverGlade Roles

With the examples just shown it will be easy to expand on and understand the roles that EverGlade plays in the development process. There are four roles, the last of which is beyond the initial examples but is required for full flexibility.

2.3.1 Primary Role - Lockstep Evolution Management

Neither Glade nor Gtk provide any assistance in reconciling these two levels of design to maintain synchronization, so that the whole design may evolve with top and bottom in lockstep. This is the primary role of EverGlade: that of an evolution manager.

2.3.2 Secondary Role - Dynamic GUI Evolution by Automation

A secondary role extends the management to the more dynamic evolution conditions where the GUI is merely an interface of a dynamically evolving external process, such as a background or server-side computer program.

Often in such cases, the API code design must be dynamically regenerated by the external process, even dynamically recompiled in an included make process. In these cases portions of the Glade artwork are merely exemplary patterns (e.g. foreshortened menus) which must be dynamically "fleshed out" via the internal loops of the external process. Such loops must replicate callbacks and signal conditions, which cannot be generated by Glade, but must be provided surgically by editing or re-generated by surgically inserted generative processes in the downstream design.

This external process inserted into the mix vastly complicates the already daunting process of managing evolution of the whole design (of the GUI interface and the external process itself). It often requires a third (intermediate) level of design between the artwork and the API code, whose purpose is to regenerate the API code.

This intermediate design level must therefore be a dynamic container of the API-level design, capable of generating that lower design level to meet dynamic conditions of the external process. Such a generative design container is known as meta design. It is a metaprogramming level connected logically in easily discernable patterns to both the top-level artwork and the bottom-level API code.

2.3.3 The MIDDLE Synchronization Principle

These associative patterns may be literal text patterns contained in embedded "here documents", or format patterns containing embedded substitution variables within metaprogram loops. In either case, they may be easily reconciled to generated design patterns from the Glade artwork above, and to the API code below, by synchronized comparative editing via difference-detecting and highlighting multi-pane editors such as Meld, or un-synchronized multi-pane gang editors such as jEdit or Kate.

Multi-level equivalence of the associative design patterns is made simple by their comparative juxtaposition, and by a principle of configuring the data ordering and juxtaposition so as to minimize incremental design difference for lockstep equivalence (MIDDLE). This synchronization principle maximizes suggestive adaptations to the user, even when the data being compared and changed are functionally in separate phases of design transformation. Difference-minimizing synchronization is managed through by an assembly-line architecture of incremental archives. Each archive in the assembly line is a tree of directories in which different states of code are maintained, and from which separate states may be compared and edited to reconcile them with changes made upstream by generation or downstream via editing.

Archives are named by a project name (all caps) appended to a serial name composed of a date stamp and a serial letter. They are generally associated with a mutation change (e.g Code generation via Glade), and a new archive in the assembly-line may be created for each mutation.

The most recent archive (head of the assembly line) is paired with a "baseline tree" which is associated with the latest surgical changes. This tree is maintained under version control as a subversion working directory.

The archive and baseline trees are described under Project Architecture below.

2.3.4 External Regeneration Drivers - Looped Meta-Design (LMD)

The full features of EverGlade focus on dynamic GUI generation beyond the Glade envelope, where a separate generation driver program captures Glade's incomplete GUI design, and finishes it using looped meta-design (LMD), which at this stage must be manually adapted in Perl as meta design, or inserted as C-loop elements in the API-calls. The external regeneration driver is the data source, containing the replication loops. An example is a script that reads the contents of a directory and dynamically generates a large menu GUI for accessing that directory for some purpose.

As the action of accessing and processing the contents of the directory may substantially alter the directory content structure, even creating and destroying new subtrees, dynamic regeneration of the GUI may be required.

Another example of this type of GUI regenerative design is GAEMY (Grammar-Action Evolution Manager for Yacc), another metacybernetic tool, in which system architecture mutations are changes of the pure language grammar in the Yacc BNF metalanguage, and surgery involves the evolution of C-code semantics of Yacc action predicates.

In effect, EverGlade automatically produces an ad-hoc GUI regeneration API for the external driver, in the form of Perl meta-source subroutines that the external driver calls. These subroutines are contained in a Perl module called PROJECT_gen.pm. where PROJECT is the upper case Glade project name.

2.4 Top Panel Widgets

The top panel of the EverGlade GUI (Figure 2.4:1) remains stationary while the six notebook tabs are changed. It contains two Entry widgets for entry of the project name and final path. These fields must be populated for all EverGlade processing, described below. The third widget is a combo box for selection of a particular editor to be used for un-synchronized gang editing.



Figure 2.4:1. EverGlade GUI and Glade Processing Tab

2.5 Project Architecture

An EverGlade project is a subtree in two different branches of ~/EVERGLADE:

As EverGlade's purpose is to augment the output code from Glade, and then use the Glade-generated make apparatus to make the final GUI executable; it moves Glade PROJECT design data from the GladeWork/PROJECT path to the Assembly/PROJECT path to facilitate its metacybernetic evolution. Then the augmented design is copied back to the GladeWork/PROJECT path, ready to make its executable program. A project subtree in the Assembly path has the typical structure:

2.5.1 Final Path

The final path associated with the project name must be populated in the Final Path field to associate the external driver with the GUI. This is an external location outside the EVERGLADE tree (unless the GUI is EGLADE--the EverGlade GUI). It is associated with the final product of which the GUI is a part. It is also the residence of the "external driver", which in the case of meta-source generated GUIs is the processor which fleshes-out portions of the GUI which are only exemplified by Glade artwork.

The place where final generation of the source code takes place is the GUIbuild subdirectory of the final path. GUIbuild is the staging area for building the GUI program source into an executable program via make, and prior generation of that source from meta-source if required.

The meta-source module, PROJECT_gen.pm is the primary output the Meta Design tab. It may be bypassed if no external driver is required to flesh-out a GUI design. It is an ad-hoc GUI regeneration API for the external regeneration driver. Thus it must be delivered (copied) to a the GUIbuild subdirectory where the external looping process will access it to produce the final C-source, which will be subsequently moved to the make location in GladeWork (~/EVERGLADE/GladeWork/PROJECT/src).

2.5.2 Metacybernetic Full Fabrication Cycle

Figure 2.5:1 illustrates the seven fabrication steps of each evolution cycle and the movement of project data between the various directories.



Figure 2.5:1 Evolution Cycle
  1. Glade Work, Mutation, and Source Generation

    The metacybernetic fabrication cycle begins with Glade artwork via the server script EG_glade, and a mutation via the server script EG_mutate, which creates a new dated project archive in the ~/EVERGLADE/Assembly tree. If the project tree is new, EG_mutate also creates the project base tree. This script then executes Glade via command line to invoke generation of the seven C-module files into the src subdirectory of GladeWork/PROJECT, and into the isrc and tsrc subdirectories of the new PROJECT archive in the Assembly line.

    The EG_glade script initially only produces project XML files in the ~/EVERGLADE/GladeWork/PROJECT subdirectory, without generating source code. If a mutation archive exists in the ~/EVERGLADE/Assembly tree, then EG_glade will re-execute Glade via the command line for source generation, causing the C-module files to be written in the ~/EVERGLADE/GladeWork/PROJECT/src subdirectory. Then these files are copied to the isrc subdirectory of the latest archive tree.

  2. Source Tagging and Stubs Editing

    The seven source files from tsrc are loaded for editing, either by gang editing or meld editing to insert tags which partition the source into parts for meta-source abstraction, and perform editing to fill in stubs design.

  3. Meta-Source Generation

    The seven source files from the tsrc subdirectory are processed by the EG_genmeta script, one at a time, each time calling the metagen.pl script which abstracts tagged source into Perl meta-source subroutines, and appends them to a file called rawgen/PROJECT_gen.pm.

  4. Meta-Source Refining

    The rawgen/PROJECT_gen.pm file is loaded for refinement editing, either by gang editing or meld comparison editing against fingen/PROJECT_gen.pm in either the base tree or the last archive tree.

  5. Baselining and Meta-Source Module Delivery

    The contents of the four subdirectories of the latest archive are copied to the base tree, where they can be used to update the Subversion repository. This is also the delivery step which copies the fingen/PROJECT_gen.pm module to its driver destination 'GUIbuild' where it is called as a Perl API by the PROJECT server script.

  6. Source Regeneration

    This involves the execution of the server PROJECT driver script to regenerate the C-source modules int the GUIbuild subdirectory.

  7. GUIMAKE

    The GUIMAKE script copies the C-source modules from the GUIbuild subdirectory to the ~/EVERGLADE/GladeWork/PROJECT/src subdirectory, and then executes Make in the ~/EVERGLADE/GladeWork/PROJECT subdirectory, thus completing the EverGlade detour of the Glade generation process, and producing the EverGlade-enhanced GUI executable.

2.5.3 Metacybernetic Reduced Fabrication Cycle

The reduced fabrication cycle is for GUIs that do not involve external process generation. Consequently there is no need for abstraction of source into meta-source for regeneration.

Figure 2.5.3:1 illustrates the five fabrication steps of the reduced evolution cycle and the movement of project data between the various directories. Steps 3, 4, and 5b and 6 are bypassed in this reduced cycle.



Figure 2.5.3:1. Reduced Evolution Cycle
  1. Glade Work, Mutation, and Source Generation

    The metacybernetic fabrication cycle begins with Glade artwork via the server script EG_glade, and a mutation via the server script EG_mutate, which creates a new dated project archive in the ~/EVERGLADE/Assembly tree. If the project tree is new, EG_mutate also creates the project base tree. This script then executes Glade via command line to invoke generation of the seven C-module files into the src subdirectory of GladeWork/PROJECT, and into the isrc and tsrc subdirectories of the new PROJECT archive in the Assembly line.

    The EG_glade script initially only produces project XML files in the ~/EVERGLADE/GladeWork/PROJECT subdirectory, without generating source code. If a mutation archive exists in the ~/EVERGLADE/Assembly tree, then EG_glade will re-execute Glade via the command line for source generation, causing the C-module files to be written in the ~/EVERGLADE/GladeWork/PROJECT/src subdirectory. Then these files are copied to the isrc subdirectory of the latest archive tree.

  2. Callbacks Editing (Source Tagging Unnecessary)

    The seven source files from tsrc are loaded for editing, either by gang editing or meld editing. Since meta-source abstraction is precluded, the insertion of tags for meta-source abstraction is unnecessary. However, this is the state where editing of Callbacks stubs and other files will take place.

  3. Baselining

    The contents of the four subdirectories of the latest archive are copied to the base tree, where they can be used to update the Subversion repository. This is also the delivery step which copies the fingen/PROJECT_gen.pm module to its driver destination 'GUIbuild' where it is called as a server API by the PROJECT server script.

  4. Source Regeneration

    This involves the execution of the server PROJECT driver script to regenerate the C-source modules int the GUIbuild subdirectory.

  5. GUIMAKE

    The GUIMAKE script copies the C-source modules from the GUIbuild subdirectory to the ~/EVERGLADE/GladeWork/PROJECT/src subdirectory, and then executes Make in the ~/EVERGLADE/GladeWork/PROJECT subdirectory, thus completing the EverGlade detour of the Glade generation process, and producing the EverGlade-enhanced GUI executable.

2.6 GUI Tabbed Pages

The seven steps of the Full Evolution Cycle are controlled by the first four tabbed pages of the EverGlade GUI.

  1. Figure 2.4:1 shows the Glade Design page containing the Glade Processing functions of initialization and editing.
    • Initialization creates the project in Glade and in the GladeWork tree when the Execute Glade button is clicked, regardless of whether the project is saved from Glade.
    • Glade Editing is for actual creation of widgets in Glade, and saving the project when finished. Code generation within Glade is not required, however. If version control retrieval is selected, then the Glade project XML files are copied from the VC subdirectory of Assembly/PROJECT into the GladeWork/PROJECT directory before Glade is invoked.

  2. Figure 4.0:1 shows the Assembly Line page containing the assembly-line mutation staging and source tagging operations.
    • The Archive Mutation frame on the left stages the assembly line, creating a new date-stamped archive tree in the Assembly/PROJECT directory when the Mutate Archive button is clicked.
      • If this ia a new project being initiated from scratch, it creates the VC directory and the baseline tree within it; creates the configure.in file for autoconf and automake in the GladeWork/PROJECT directory and the Makefile.am for automake in its src subdirectory. It also creates the DriverPath directory if if does not yet exist, and the GUIbuild subdirectory within it, where the meta-source Perl module will be delivered, and the source will be regenerated for final make processing.
      • Otherwise (an old project) it checks to see if no archive exists, meaning that the old project was checked-out from version control, in which case the initial archive is cloned from the checked-out baseline tree. Also, presuming changes have been made to GUIbuild source (and possibly meta-source) during an iterative make process, the GUIbuild source and meta-source files are copied to both the latest archive and the baseline trees for subseqent meld-reconcilation.
      • Check Buttons (processed in the order they appear)
        • Include GUIBuild Meta Source - Selecting this check button causes the new archive fingen/ directory to include the Meta Source module copied from the driverpath/GUIbuild directory to incorporate prior edits associated with source regeneration in the make cycle.
        • Include GUIBuild Source - Selecting this check buttion causes the new arhive tsrc/ directory to include the source files copied from the driverpath/GUIbuild to incorporate prior edits performed in the make cycle.
        • Update Baseline Meta Source for VC - Selecting this check button causes the Meta Source module in the new archive fingen/ directory to be copied to the baseline fingen/ directory so it can be committed to SVN version control.
        • Update Baseline Source for VC - Selecting this check button causes the source files in the new archive tsrc/ directory to be copied to the baseline tsrc/ directory so that they may be committed to SVN version control.
        • Restore Last Archived Glade Design -Selecting this check button will cause the last archived glade design to be restored in the new archive. This can be used to restore a local glade design that was in place of a previous update from version control.
    • The Source Tagging and Code Design frame contains three buttons to invoke editing of of source files, and a button to bypass meta design altogether.
      • The Gang Editing for New Tags and Design button starts the source tag insertion process for source-code generated by Glade for the first time, applying the tagging language to divide the meta-source modules into parts. jEdit is employed for gang editing in a single session, so that all files are available together, and other files (e.g. old design) which might be used as copy/paste sources can be included in the gang file group. This is also the button to choose when moving source text from one of the source files (e.g. main.c or callbacks.c) to another (e.g. support.c).
      • The Meld Glade Update button is for reconciling tagged archive source with regenerated source from Glade (which has no tags) using the meld side-by-side comparison editor. This editor highlights changes in each side that don't exist in the other side, while providing arrows for automated pasting for reconciliation.
      • The Meld to Baseline Tags button uses meld to reconcile differences between current archive tree source, and source contained in the baseline (possibly due to a version-control update in the baseline, made by a colleague).
      • The Send Source to Baseline/Build> button is used to invoke the shortcut process of the reduced evolution cycle, bypassing meta design altogether. As shown in Figure 2a, this button causes the source files in the tsrc/ directory of the latest archive to be copied to the GUIbuild directory of the Driver Path. It also causes the contents of the isrc/, tsrc/, rawgen/, and fingen/ directories of the latest archive to be copied to the baseline tree so that they may be committed to SVN version control.

  3. Figure 5.0:1 shows the Meta Design page containing the meta-sourec generation and refinement editing operations, together with baseline and GUIbuild delivery.
    • The Generate Module buttons converts the seven tagged-source files of the current archive into a single Perl meta-source module file (PROJECT_gen.pm) in raw form (prior to refinement using the next three buttons).
    • The first refinement button, Gang-Edit New Module invokes the selected gang editor to edit the raw module with the equivalent module from the prior archive in the assembly line, if one exists, or with any other module or source file the user cares to load into the gang edit during the session
    • The second Meld-Evolve Base Module, and third Meld-Evolve Last Module refinement buttons invoke meld to synchronously compare and edit the raw module with the equivalent module selected by priority if such a module exists, or a lower priority equivalent module if it does not, where the existence check starts with the baseline module for the former and with the last archive module for the latter.
    • The next button on this page, Update Baseline MetaSource for VC copies the source and meta-source content from the lastest archive tree to the baseline tree.
    • The last button Update GUIbuild Meta Source copies the meta-source module to the GUIbuild directory for the next stage, source regeneration.

  4. Figure 6.0:1 shows the Generation page containing the source regeneration and make operations.
    • The left side is devoted to regeneration of source code from the meta-source module in the GUIbuild directory, nominally residing under an external driver program tree architecture somewhere remote from the ~/EVERGLADE tree (unless the GUI to be built is EGLADE, the EverGlade GUI itself).
      • If the GUI has dynamic parts generated by LMD in Perl meta-source, then the resulting executable will be specific to a data source, such as a specific project of the external driver. The name of this project data source is specified in the GUIbuld Datakey entry widget.
      • The Source Regeneration button invokes the external driver script, (i.e. the name contained in the Project Name entry widget, which must be in the $PATH, usually in the /PROJECT/bin directory, which must be in the $PATH).
    • The right side is devoted to building and installing the GUI executable program using make.
      • The Make button at the bottom invokes a server script, GUIMAKE, which copies the source files from GUIbuild to GladeWork/PROJECT/src and then executes make in GladeWork/PROJECT/, an writes the make output to a file called makeout in that directory.
        • If the install check button is activated, and the make is successful, the resulting executable (named project if the GUIbuild Datakey widget is blank, and project_datakey otherwise).
        • if the run check button is activated, and the make is successful, the GUI will be immediatedly executed.
      • The Gang Edit GUIbuild Source button is for making corrections to the source files in the GUIbuild directory during the make cycle.
      • The Archive GUIbuild Source button is employed for GUIs only requiring the reduced evolution cycle to return the corrected GUIbuild source files to the tsrc/ directory of the latest archive.

3.0 Glade Design Processing

Top

Glade processing is the initial step in the process of adapting Glade-generated source code design into a Perl generator as meta-design. It creates or edits a GUI project XML file using Glade. Since its sole purpose is to modify this file, it may be executed repeatedly to refine the GUI image, before the subsequent EverGlade steps

3.1 Project Initialization

For a new project, invoked by selection of the Initialization radio button, the Execute Glade button executes the server script ~/bin/EG_glade which creates an empty XML file project.glade (where project is the lower case of the PROJECT name). It also creates a project options file project.gladep, which contains options corresponding to the two check buttons for gnome and gettext support, respectively.

This XML files are stored in a created PROJECT subdirectory of ~/EVERGLADE/GladeWork.

3.2 GUI Editing

When the GUI Editing radio button is selected, clicking the Execute Glade button causes EG_glade to execute Glade via the command line, causing Glade to load the project.glade file and to save the result of Glade editing in this file when Glade's save button is clicked.

The Execute Glade button does not invoke code generation from glade unless it is invoked from inside Glade itself.

4.0 Assembly-Line Processing

Top

The contents of the second notebook tab is shown in Figure 4.0:1. This concerns the assembly-line maintenance and processing to prepare for meta-design generation.



Figure 4.0:1. EverGlade GUI and Assembly Line Tab

4.1 Mutate Archive Button

After Glade artwork processing, this button creates a new archive tree in the assembly-line, corresponding to a system architecture mutation via Glade. This button executes the server script EG_mutate which creates a new archive subdirectory named PROJECT_yymmddL (L is any letter A-Z) within the ~/EVERGLADE/Assembly/PROJECT directory. For clarity we will refer to this latest stage of the evolution assembly-line as $newarch.

EG_mutate re-executes Glade via the command line to generate source code from the PROJECT.glade file in the ~/EVERGLADE/GladeWork/PROJECT/Glade subdirectory, which will output C-source files into the ~/EVERGLADE/GladeWork/PROJECT/src subdirectory.

This source is then copied to the new archive tree subdirectories $newarch/isrc (input source from Glade) and $newarch/tsrc (tagged source workarea). Two other subdirectories are also created as workareas for subseqent steps. They are $newarch/rawgen (workarea for initial meta-source generation), and $newarch/fingen (workarea for final meta-source adaptaion).

4.2 Install SVN Update Button

This is for the case where the design was created remotely and committed to SVN. Then it was downloaded to the local machine via the SVN update command.

This button installs the current archive from the version controlled baseline. It copies the PROJECT.glade and PROJECT.gladep xml files from ~/EVERGLADE/Assembly/PROJECT/VC to the ~/EVERGLADE/GladeWork/PROJECT directory. Then it executes Glade in the background to generate source into the ~/EVERGLADE/GladeWork/PROJECT/src directory.

If the current archive being installed is new (i.e. the first mutation), no Makefiles will exist in the GladeWork PROJECT and PROJECT/src directories, then the configure.in and Makefile.am files will be generated to go with the GNU Makefile generation files produced by Glade, and the autogen.sh script will be executed to create the makefiles.

The current surgery source (tsrc) from the baseline is copied to the new archive and the current mutation source from the background Glade source generation is copied to the isrc directory.

If meta-source exists in the baseline design, then it is also copied to the rawgen and fingen directories of the new archive.

Upon completion the new archive is ready for all upstream and downstream operations of EverGlade, just as if the new archive had been created locally via the Mutate Archive button.

4.3 Gang Editing for New Tags and Design

After creating the next archive in the assembly-line, this button is used for inserting new design code in the generated callback stubs. When the full meta-design evolution cycle is employed for advanced GUIs, it is used for placing tags to partition the Glade-generated C-source for abstraction of into meta-source parts.

It invokes the selected gang editor with loaded source files from the tsrc subdirectory of current ($newarch) and prior archive ($oldarch) to allow the user to tag and edit the source.

Tagging for Meta Design

The purpose of tagging is to break up the source text modules into parts which can be abstracted into character strings in Perl suboutines, then reprocessed for augmentation, and subsequently reassembled for regeneration in the order they were abstracted but nominally with new dynamically generated parts in place of those which were incomplete in the initial abstraction.

The naming of parts in the tags must adhere to a naming scheme, which defines the sequence in which the parts are abstracted and reassembled. The tags in which the partnames appear are configured by a specific tagging language.

These tags are placed at appropriate locations in the source files. See tags (in blue) placed in this example of an interface.c file generated by Glade.

As the gang editor is useful for multi-pane editing of dissimilar files, it is appropriate for cutting and pasting patches of text from an old design, where the old design and the new design are organized differently. Side by side or above-below window editing is effective with gang editors in this case because the windows do not scroll synchronously. The following screenshots show a gang editing session invoked by this button using the jEdit and Kate editors.



Figure 4.3:1. Gang Editing with jEdit




Figure 4.3:2. Gang Editing with Kate

However, in the subsequent evolution of the same design, where each new version is similar to the prior one, a more appropriate approach is side-by-side meld editing where the two windows scroll synchronously. This is the case with the two lower buttons.

4.4 Meld Glade Update Button

The Meld Glade Update button is used to reconcile previously edited source with a newly generated source from Glade. In this case, the superior features of the Meld editor vastly simplify the reconciliation. The result of clicking the button is a series of Meld editing sessions of the $newarch/tsrc/ files on the left (prior surgery) and the $newarch/isrc/ files on the right (new stubs from Glade). The objective of the editing is to move newly generated code from the right to the left. This is best explained by screen shots of such a session series, as shown below.

Each time Glade generates new output, it entirely replaces some of the generated files, and appends to others. The replaced files are interface.c, interface.h, support.c, and support.h. Glade's presumption is that these files need never be edited downstream. EverGlade, however, overrides this Glade behavior, maintaining the previous versions from $newarch/tsrc on the left, allowing them to be easily modified from any new changes appearing on the right via automatic pasting (the Meld arrows) or by cutting and pasting.

However, Glade would normally append new changes to main.c, callbacks.c, and callbacks.h, causing difficulty in maintaining the synchronization of function order needed for efficient maintenance with Meld. While this is only a minor inconvenience with main.c, it can defeat the purpose of Meld in the case of callbacks.c and callbacks.h, so EverGlade overrides this difficulty.

4.4.1 EverGlade Pre-synchronization of Callbacks

EverGlade maintains lockstep synchronization of callbacks by rearranging the ordering of functions on left and right to be the same. First the ordering of callback functions and prototypes in Glade output files callback.c and callback.h copied to the $newarch/isrc/ directory are arranged in alphabetical order. Then the corresponding (previously edited) files in the $newarch/tsrc/ directory are rearranged in alphabetical order, and any functions in the $newarch/tsrc/ files that do not appear in isrc/ files are placed at the end of the respective file (also in alphabetic order).

Thus, on the left-hand side, Glade generated callback functions will appear alphabetically at the top (corresponding to the ordering on the right), and user-added functions will appear alphabetically at the bottom.

If tags have been previously inserted on the left for Meta-Source partitioning. These tags will be automatically replaced, and new tags will be generated to separate generated callbacks from user-added functions. Otherwise no tags will be present.

4.4.2 Permanent Code Configuration for all Melds

The pre-synchronization of callbacks, performed by this button, permanently configures the ordering of functions in these files for all subsequent meld operations. Thus it must always be performed following each Glade execution. It may be preceded by Gang Editing for New Tags and Design, but it must precede Meld Code to Baseline when Glade has been executed.

4.4.3 Example Sequence of Meld Sessions

Clicking Meld Glade Code Update invokes seven meld sessions in the order of the following examples.

4.4.3.1 Melding of main.c

Figure 4.4.3.1:1 shows the top of the two synchonized buffers from the first session invoked by the button. On the left is the tagged and edited [tsrc] version. On the right is the pristine [isrc] version generated by Glade. Note that its generated comment is no longer valid, as EverGlade does overwrite all files in the [isrc] directory.



Figure 4.4.3.1:1. Glade Update Melding of main.c

4.4.3.2 Melding of interface.c

Figure 4.4.3.2:1 shows the near top portion of the second Meld session, In this case, the version on the right is the pristine version generated by Glade. On the right, a destroy function has been added, as highlighted in blue.



Figure 4.4.3.2:1. Glade Update Melding of interface.c

4.4.3.3 Melding of interface.h

Figure 4.4.3.3:1 shows the third Meld session, showing nearly vacuous Glade-generated text on the right, and the design additions that have been made to the tagged version on the left.



Figure 4.4.3.2.1. Glade Update Melding of interface.h

4.4.3.4 Melding of callbacks.c

Figure 4.4.3.4:1 shows near-top portion of the fourth Meld session, showing the Glade generated declarations and stubs on the right and the surgery expanded declarations on the left.

Figure 4.4.3.4:2 is slightly scrolled down, illustating inserted surgery highlighted in blue added by surgery to the stubs on the right.

Figure 4.4.3.4:3 is scrolled further down, where the blue highlighting by Meld illustrates surgery insertions in the synchonized stubs on the right.

Figure 4.4.3.4:4 is scrolled to near the bottom of the file where tags delimit the callbacks on the left above from the user-added functions below.



Figure 4.4.3.4:1. Glade Update Melding of callbacks.c near top of file




Figure 4.4.3.4:2. Glade Update Melding of callbacks.c scrolled down slightly




Figure 4.4.3.4:3. Glade Update Melding of callbacks.c synchonized with stubs




Figure 4.4.3.4:4. Glade Update Melding of callbacks.c and user-added functions

4.4.3.5 Melding of callbacks.h

Figure 4.4.3.5:1 shows the bottom portion of the fifth Meld session, where the generated tags on the left separate the callback prototypes from the user-added function prototypes.



Figure 4.4.3.5:2. Glade Update Melding of callbacks.h

4.4.3.6 Melding of support.c

Figure 4.4.3.6:1 shows the top portion of the sixth Meld session, where the right version is pristine code generated by Glade (without tags), and the left version shows an added tag.



Figure 4.4.3.6:1. Glade Update Melding of support.c

4.4.3.7 Melding of support.h

Figure 4.4.3.7:1 shows the top portion of the seventh Meld session, where the right version is pristine code generated by Glade (without tags), and the left version shows an added top tag.



Figure 4.4.3.7:1. Glade Update Melding of support.h

4.5 Meld to Baseline Button

The Meld to Baseline button is used to compare a new archive mutation generated by Glade with the baseline source (tagged or not). The result of clicking the button is a series of Meld editing sessions of the $newarch/tsrc/ files on the left and the $baseline/tsrc/ files on the right.

The objective of this meld may be simply to check for differences between upstream source code, that may have been chanced due to Glade artwork changes, or surgery implementing changes to filled in callbacks, and source that has been through downstream make and testing during a previous evolution cycle.

Since the baseline tree is also used as the interface to version control, another purpose is to compare upstream source to baselined source to downstream source that has been updated and committed to SVN by a colleague. This would be code such as changes to callbacks and user-added functions that do not reflect Glade artwork changes to the GUI.

4.6 Send Source to Baseline/Build Button

This button is used to bypass meta-design processing for GUI projects which do not need it. It copies source files from the current archive tsrc directory to the baseline tsrc directory and to the final path GUIbuild directory, from which the make process takes its input.

5.0 Meta-Design Processing

Top

The Meta-Design tab brings up buttons used for generating, editing, and finalizing the Perl meta-source module, PROJECT_gen.pm, in preparation for its use by an external regeneration driver to produce the final GUI source code.



Figure 5.0:1. EverGlade GUI and Meta Design Processing Tab

5.1 Meta-Source Module Generation

The Generate Module button converts the seven source files into a single Perl module, called PROJECT_gen.pm. It invokes the EG_genmeta script, which in turn sequentially executes the metagen.pl script to process $newarch/tsrc files: main.c, interface.c, interface.h, callbacks.c, callbacks.h, support.c and support.h, producing the common output file $newarch/rawgen/PROJECT_gen.pm.

All of the content in all of the files will be organized into a set of perl subroutines, which are divided into two categories:

  • "comment subroutines" having names like "main_PATCH0", or "interface_PATCH13", and
  • "regenerator subroutines" having names like "load_partname", "build_modulename", "toploop_partname", "subloop_partname", or "append_partname.

The comment subroutines will contain empty text or text that provides exemplary information generated by Glade, to be replaced with looped meta-design (LMD) Perl code, to produce the proper design at this station in the source code.

The regenerator subroutines named "load_partname" will be functions containing meta-source text in here-documents or text-assignment statements. They will return text strings containing static parts when called by text-assignment statements appearing in "build_modulename" subroutines.

The regenerator subroutines named "toploop_partname" and "subloop_partname" are actually stubs that must be completed manually for generation of dynamic parts. They mostly contain lines of Perl comments, each being a C-statement generated by Glade that is merely a dummy example to be used as a guide in crafting Perl loop-element statements, which manifest as calls to the "append_partname" subroutines for the dynamic part associated with the subject toploop or subloop.

5.2 Meta-Source Module Refinement

The generated output is "raw" meta-design, stored in $newarch/rawgen, from which it must be refined by editing for storage in $newarch/fingen. This refinement operation is performed by the next script, EG_fixmeta, which loads editors for manual refinement of the raw meta-design. This script is invoked by either of the next three buttons, Gang-Edit New Module, Meld-Evolve Last Module, or Meld-Evolve Base Module, depending on the stage of refinement being invoked.

5.2.1 Gang-Edit New Module Button

Gang editing is editing of multiple buffer editing with the selected gang editor.

When the meta-source module is generated for the first time, there may not be a prior design pattern to build upon. However, EverGlade will attempt to find one. This button loads the newly generated module from $newarch/rawgen into the gang editor, along with the previously generated version from baseline/fingen, if one exists, or last achive/fingen, if one exists. Otherwise only the single file is loaded. Then other files may be loaded into the gang-editor for unsynchronized gang editing.

The purpose is to flesh-out the design of the generated Perl looped meta-design stubs to complete toploop and subloop subroutines for dynamic part generation of widgets such as menus.

If there is another GUI program available which can be used as a design guide, even if it is mostly dissimilar to the current design, a good approach is to start the project with two identical archives from the new Glade GUI (run mutate archive twice with the same new project name); then copy the other project source code into the first archive for use as a design reference. Clicking this button will invoke the gang editor with both files loaded. In this case, since the two files will be highly dissimilar in organization even if similar patches exist in each, unsynchonized gang editing enables scrolling one window into juxtaposition with the other for convientient copying and pasting.

When editing is complete, be sure to click the save button in the editor to save the edited file in its default $newarch/rawgen subdirectory. When the editor is exited from the session, the EG_fixmeta script then copies the edited file $newarch/rawgen/PROJECT_gen.pm to $newarch/fingen/PROJECT_gen.pm.

5.3 Meta-Source Meld Refinement

After the original fleshing out of the looped meta-design stubs, the organization of the any two mutations is likely to be similar enough in organization that synchonized meld editing is effective. The two Meld-Evolve buttons load the $newarch/rawgen version of PROJECT_gen.pm on the left side, and its $benchmark/fingen version on the right side. The $benchmark is chosen by priority, where the highest priority benchmark is chosen if it exists. If not, then the next priority benchmank that exists is chosen, and so on until an existing benchmark is found.

At the end of the editing session, the edited left-side version must be saved by clicking Meld's save button, before exiting Meld. Then the EG_fixmeta script will copy the edited file $newarch/rawgen/PROJECT_gen.pm to $newarch/fingen/PROJECT_gen.pm.

5.3.1 Meld-Evolve Last Module Button

This button calls EG_fixgen, selecting the last archive version as the benchmark from which to start the existence check.

5.3.2 Meld-Evolve Base Module Button

This button calls EG_fixgen, selecting the baseline version as the $benchmark from which to start the existence check.

5.4 Delivery Buttons

The last two buttons on this page deliver the current working copies to version control and final processing (make) destinations. This presumes that current editing is complete, and the PROJECT_gen.pm module in $newarch/fingen and all its constituent source files in $newarch/isrc and $newarch/tsrc are ready to be delivered.

5.4.1 Update Baseline MetaSource for VC

This button delivers source and meta-source to the baseline tree, PROJECT_base, in the ~/EVERGLADE/Assembly/PROJECT/VC directory, which is a SVN working directory, after which, kdesvn can be used to commit the files to the SVN repository.

5.4.2 Update GUIbuild MetaSource

This button delivers the PROJECT_gen.pm module to the GUIbuild directory in the Final Path, which is the staging directory for Generation Processing.

6.0 Generation Processing

Top

The final EverGlade steps involve source code generation from meta-source and GUI executable file generation from source code (make).



Figure 6.0:1. EverGlade GUI and Generation Processing Tab

6.1 External Driver Regeneration

The left side of the Generation tab regenerates the GUI C-source from meta-source, usually by invoking an external driver to flesh out one or more dynamic GUI parts, such as menus.

6.1.1 GUIbuild Datakey

If the GUI is the kind that is dynamically generated as a by-product of an external process, EverGlade must initiate that process and feed it information as to its source of data. That purpose is served by the GUIbuild Datakey. This is the name of a configuration file resident in the GUIbuild subdirectory of the Final Path. Ordinarily, the name of the Datakey is the name of a project within the external process.

If the GUI is completely static, requiring no external process, then no Datakey is required, and this entry box is left blank.

6.1.2 Source Regeneration Button

As the name of the external process is the same as the Project Name, EverGlade presumes that this is also the name of a command script which executes the process. So the Source Regeneration button executes that command script with the GUIbuild Datakey as its parameter

6.2 Build GUI Executable Program

In the final development step EverGlade executes the Make process to compiler and link the GUI executable. The first two buttons are used in the make cycle for convenience in correcting the source files in response to make errors, and in replacing these source files in the $newarch/tsrc directory, once make is successful.

6.2.1 Gang Edit GUIbuild Source Button

This button loads all of the source files from the [Final Path] GUIbuild directory into the gang editor facilitating correction of make errors.

6.2.1.1 Archive GUIbuild Source Button

This button copies the source files from the [Final Path] GUIbuild directory to the $newarch/tsrc directory, where they can be melded with Glade output after new changed are made with Glade. It complements the Send Source to Baseline/Build in the Assembly Line page (Figure 3), when Meta Design is being bypassed (no tags).

6.2.2 Make Button

Clicking this button executes the GUIMAKE script, which copies the GUI C-source files from the target GUIbuild subdirectory in the Final Path to the ~/EVERGLADE/GladeWork/PROJECT/src where they were originally generated into by Glade. Then ~/EVERGLADE/GladeWork/PROJECT/Makefile is executed by make with output directed to the local 'makeout' file.

6.2.2.1 Install Check Button

Activating this check button causes the project executable to be installed in ~/PROJECT/bin or in ~/bin.

6.2.3 Run Check Button

Activating this check button executes the project executable.

7.0 Reverse Engineering Evolution

Top

Sometimes, key flaws in a full-evolution design are not uncovered until they are revealed during testing. Then the design is subsequently evolved experimentally via a surgery-make-text subcycle that may cause it to significantly diverge from the original Glade-specified design. Such a process can play havoc with an organized fabrication process designed to maintain upstream and downstream design in lockstep as illustrated by the yellow cycles in Figure 7.0:1. Often, this is where the original metaphoric evolution process is abandoned, and subsequent evolution continues in this make-surgery cycle.



Figure 7.0:1. Make-Test Design Surgery Subcycles

If, on the other hand, it is desired to preserve the whole metaphoric design cycle, so that Glade may be employed for significant stylistic changes and metaphoric extensions in functionality, and Perl programmed meta-design may extend this metaphoric functionality. Then the code altered in the downstream make-test cycle must be reverse engineered, as indicated in Figure 7.0:2, back into meta-source (light-green arrows), and from meta-source back into tagged-source (turquoise arrow), which may be melded with future Glade-generated source stubs.



Figure 7.0:2. Reverse Engineering Reconciliation

These purposes are served by the right-most tabbed page in the EverGlade notebook. Gang editors play a far more important role in reverse-engineering surgery, as it involves multi-paned comparison of meta-source code to source code, which often can't be synchronized via Meld.



Figure 7.0:3. Re-Engineering from Make back to Glade

7.1 Re-Engineering Meta-Source to match Made Source

The two buttons at the top of this page invoke a sequence of seven meld or gang editing sessions, comparing three window panes, and an eighth session comparing two panes, from files present in the GUIbuild directory within the External Driver Path.

7.1.1 First Seven Sessions - Reconciling Meta-Source Parts to Source Files

In the first seven sessions, the left pane will contain the part of the meta-source module corresponding to the source files in the center and right panes. Figures 7.1.1:1 to 7:1.1:5 show examples.



Figure 7.1.1:1. Meld of mainc_part compared to main.c and archive/main.c

Figures 7.1.1:1 and 7.1.1:3 illustrate the inadequacy of Meld for comparing meta-source to source. Meld's limited differencing logic essentially capitulates when there is a difference in every line, causing its erroneous synchronization of panes containing such differences to block effective editing.




Figure 7.1.1:2 jEdit session of mainc_part compared to main.c and archive/main.c

Figure 7.1.1:2 illustrates the superior features of jEdit for gang editing of meta-source to source. Although each pane must be scrolled separately, panes of any conceivable combination of side-by-side and upper-lower comparison are simple to configure. The "roladex" file selection at the top of each pane (illustrated open in the right pane), makes it easy to select and switch buffers. When a buffer has been altered, the diamond in the roladex becomes red.




Figure 7.1.1:3 Meld of interfacec_part compared to interface.c and archive/interface.c



Figure 7.1.1:4 jEdit session of interfacec_part compared to interface.c and archive/interface.c

Figure 7.1.1:4 illustrates the juxtaposition of looped meta-design on the left to the generated result on the right. Since the object of reverse engineering is to detect needed meta-source changes on the left to compensate for actual source changes on the right made during the make cycle, this requires mentally transforming the output back into the logic which produced it.




Figure 7.1.1:5 jEdit session of interfacec_part compared to interface.c and archive/interface.c

Figure 7.1.1:5 illustrates another portion of the same session as Figure 7.1.1:4, where static meta-source contained in a Perl "here document" on the left is merely a container for the actual source patch shown in the center pane.

7.1.1.1 Left Pane - Meta-Source Part to be Updated

The code contained in the left pane is extracted from the meta-source module contained in GUIbuild, specifically for comparison to the source code of the two right panes. Because meta-source is a container for generating source, the relationship of meta-source to source is easy for a human to recognize and edit, but the computer is not much help, as when comparing source to source. Meta-source consists of a set of Perl subroutines which produce the source code when executed.

In the case of gang editing, this placement in the left pane is by convention. The configuration of the panes and the selection of content for their respective buffers must be performed by the user. It is not automatic, as in the case of Meld.

7.1.1.2 Center Pane - The Source File that was altered in the Make Cycle

The code in the center-pane buffer is (conventionally) the source file in the GUIbuild directory that was altered in the make cycle. Thus it is the source from which changes are to be transferred into the meta-source contained in the left pane.

7.1.1.3 Right Pane - Original Source File before alteration in the Make Cycle

The code in the right-pane buffer is (conventionally) the source file in the GUIbuild/archive subdirectory, where it was placed by the Source Regeneration button in the Generation page, before the Make button was clicked for the first time in the make cycle. Thus it is merely employed as a benchmark to remind the user which changes were made in the make cycle. Unfortunately, in gang-editing, these changes are not highlighted, as they are in Meld, so the user must carefully scan the center and right panes for differences.

7.1.2 Eighth Session - Validation of Meta-Source

The eighth session is always a Meld session, since it is a comparison of GUIbuild meta-source module (reassembled from the edited meta-source parts) on the left to the original meta-source module saved in GUIbuild/archive by Source Regeneration button in the Generation page, before the Make button was clicked for the first time in the make cycle. Figures 7.1.2.1 and 7.1.2.2 illustrate top and botton views of the eighth session.




Figure 7.1.2:1 Top view of meta-source validation session



Figure 7.1.2:2 Bottom view of meta-source validation session

The bottom view shows that the final assembly subroutine, produced by the Source Regeneration button in the Generation page, somehow was deleted in the make-cycle revisions, as well as the "1;" which terminates a Perl module.

7.2 Re-Engineering of Tagged Source from Meta-Source

This reverse-engineering step corresponds to the turquoise arrow in Figure 7.0:2. It is invoked by the second pair of buttons in Figure 7.0:3. It involves seven comparative editing sessions, with meta-source parts in the right pane from which changes are to be made to the tagged source files in the left pane. When the editor's Save button is clicked, the edited source file is then saved in the tsrc subdirectory of the latest archive in the current project within the assembly tree.

This enables project design to resume with the left four tabs, beginning with Glade Design rework, which generates new source stub files placed in the isrc subdirectory for direct reconciliation with the reverse-engineered tagged source in the tsrc subdirectory.

Once again, Meld synchronization is of little use in comparing source to meta-source, so gang editing is called for. Of course, the user must configure the panes in this case, with meta-source on the right and source on the left (by convention). Figures 7.2:1 and 7.2:2 illustrate the use of the kate editor in two of the sessions.




Figure 7.2:1. Gang editing of callback.c versus callbackc_part with kate



Figure 7.2:2. Gang editing of interface.c versus interfacec_part with kate

7.3 Evolution Between Arbitrary Design States

The bottom frame of the Make Back page provides for meld or gang editing of two versions of any of the source or meta-source files from any two states.

Figure 7.3:1 shows the files available for selection for the given project. Figures 7.3:2 and 7.3:3 shows the archive trees from which files may be loaded into the left-side and right-side buffers respectively, when either the Meld or Gang button is clicked. When a backup file (filename with appended ~) is selected, the check boxes choose which side (pane) is to be the backup file. If both are checked then both buffers will contain the backup version for that tree. Note: if the tree is the same, and both boxes are checked, then the same file will appear in both panes.

This behavior applies only when the selected file has a tilde (~) appended.




Figure 7.3:1



Figure 7.3:2



Figure 7.3:3