I just wrote a real long description of an approach and I hit some button and everything vanished! I'm now mad! So I'll summarize:
I wouldn't use GDK with DBC because each is complete in itself and I don't see the advantage of not just using GDK. I would use straight C (because I'm a dinosaur) but you could easily use straight C++.
If you want to use windows gui, you can subclass the "DBG" class window (that's the name of the class of window that DBC creates) to use things like menus and such.
I you want a custom GUI, you'll have to create it no matter what you do. I've done work with writing drawing commands directly to DBC's back buffer through a DLL. It's very fast. I've even tried drawing custom 3D (just outlines and such) to the back buffer and it works fast as well.
The challenges:
1. Reading from the back buffer is too slow
2. Most memory handling has to be through memblocks.
No. 2 is a challenge because caling memblock commands in DBC isn't the fastest thing in the world and you also have to be clever how you set them up.
As far as data types: vectors, quaternions, matrices, etc. you generally create the types you want in your DLL. You then allocate sufficient memory in a memblock of the data size for N number of items.
If you look at the DBC challenges, the last challenge I entered with a smooth moving snake over a waving matrix, uses vector data types to communicate to the d3drm DLL.
You aren't limited to only using memblocks for memory management, however. I've created a collision DLL that manages all of the objects inside the DLL. ColDet does the same thing, and so does sparky's. ColDet was written in C++ and manages instances of collision objects classes. This is hidden from DBC through the DBC functions and the "in between" dll I made to talk to the coldet library.
Caleb on the DBC forums created a DLL in C++ for dynamic memory management. You should look aroudn for that.
Quote: "...On top of that, you get access to classes and subclasses. This is what I was thinking would allow you to create a GUI toolkit. Not necessarily using a native Windows GUI, but more of a custom GUI system for use within programs (calling up windows, message boxes, button support, etc). As it stands, it can be done, but it's incredibly tedious to do. This would allow for a more general solution, rather than always making specific cases.
"
No matter how you look at it, the GUI would still have to be created. It's a tedious task. But once it's in place, it is done. But it still doesn't eleviate the problem of a thousand new commands to use in the form of a library to use the GUI with a program. You still have to position dialog boxes, create menus, setup windows,etc. Even with windows, managing the GUI is not simple.
If you created the DLL, you might also want a GUI designer that spits out the function code for use in the program.
Enjoy your day.