When winecfg was originally proposed I wanted to do it in GTK, and whinged loudly when Alexandre said it had to be done using Win32 to keep dependencies small. I guess his reasoning hasn't changed, so, for GUIs you'd have to do it using Win32 and C :(
Of course if you aren't bothered about it becoming official you can do it however you like ...
If this http://wiki.winehq.org/ThemingSupport is to become a part of wine (RE: GTK support for themes), I don't see what the problem with using GTK is. GTK is available on all distributions that I know of, and definitely all popular distributions. winetools already uses the legacy GTK+-1.2, also I see that there are advantages of having a GUI for installing/uninstalling applications separate from wine and win32 provides certain advantages i.e. providing process management, i.e. killing wineservers when they hang without reason. The main advantage I see is that the code is far simpler than writing it in C, of course, I'm not particularly bothered whether my application gets included in wine distributions, as long as the AppDB can provide support for the features I want, if the AppDB integration features are dealt with with respect to my app, then it is possible that someone else will develop a win32 C application which uses the same features.
On the subject of dependencies, if the application is not required by the wine core then surely dependencies are irrelevant, and the shortest development path (python gtk, glade imho) should be considered as it means the application will be available much faster than developing it in C which could take far longer to develop.
Another advantage of python is that you can also run windows applications in python (which of course would require the windows python binary) but if someone wanted to create a Qt or win32 UI for wine doors then I'd happily support them in this endeavor.
Maybe now we can think more about in general terms what is required for this kind of user interface, I would like my application to become the benchmark for this type of tool I have many features already working and lots of ideas of my own, more community involvement would be appreciated but at the speed I am writing this I imagine it could be ready for winetools replacement very soon.
Your remarks on perl and bash usage seem to me a step backward, perl is terrible at a hell of a lot of things (I should know, using perl for many many years and still stabbing myself in the hand when working with it at times to relieve the pain in my brain), bash is currently used for winetools and is a nonsense mess of code because quite simply bash wasn't supposed to do things like that. I employ bash where necessary and will only use it where appropriate, I believe that over complication of what is essentially a very simple concept by going down a route of bad languages and restrictive dependencies inhibits development by making it difficult for developers to dive in and start work on something.
If I say it _must_ be written in C win32, perl or bash then immediately developers will consider the issues, ok perl could do a lot of it easily but there are some problems in other areas, bash would be a large amount of work and win32 C would mean lots and lots of code auditing, re-factoring and bug fixing, probably resulting in a 5 year development process to get the application to a point where it is in regular use. These issues may serve to deter a developer from taking on the project with a view to "I'm not getting my hands on that train wreck".
There is also the subject of desktop integration, I use gnome, lots of other people do, GTK fits together nicely and would prevent deviation from the desktop model, if wine is to use GTK all the better, but this in itself means that the GTK requirement would exist and various other requirements around this wouldn't be a great issue. With the current complexity of linux desktops I believe that restricting the language and dependencies is silly and uncalled for. Maybe Alexandre's views may have changed this far on?
K,