Widgets are the visual building blocks of every RedEye layout. Each widget maps to a .NET Windows Forms control and is declared as an XML element inside aDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/ryzhpolsos/redeye/llms.txt
Use this file to discover all available pages before exploring further.
<window> in RWML. When RedEye parses your layout file, it instantiates each element as a widget, applies its attributes, and adds the resulting control to the parent window or container. You can combine any number of built-in widgets — and widgets exported by plugins — to compose any desktop surface you can imagine.
Widget lifecycle
Every widget follows a four-phase lifecycle that runs in order during shell startup.Initialize
The widget’s underlying Windows Forms control is created and stored. Services the widget depends on — such as the resource manager and logger — are resolved from the component manager. This is where one-time setup like event listener registration happens.
UpdateConfig
All XML attributes are read from the widget’s config node and written into the widget’s
ShellWidgetConfig object. Because attribute values can contain expressions, this phase evaluates variables and functions and produces concrete values. If updateInterval is set, this phase runs on a background timer.UpdateControl
The values stored in
ShellWidgetConfig are applied to the actual Windows Forms control: size, position, colors, fonts, and so on. This phase always runs on the UI thread and re-renders the control.PostInitialize
Runs after all widgets in a window have been initialized. Parent-child relationships are resolved, tooltip handlers are attached, and container-specific finalization (like table layout cell placement) is applied. This is where widgets that reference other widgets by
id do their wiring.updateInterval is greater than zero, the UpdateConfig → UpdateControl sequence repeats automatically on a background thread at the specified interval, letting widgets display live data without restarting the shell.
Common attributes
Every widget — whether built-in or from a plugin — inherits the following attributes fromBaseShellWidget.
Unique identifier for the widget within its window. Used to reference the widget from other widgets (for example, the
for attribute on <contextMenu>, or the parent attribute for reparenting). If omitted, a GUID is assigned automatically.Horizontal position in pixels relative to the parent container or window origin.
Vertical position in pixels relative to the parent container or window origin.
Width of the widget in pixels.
Height of the widget in pixels.
Docking behavior. Accepted values mirror
System.Windows.Forms.DockStyle: none, top, bottom, left, right, fill.Anchor edges. Combines
AnchorStyles flags, for example top, left.When
true, the control resizes itself to fit its content.Outer spacing around the widget. Accepts one to four comma-separated pixel values following the Windows Forms
Padding convention: all, left,top,right,bottom, or horizontal,vertical.Inner spacing between the widget border and its content. Same format as
margin.Foreground (text) color as an HTML color string, for example
#ffffff or red.Background color as an HTML color string.
Font descriptor passed to
ParseHelper.ParseFont, for example Segoe UI, 10.When
true, sets the control’s background to Color.Transparent, making the window background show through.Z-order index within the parent container. Higher values appear on top.
-1 means append order.Milliseconds between automatic
UpdateConfig + UpdateControl cycles. 0 disables the timer. Use this to refresh live data such as clocks or system stats.Text shown in a tooltip when the user hovers the widget.
id of another widget to use as the Win32 parent control. Overrides the default parent set by the container hierarchy.Event attributes
Any attribute whose name starts withon is treated as an event handler. The attribute name maps directly to a Windows Forms event on the underlying control — for example onClick maps to the Click event. The value is an RWML expression that is evaluated when the event fires. Event arguments are exposed as arg0, arg1, etc.
Container widgets vs. leaf widgets
RedEye distinguishes two kinds of widgets. Leaf widgets extendBaseShellWidget directly. They wrap a single Windows Forms control and do not manage child widgets. <label>, <button>, <image>, <textBox>, <webView>, <windowList>, <appList>, <contextMenu>, and <externalProcess> are all leaf widgets.
Container widgets extend BaseContainerWidget, which itself extends BaseShellWidget. A container owns a collection of child widgets, adds their controls to its own panel, and propagates UpdateConfig and UpdateControl calls down to every child. <panel>, <flowPanel>, and <tablePanel> are container widgets. Some leaf widgets such as <windowList> and <appList> manage their own child controls internally but do not implement IContainerWidget — they use a template node to instantiate children dynamically.
Widget element names
Widgets are referenced by their lowercase XML element name. The mapping from element name to implementation class is registered at startup. Built-in element names are:| XML element | Class |
|---|---|
<label> | Label |
<button> | Button |
<image> | Image |
<panel> | Panel |
<flowPanel> | FlowPanel |
<tablePanel> | TablePanel |
<textBox> | TextBox |
<webView> | WebView |
<windowList> | WindowList |
<appList> | AppList |
<contextMenu> | ContextMenu |
<externalProcess> | ExternalProcess |
Element names are case-sensitive in RWML. Use the exact lowercase/camelCase spellings shown above.
Learn more
Built-in widgets
Full reference for every built-in widget, including all widget-specific attributes and XML examples.
Exporting widgets from plugins
Register custom widget classes in a plugin so they are available as XML elements in your layouts.