I have the latest svn. I waited to begin in earnest till after your merge. I also will wait for multiuser and probably the next release before thinking about a real branch / merge for a Qt GUI.
Right now I'm working on just getting the widgets right, and this toolbar is a bit of an issue. There's little point in a Qt GUI if it looks worse than the GTK one with the Qt-GTK theme engine applied (nearly every person running KDE has the GTK libraries anyway) as right now both GUIs are functionally identical.
I'm not sure how GTK development works, but much of Qt is using Qt Designer. Basically making the GUI .ui files, actions, and signals and slots. The GUI above is a preview from the designer (sorry if it seemed that I was further along), so right now while the GUI is somewhat complete, compiles and GUI things like accelerators and hotkeys work, no real emulation functions are registered. Actually plugging the GUI into the emulator is the easy part.
I eventually plan on a gui_qt dir to parallel your gui_gtk one, and a flag to pick which GUI to build.
My biggest question is how
should we handle the plugin GUIs. Our plugin_exec_x() way of calling plugin registered functions leaves a lot to be desired. Not only do most plugins not have an About or Test, so instead of a default "Not yet implemented box." we get nothing, but it means there is only one GUI for the plugin. Right now if I was to make my Qt GUI, Rice and Glide would still have GTK configs, and Blight's is SDL. This is not ideal. A more extensible plugin API is needed. Ideally plugins should also not depend on GTK / Qt / SDL #defines either, meaning one could use binary plugins with either a GUI or non-GUI build. Sadly this is some major work.