There may be certain problems on the system of a future Orxonox user, which prevent Orxonox from starting successfully. One of the biggest problem is probably a missing, outdated or wrong placed media directory. Of course this problem reduces if we ship Orxonox as one bundle, but in several packet managers we probably still have to use two packets - one source, one media.
Now how do we tell the user if something went wrong? In the simplest case we just start Orxonox anyway and display the message. But if the media repository is missing, we can't even show a simple CEGUI message. Of course we could display a text error in the console and force the user to change the media path in the orxonox.ini (and probably also delete the corrupted keybindings.ini ^^) but I think we all agree, this sucks. I prefer a simple GUI where the user can enter the path to the media directory (or click it's way through the filemanager) and just hit [ok] and everything works automatically. Additionally a download link to the media repository/package could be displayed if the user didn't loaded it yet.
But how do we draw this GUI?
- With CEGUI. This however requires a minimal set of media files in the trunk to show text and a simple menu. And, probably even more complicated, it requires Orxonox to start without a media repository - of course no full start, but enough to draw the GUI.
- With a menu like the Ogre settings when starting Orxonox the first time. Unfortunately the Ogre menu is one big hack (or better said four big hacks - one for each operating system / window manager) and there's really no chance to modify this GUI or expand it for our needs.
- With tk. Tk is GUI toolkit which is usually shipped together with Tcl. And since we're already using Tcl, it probably wouldn't be a big deal to additionally require Tk. However this would still be an additional library dependency - for just one window (or are there maybe other usages?)
- With a selfmade text-GUI. We could draw some sort of a GUI into the console, like aptitude does (all we need is one input field - I guess there exist some libraries, but of course this means even more dependencies). However this wouldn't be platform independent because windows user don't have a console.