You may also be interested in the User's-documentation.
A mred-id% object is an abstraction of a widget. From it, a widget can be created, or recreated if its properties have changed.
A mred-id% is created out of a mred-plugin% (a mred-id% factory). Each plugin is a folder in the "widgets" folder. They are loaded automatically on startup, and buttons in the main frame are created. Clicking on them instantiate a new mred-id% and its initial associated widget.
Some modules have tests at the bottom of the file. Here is a description of the different modules:
Main file, that launches the project.
Defines the frame that contains the hierarchy widgets (which should be in a separate "hierarchy-widget.rkt" file ?). The hierarchy widget is now a hierarchical-list%, which was easier for me to use.
Defines the frame where the properties of a widget can be modified by the user.
Among with other buttons, this frame contains the buttons of the plugins which are added automatically.
This module controls the general behavior of the application. It sends signal to and receives signals from the 3 main frames: toolbox-frame, property-frame and hierarchy-frame.
Contains a tooltip%% mixin that can be applied to any subwindow class.
Define a particular dialog% to edit default values for list boxes.
Defines several generic widgets.
This is a generic (usable outside MrEd Designer) module that applies a given user procedure to a folder hierarchy. Each folder is treated as a plugin. The current-directory is parameterized to this folder, and the name of the folder is given as an argument to the user procedure. A partial order sequence of the folders (plugins) can be given, as well as a list a of folders to omit.
Each widget is a plugin that belongs to the "widgets" folder.
This module loads the widgets with dynamic-require and makes a
mred-plugin% object out of it.
This object contains several information, notably the initial property values of the widgets of this class.
This directory contains the widget plugins, that will be `dynamic-require'd on application startup.
The "widgets/load-preferences.rkt" file contains the sequence order and the "don't load" definitions for the plugins. Non listed plugins will be loaded after the others.
Each widget plugin folder must contain a widget.rkt file and two icons named icons/16x16.png and icons/24x24.png.
The widget.rkt file must contain a
Its last list of arguments are the definitions of the widget properties.
For more details on these arguments, see here.
A "property" is the definition of a `(field value)' form that is given to the creation of a plugin widget with
new (see the widget.rkt files in the widget plugins).
Defines the classes that hold bits of properties. A property is a property-field% that holds the name of the identifier field, and a property that holds a description of the associated value. The property value is made of other properties.
Transforms the property objects into widgets so that the user can modify them. The widget values are synchronized with the properties.
The widget plugins only use the properties, and not the property-widgets.
Almost abandoned file. Should be merged with mred-id.rkt?
Contains definitions of useful properties, like fonts, image-labels, etc., that can be used in widget plugins.
Because it is not possible to modify the values of a ('widget after its creation, it has to be recreated each time a value changes. A mred-id% object contains the properties corresponding to the widget definition. It is thus the "model" of the visual widget.
Generic code writer.
It is a serializer/deserializer that outputs constructor code instead of simple data.
For example, a class that inherits the code-write%% mixin can declare fields that will be code-writable, with:
A class can also redefine its output constructor code.
This module is used to write template and project files.
The name "code-write" is misleading because it does not write anything, it merely returns Racket data. Writing it to a file is up to the user.
Contains the function to write the generated code from a project. How widget code is generated is defined in mred-id.rkt, and uses values defined in the widget.rkt of the plugins.
Defines the functions to manage template files. A template is like a user project file, but where the root node is not a project%, but any kind of widget. A template can be inserted several times in the current project under the selected node (if the parent-classes match). Ids are renamed if necessary to avoid duplicates.
Cut/Copy/Paste and projects are implemented in terms of templates.
Templates are loaded by this module.
Contains the user template files. There is normally no need to sneak in here.
Contains several generic tools that are used in many of the modules.
define/provide to avoid writing identifiers twice.
Contains also a
getter/setter hygienic (? at least it uses
with-syntax...) macro that eases the definition of getters and setters for class fields.
Contains callbacks for the Help menu.
This file is for internal purposes only (cleaning the project, deleting non-useful files, etc.). Warning: some functions may delete the svn folders. Use with caution!
This folder contains tests for projects and generated code.