It would be nice if Acme were written in C++ and could be included as an optional 4th program built in the Armagetronad module. Not a big deal, and there's plenty of argument that can be had on both sides of the fence.
So this leads me to using Qt for our GUI in-game. Before getting into that, I thought it would be worthwhile to make a list of widgets we'll need, widgets we might like, and so forth.
Ingame widgets:
* we already have menus that overlay the game itself. I'm inclined to keep them that way, i.e. they shouldn't become new windows but should instead remain in armagetron's windows.
Out-of-game widgets:
* Application preferences
* Moviepack selector
* Generic file selector (for things like constructing a playlist, picking individual files for various purposes such as maps, etc)
* Sound layout selector (for lack of a better word)
* Other skin-type layouts, cockpit, gui theme, etc. One for each. Maybe one that encapsulates all
* Player preferences
* Player profile selector
* Plyer profile editor
* Cycle color picker
* Cycle model picker
* Cycle texture picker
* A neat little widget that shows visually what your cycle looks like as you go
* Instant chat input
* Player keybinds
* Server browser
* Server bookmarks (preferably using another server browser widget to ping servers marked)
* Game settings (cycle physics, game rules, etc)
It doesn't look to me like there's any great need to integrate with desktops inside the gui itself. Basically I think we've already talked about most of the desktop integration we're wanting, more might present itself later.
Most of these widgets fall into the Custom category. So most/all gui toolkits we use will still require us to write these widgets ourselves, using their framework. Most of them also, coincidentally, are related enough to generic widgets that all gui toolkits support that we can significantly decrease development time and work by inheriting from the toolkit and customizing from there.
So, Qt supports it's own themes that can be configured per application. If we used Qt, we already get GUI themes. We optionally get to let the user pick "Desktop Environment theme" and it'll use their KDE theme if available. I think that will work in Windows and Mac OS X as well, but don't know for sure. We get translation, and we get a few other goodies. Having worked with the API, at least the bloated one that is Qt3, I can say it's pretty sleek. It's so object-oriented and so totally C++ that I wonder why Luke likes it so much.
Qt Designer really does speed up development without sacrificing real programming, which was always my hangup on it. Compared to Delphi, where the point and click programming pretty much pushed you into really bad design.I don't know if Qt is right for us, to be honest. There are a number of issues that come to mind, such as "where is the game loop?", and "Can we override Qt widgets and then stick them in a full screen OpenGL view?" I presume that stuff is handled, Qt is supposed to be good for games, although not necessarily great.
I'd like Acme to have the same dependencies as the core game, and Luke drove yet another nail into its coffin when he reported 11fps. The same work that Acme needs to get that fps up to where the thing is useable is also required in any custom widget set we write. So there's a lesson in there in custom widget sets, a lesson that once learned took me into fooling with Qt.
OTOH, I think we've always dismissed Qt without giving it any solid consideration as a GUI set. Seems like most of us Linux boys around here are KDE users anyway, so it's not like we don't know what Qt looks and feels like. We do, in fact.
