Generally, all dialogs found in the Two-Layered GUI Toolkit feature a settings class that stores all the information about the dialog and is independent of the GUI toolkit, as well as a binding to an actual GUI toolkit that is used to display the dialog.
Think of a backend that may be represented by different front-ends. Chances are you don't want to include types from specific GUI toolkits in the public interface. After all, that would require every frontend to know that particular GUI toolkit. Instead, you define descriptive objects, which are then used to create GUI representations using the respectively used GUI toolkit in each frontend.
The Two-Layered GUI Toolkit takes some of this work from you - it provides ready-to-use descriptive objects for the most common dialog types, as well as bindings for some GUI toolkits to automatically convert those definitions into actual GUI representations.
There is no problem with that, as the Two-Layered GUI Toolkit doesn't force you to use both layers. All the dialogs can also be used the traditional way by directly calling the methods of any of the bindings and defining the dialogs argument by argument. This is not equivalent to using the built-in dialogs of your GUI toolkit, as you can still benefit from the additional features of the Two-Layered GUI toolkit this way.