The first application for the Unnamed Grand Project should be a site designer. This allows people to make Sites (aka web pages without the web) without necessarily having any programming knowledge. It would be a cross between a spreadsheet, GUI designer and web page editor. The Site Designer would be the starting point for writing code as well.

Below are ideas only.

Types of Sites to make (i.e. templates):

• Applications - e.g. word processor, drawing programs, image editors, ...
• Database applications (should have special support because these are very common)
• Text and images like web sites.
• A library package, which doesn't have any Site instances but does have a model definition.

Text-like sites would have a flow like web sites: the page is a vertical list of paragraphs with text. Images can be inserted. Panels can be visible with menus to other pages. The model of this page would be a hierarchical collection of documents, with the hierarchy appearing as a menu on the site somewhere. The view of this page could determine the placement of the text, images and menus as well as their appearance.

Database applications are very common; database-like applications should be able to be made without writing code. The model would define the tables, their relationships, the columns in those tables and their behaviour.

Applications would require code. Code would be able to be implemented anywhere. The development environment should be able to show the implementation of any widget on the screen. There could be two views available: the UI and the model. The UI would be where the forms are defined. The model would be something akin to a UML editor, with the ability to edit and run code.

User interface elements observe a model. Their implementation is usually not of interest to the developer unless the developer is designing custom widgets. Buttons are views on a Action object.

Editing code

Code can be reached by:

• clicking (double-clicking?) on a model in the UML editor. If the UML is detailed enough and individual methods are shown, then individual methods can be clicked on.
• Selecting a context menu operation from a UI widget. For example, editing the action of a button will pop up a code editor on the implementation of that button's action.

The code editor would always be available, but would not be shown to people who don't know how to use it (i.e. it would be a menu option they would typically avoid). In this way, the GUI editor could function as a word processor or basic database-like application designer (etc) without the user writing any code.

The code editor could be just a pane with code and the description of what you're editing, with a bunch of buttons which pop up various selectors.

The description of what you're editing would show what the code pane is showing:

• "Namespaces.ClassName>>methodName" would mean that a method is being edited.
• Ditto "Namespaces.ClassName class>>methodName"
• "Namespaces" would show a namespace definition.
• "Namespaces.ClassName" would show a class definition.
• "Namespaces.ClassName documentation" would show documentation.
• "Namespaces.ClassName method categories" would show the method categories.
• "Namespaces.ClassName hierarchy" would show the inheritance hierarchy of that class.

In fact, the description could consist of drop-down menus so that individual entities could be selected. The description could have an "expand" button to make those drop-down menus turn into list boxes.

Alternative uses of the Site Designer

The site designer is designed to be a generic tool for making Sites. We assume that the Site is initially created using a template of some sort.

• It could be used like a word processor by having no menus and a single "Text" pane.
• It could be used to make simple database-like applications by making a UI and a model. Pre-made buttons such as "Add", "Delete", "Open another panel" could be made. Other data-oriented widgets such as lists, tables, etc could be made available. The model could consist of "Table" objects which have an editor that lets a naive user define columns of particular types.
• It could be used to make simple applications that behave like a spreadsheet. A UI would be a free-form spreadsheet except that the user needs to add "Calculator" widgets to it. These widgets can then have either Smalltalk code or "spreadsheet" code defined on them. Each would have a name and each would be able to refer to the value of other "Calculators" by name. "Lists" and "Tables" would also be available, but by now we are approaching the database-like applications.
• A more complex "Site" could be developed. The model would define the structure of the site: what the hierarchies of pages are, how searching works, etc. The views of that site would display these to the user. Custom widgets could be included.

A cool feature would be to make any of the above available as a custom widget that can be inserted into somebodies site.

Storing the GUI

The GUI could be stored in automagically generated code. A project would have a main "Site" page which is a class with a constructor method. The constructor method is executed in such a way that the site designer's special editable widgets are created and added rather than the default non-editable widgets.

When the user modifies the placement of those widgets, the code is automagically modified. This could be done by making the entire method automatically generated by iterating through the editable widgets and writing code for each to a code stream.

The code editor would need to be aware that the method is automatically generated (pragma?) so that it can warn the user if the user tries to edit it.

Layout

I like TableLayout. It is generic enough to be useful for nearly every UI, yet very powerful.

An interactive editor for this could resemble a spreadsheet. Widgets can be added to the spreadsheet. Columns and rows can be defined as "Preferred", "Fill", "Weighted" (i.e. allocated a certain amount of the total available space) or "Fixed" (e.g. number of mm). Widgets can have justifications of "left", "right", "top", "bottom", "center" and "fill" their cells. Widgets can span several cells. Rows and columns can be added, inserted and deleted.

The GUI editor would need to have a non-wysiwyg minimum cell size so that cells of size 0 are visible. Otherwise, cells with no widgets will not be interactive.