The attached patch is a beginning step - it has the visitor interface for the screen sub-widgets, and it adds the necessary accept method to the sub-widgets. There is no interface implementation.
The screen widget model classes already use a pattern similar to visitor called double dispatch. Essentially, the ScreenStringRenderer implementation calls the renderWidgetString method of each widget, and that widget method calls the renderXxxx method in the ScreenStringRenderer. With the visitor pattern, the renderWidgetString method is called accept, and the renderXxxx method is called visit. So, it's basically the same design but with a slight difference.
In the current code, the visitor (ScreenStringRenderer) passes a number of arguments to the model widget renderWidgetString method. In the attached patch, the visitor (ScreenWidgetVisitor) passes only itself as an argument to the model widget accept method. The reason for this difference is flexibility and expandability. Set up this way, the visitor could be anything - a renderer, an artifact info gatherer, a pretty printer, etc. There is no implementation implied in the design.
Each renderer would implement ScreenWidgetVisitor. The code inside each model widget renderWidgetString method would be moved to the corresponding visit method in the renderer. Likewise, the artifact-info-gatherer would implement ScreenWidgetVisitor. The existing model widget artifact-info-gathering code would be moved to the corresponding visit method in the artifact-info-gatherer.
Once those changes are made, the model widgets will contain only object construction code. Even that code could be moved to a builder class that implements ScreenWidgetVisitor.
The benefit of this change will be improved separation of concerns. Right now the screen widget model classes try to be everything to everybody. After the change they will be little more than data structures that various behavior-specific objects will refer to. Rendering code is not mixed in with object construction code or with artifact-gathering code. The API is simplified.
A change like this could have serious downstream consequences for OFBiz users who have modified the screen widget model classes. One approach we could take is to put the visit methods in ScreenStringRenderer (instead of having a separate interface) and then deprecate the existing renderXxxx methods. The downside is code maintainance - bug fixes and new features will have to be applied to both patterns.
If you believe the change is worthwhile, then please vote on this issue.