I've added the DialogManager into the old SPDesktop. This means that the current codebase can now use the new dialogs via DialogManager. It also means that the way is now open for anyone that wishes to create new gtkmm dialogs using the new dialog code.
I have hooked in one dialog - Messages (aka ishmal's Debug Dialog). I chose this because it's a finished dialog, and because I figure it's not as critical as some of the drawing dialogs, in case it misbehaves.
If you wish to create a new dialog, please feel free to use the Messages dialog as an example.
To add a new dialog, the process is straightforward:
1. Create a .cpp and .h for your dialog in src/ui/dialog/. The dialog must derive from Dialog (see dialog.*).
2. Add your class to DialogManager. You do this by adding an #include to dialog-manager.cpp, add a member pointer to the DialogManager class in dialog-manager.h, and a get*Dialog() routine (you can just cut and paste from one of the other dialogs).
3. Add a menu item and shortcut key for your dialog. See verbs.cpp and interface.cpp.
I think you'll find that creating dialogs with the new system can be done in about half the code as before, and maintenance is greatly increased since the common boilerplate code is factored out into base classes. Also, the classes are simpler in that they have fewer pointers, and don't need to handle their own instantiation; DialogManager takes care of this. Fewer pointers and less need for memory management implies fewer opportunities for bugs to creep in.
Also, since DialogManager is used for accessing dialogs, there is no need to include the dialog headers in other parts of the code; theoretically this should cut down on include header nesting and make compilation work a bit faster.
Some caveats: The preferences loading/saving code isn't implemented. This means that dialogs won't "remember" their settings between program runs. However, there is code to track this info in there, so should be straightforward to hook up if anyone wishes. As well, some of the code for transient behavior is there, but not all, so transient behavior is probably not right. Feel free to fix; it's all implemented in the Dialog base class so only has to be fixed in one place, and then all dialogs will behave correctly.
Bryce