Well, I just installed 1.5.1 since 1.4 was on a different partition on this OS X box and I could not run it off of that partition (probably because the CelestiaResources (as we call it here in Mac-Land) was not in the correct path anymore).
So, first of all, let me say I 100% agree with Qt. I have been using Qt 3.x for years for Windows development and I can tell you there is no way you'd find this GUI any different from any other Windows application. Indeed, with Qt, you can build a number of different UI Look-and-feels, including KDE (of course), Mac OS X and even IIRC OS 9. Thus, I could even make my WIndows application look like an OS X app. But, the point is, Qt's multi-platform support is very well integrated with supporting a Native look-and-feel and gets my vote for the unified GUI.
Now, as far as Cham's reticence to install any package that requires 'Additional Libraries', I suggest we simply provide Celestia in 2 formats for each platform: Dynamically linked with Qt and Statically Linked with Qt. The Statically linked version would be monolithic and not require any additional libraries. Obviously, the download page should not that the Dynamically linked version is preferred if Qt is already installed or might be installed some time in the future, but if you simply MUST have a stand-alone, then the statically linked version is just that.
The nice thing about this approach is that it becomes a link-time issue, since we can have pre-built Qt dynamically built and statically built libraries. In terms of building, I'm not sure if the Qt license allows us to include the static Qt library in the source package, but this would also solve the potential issue when someone wants to install from source without installing any additional libraries. Personally, I prefer the dynamic linking because of the potential for duplicated libraries installed, but so be. In the end, if someone wants a stand-alone, I say we simply give that person a statically linked version of Celestia. And in truth, I agree on a Mac OS X system, I really don't like installing extra libraries for applications. I'd rather there be redundant libraries in my .app file since if everything is contained in the .app file, I can easily toss the whole thing in the trash when I need to get rid of it and don't need to run some obscure uninstaller. Thus, static linking would suit me well on a Mac.
Now, I haven't personally dealt with KDElib and the APIs it exports above and beyond Qt but why do we need KDElib vs. Qt again? In my experience, Qt is pretty robust with respect to GUI development and in fact we choose Qt BECAUSE of it's ability to generate cross-platform native look-and-feel GUIs.
Also, as far as video playback, may I just say that personally, I
want something that will play on my Apple TV, and even Matroska MKV files can't do that without a complete codec decode-recode. Mind you, Apple is mighty proprietary with their specific tweaks of the H.264 spec and the features they don't allow, but it would be nice if I could just drag my exports into iTunes and then watch them on my telly. If only I could run VLC on my Apple TV...
Oh, and BTW, 2012 is when the Mayan calendar resets, so it's a big joke that that is the end of the world -- IMHO, the dawning of the Age of Aquarius as we exit the Age of Pisces in our 26,000 year precession around our shifting Equinox is still the bigger news, though I suppose for folks 2000 years ago leaving the Age of Aries for Pisces it was bigger news.
Language could be implemented in at least 2 ways in Celestia: 1, Qt's Linguist will help generate a language database that can be used to generate the correct language for a given user. Otherwise, there is the ISO C++ std::message library which can be tied to a locale and is meant to perform the basic same purpose of a language library. There are of course other ways, and I know Celestia has partial support for dynamic languages, but as has been mentioned and being able to choose a language that contradicts the default system settings would be useful IMHO. And, like in ISO C++ I should hope these languages would be stored in the ISO canonical fashion as la_NA where la is the language code and NA is the national localization code, such as US or BRazilian.
Personally, I also like the idea of Python integration but I don't think wxPython is the way to go -- as I said, I prefer Qt -- but rather have Python as a scripting language back-end. Python scripts aren't that hard to write or learn and it has the added benefit of being one of the more legible scripting languages out there.
Then, I would like to touch the topic of Terrain generation. It seems to me we should NOT try and create accurate terrain models for the simple reason that, as has already been stated by scaddenp, the amount of data required -- at least until we start talking about Petabyte hard disks. However, a good Open-Source Fractal library may be a cheap and easy way achieve 'realistic' landscapes without having to go into the absolute detail of landscapes. Then, maybe a 'roughness' parameter could be provided for each landscape over a wide region of terrain that would be used as a parameter for the Fractal engine that would control how high the mountains in the specific region were. The Himalayas could have a very high roughness and the great western plains of North America could have 0 roughness. In any case, my vote would be for the distant time frame, e.g. 2.x+.
Oh, and I'll cast a vote for the binary star system POV problem. If I go
to Alpha Centauri, I would generally expect to be sent to a point where my Field of View at 1.00 would allow me to view all 3 stars at once.
Finally, I have
to bring up my topic from what, 2004 or something, namely the ability to observe relativistic effects when traveling fast as an option. Namely, allow near infinite speed from the POV of our zero-mass camera but do things like pinch the window and the FOV as we accelerate to simulate the Lorenz contractions. Then, add the ability to frequency-shift the view toward the red and blue for speeds that would not shift the view beyond the visible spectrum. Of course, it would be interesting if radio sources suddenly become visible as we reached sufficient speed, but let's not get carried away. Though, adding the ability to view stars and other astronomical bodies in Gamma, X-/Röntgen-Ray, Ultra-Violet, Infra-Red, Microwave and Radio Wave frequencies [like Geordi from Star Trek: The Next Generation] would be neat
. But I digress. Anyway, the other thing I think would be neat would be to manipulate the clock as we approached infinite speed to demonstrate time dilation from the POV of our zero-mass camera. That is to say, we could never travel faster than light with respect to an Earth observer, but it would SEEM like we were because our time would be dilated so our perceived velocity would be faster than light. I hope that makes sense. Also, I think we should allow times in access of 20 Gyr, since it looks like the Universe will be around for a LOT longer than that, and an inter-Galactic view may be interesting to simulate on those timescales as stars slowly burn out and get consumed by bigger and bigger black holes and then those black holes eventually evaporate. I know, that is currently beyond Celestia to animate galactic motion, but allowing the much larger timescale would allow for such features to be added eventually in say an add-on. Mainly, I just love seeing relativistic speeds simulated and hope that can one day be added to Celestia as it would also give a proper realism for people considering interstellar travel.
Well, those be my thoughts for things. I may check out the latest source and take a crack at some of these features myself as I still love Celestia!