As GML is runtime-checked, we should have tests that compile GML and load the widget from GML just to validate that the GML actually works. This will help us to not regress GML compatibility or auto-check that GML contributions are actually valid.

While it is in theory not a complex task, there are two major hurdles:

• LibGUI needs to compile on Lagom, at least all the widget, layout, and painting code; the window server connection stuff doesn't need to be functional. It appears that #12485 should make this possible, though it's currently stale and I haven't tested whether it's actually the case.
• Custom widget registrations done in specific apps are most likely not registered if the object file that calls REGISTER_WIDGET is not linked with the gml validation binary. This is a big hurdle for a lot of specialized applications that have a lot of custom widgets registered. A possible workaround is to ignore failures due to a non-registered widget, like the GML playground kind of does. This should print out a warning of course, and the user must manually check that the widget is registered. Any other solution would involve some central location that contains all registered widgets again, just for this validation binary, which is a massive inconvenience. If someone has a good idea on how to solve this, however, I'd like to hear it. Maybe we need to refactor Core::Object registration?

Either way, more automation in GML would allow us to speed up contribution workflows around GML significantly and reduce the possibilities of introducing bugs and regressions.