All GML-based applications should use the new (proper) GML compiler, which allows us, among other things, to verify in CI that the GML is well-formed to a high degree. This is a task list for all applications which still need this done. To find a candidate yourself, just search for stringify_gml, the old non-compiling GML method, in the CMake lists.

Porting an application usually involves the following steps, assuming that there already is a dedicated widget class for the GML definition:

• In the CMake list, replace stringify_gml by compile_gml, replace the header with a CPP file, move that CPP file to the SOURCES (and usually delete an empty GENERATED_SOURCES).
• Remove the includes of the old header file.
• Remove any REGISTER_WIDGET macros in the application.
• If not present, add a try_create method to the appropriate widget. The compiler error on the generated file will tell you how that must look exactly.
• If the widget has its own extra setup, try_create must be private. Change the setup steps so that the widget first calls try_create (which is generated from GML and will perform initial setup), then it performs its own setup. Remove any load_from_gml calls.
• If the widget has no extra setup, any previously existing try_create can just be removed (including all load_from_gml calls). try_create must then be public. Move extra setup to a public method ErrorOr<void> initialize(); see #22860
• Change the widget class in the GML file so that it matches the actual widget class. Since the top-level widget class is ignored by load_from_gml, many applications incorrectly use GUI::Widget. The class must contain a namespace; if necessary, you have to put the widget class into a namespace matching the application name. The widget's class name and file name must also match (though this is most often the case), so the file might need to be renamed.
• Audit all manual initialization for any code that can be replaced by GML property setting; see #22918

The only real place for error is an incorrectly public try_create or failing to call try_create in the custom setup function; any other error is caught by the compiler.

In some instances, the GML compiler needs to learn about new special cases not encountered before, like string argument types, enum properties, etc. I can't always predict when this is necessary, even though I'm certain most of the special cases are accounted for.

• CertificateSettings, CalendarSettings, Calendar, Calculator, BrowserSettings, Run (#20524 )
• Browser
• CharacterMap #22174
• ClockSettings #22174
• CrashReporter #22442
• DisplaySettings
• Escalator #22469
• FileManager
• FontEditor
• GamesSettings #21271
• HexEditor #21271
• KeyboardSettings #22685
• Mail
• MailSettings
• MouseSettings
• NetworkSettings #21271
• PartitionEditor
• Piano
• PixelPaint
• SpaceAnalyzer #21238
• Spreadsheet
• SystemMonitor
• TerminalSettings #22512
• TextEditor
• ThemeEditor
• VideoPlayer #21271
• Welcome #22471
• ModelGallery
• WidgetGallery
• GMLPlayground
• HackStudio
• SQLStudio
• 2048
• Flood #20552
• GameOfLife
• Hearts #22648
• MasterWord #21221
• Minesweeper #21230
• Snake
• Solitaire
• Spider
• AboutDialog
• EmojiInputDialog
• FontPickerDialog
• FilePickerDialog
• IncrementalSearchBanner
• PasswordInputDialog

When this task list is completed: Don't delete the load_from_gml function or Playground! They are here to stay. However, the stringify_gml CMake function can be removed.