This is what I do. I stick to the road map. If you guys think this is to big steps, I can create patches after each dialogue but since I'm going a bit forth and back in how things are implemented it would sometimes be more extra work for you guys to implement the same things while I changes some implementations...
Let me know how often you want me to send patches...
I'd say a good moment to submit a patch here will be when you have replaced all the macro usage and dialog hardcoded values by variables, on all dialogues. I'd focus that first, just defining a set of default values for that variables, a "default" theme. It must be a patch that's ready for inclussion on the trunk code, that's expected to contain a few minor bugs (that's work-in-progress quality, ready for nightly and deveoper testing).
Additional modification of dialogs (i.e. making them scalable or modifying the class hierarchy too much) should be done in a posterior iteration. I'd do it that way, but ofc, that's just my oppinion.
I noticed that the painting (zeichnen) is called every frame, even if the dialogue hasn't change. One thought would be to at the end of zeichnen save the dialogue as an off screen image.
Next time, if the dialogue hasn't change, paint the off screen image instead. This also applies when moving a dialogue, just move the off screen image instead.
As soon the dialogue is marked dirty, call zeichnen again to to get a new off screen image. This would speed up the frame time quite a bit.
See, you are about to grow the snowball here, and wide the amount of work you need to do. It's not a bad idea, but I don't personally think it's worth it, the perfromance increase whould be too low to justify this change, and adds complexity and mantainability problems. I'd refrain to do this, at least for now. If you want to experiment with this, I'd add as a project item, but leave it for later development iterations.
All resize stuff, aligning controls to an edge or stretching, is done in zeichnen. This calculations are only needed when the client area is resized.
Normaly a GUI system has a resize event handler that takes care of this, aligning controls. This will reduce the time spent in zeichnen and speed up the frame time a little bit more.
I think this is a better idea, and it might be really worth implementing (whould be a "cache" of pre-calculated dialog vaules), but again, I'd pospone this for later. Take into caccount that GUI drawing it's *not* a performance problem in simutrans now, no need to code too much here, all changes should be focused on readibility, modularity, flexibility and mantainability of the GUI, performance is not critical.
I'd say making pixmap-skinnable title bars or implementing partial transparencies it way more interesting to your project thatn this.
Better to work and implement on things our players will be able to see and interact with, that teorical performance increases that might not be enough to make a difference.
But ofc, all things I expressed so far are my thoughts, it's your project, do it as you wish.