Aw, crud. I wasn't getting any of the response notification eMails.
t00fri wrote:1) The Set Time bug is worse: local time zones are completely missing
2) The window size is not restored.
Yes, both of these were known issues, because they are areas that required removing Linux-specific code. I've checked in some changes. Window saving works better now. Time is still an issue. It will do local time, but will not handle DST correctly at this time.
t00fri wrote:And not to forget...the ViewOptions dialog is only shown to work with gtk-2.8.8rc2! No statements about older versions (with witch your celestia binary does not work) may be inferred...
I've typed this before, I'll type it again. I did my testing on Debian Sarge, with GTK+ 2.6.4. My autopackage will also run on every distribution out there (I've had it tested). You can get that here:
http://pat.suwalski.net/celestia/misc/c ... 86.packageIt is my hope that when 1.4.0-proper comes out, we can put this in the SF.net downloads and avoid the usual packaging mess we have. There is nothing wrong with doing individual distribution packages per se, but the autopackage is much more standardised. The downside is that it does require the download of support code. "Pick your poison."
steffens wrote:First of all - many thanks for taking up the lot of work on the GTK frontend. It is very much appreciated! As I am using Gnome as my default desktop, I was always looking forward to a Celestia frontend that nicely fits.
Ah, a fellow GNOME user. Thanks for the kind words. If you want to try something new with the GNOME front-end, it supports cel:// URLs for web browsing. More on other features later.
steffens wrote:Sadly, I do experience the same problem as toofri: missing text labels in the "View Options" dialog. What can I do to find the cause of that?
I'm curious what distro this is? Is it under KDE? Are you also using the qt-gtk theme engine? Does a different theme change anything? If it's SuSe it could be a bug in SuSe Gtk 2.6 packages.
steffens wrote:As long as we are not sure what precisely caused the problem, one should go on "digging". In any case it's independent of the gnome libs, since celestia-gtk showed the same problem.
I would love to solve it. However: (1) I cannot reproduce it under any distro. (2) It's a bug at the toolkit level. Which SuSe was this exactly? I'll grab a copy at work and go through the very painful installation process and see if I get it there. It runs fine on SuSe 10.
steffens wrote:What exactly is the difference between the GTK version and the gnome version? I compiled the GTK version as a quick test, because I had to install more -dev packages for the gnome one.
So, at the moment the differences between the GTK+ and GNOME interfaces are minimal, as a lot of the GNOME-specific stuff I was using in the 1.3.x series got pushed up to the GTK+ 2.6.
The major difference right now is that Celestia/GNOME uses GConf for its configuration settings. Celestia/GTK uses an ini-style file in the home directory. Using GConf allows for GNOME integration, such as for the web browser. At this point, the GTK version is otherwise just as polished at the GNOME version.
The real advantage to the GNOME front-end comes in the future. I'm already planning a video-capture system like what the Windows interface has, using GStreamer. GStreamer is a dependency for GNOME, so it's already there. It doesn't make sense to have the GTK interface depend on it. Additionally, the Help system could be quite literally "recompiled" (is that what we call it for docbook?) from KDE to have nicely integrated help, with minimal effort... things like that.
On the other hand, the GTK front-end is to be kept as bare-bones as possible. It should be the most basic interface that can access all of the direct features of the CelestiaCore. It should have no outside dependencies apart from GTK and gtkglext (for GL). In fact, my autopackage has the latter compiled in statically (it's only 15K), so the only dependency above plain X is GTK. That autopackage is really a cool thing that I'm going to encourage people to use.
The way I rewrote the code is perfectly set up for maintaining these streams without cluttering the code. For example, I currently have a settings-gconf.cpp and settings-file.cpp. This limits the ifdefs in the main code to little one-line snippets, because if you look at their .h files, you'll see have a consistent API. Adding a settings-win32.cpp for the Windows Registry will be a one-evening task. But that will be after 1.4.0.
steffens wrote:Fixing the problems for "old" distributions (or stable ones, as Debian people would call it) would definitely be very nice.
While I am aware of this bug about missing text, I can't see anything like it in the GTK bugzilla, open or closed, for the last 2 years. And it definitely runs on Debian stable. That's what the autopackage was built on, from a clean install.
