Celestia Development Roadmap

[chris]

We only need to know from Chris when in the roadmap he would like to have this implemented.

We can start on a Qt front-end for Celestia immediately. It's likely that Christophe is working on it right this minute

--Chris

So 1.5.0 final will ship with a unified GUI based on QT?

No, I think it will take a while before a unified Qt-based GUI is ready. I'm still learning about Qt--in particular, I don't know how different it is from KDE, and thus how much work is required to turn the KDE front end into Qt.

--Chris

[Christophe]

No, I think it will take a while before a unified Qt-based GUI is ready. I'm still learning about Qt--in particular, I don't know how different it is from KDE, and thus how much work is required to turn the KDE front end into Qt.

Qt is the toolkit, KDE provides additional desktop services. For example the current KDE interface uses the kde libs for: configuration storage, single instance control (IPC through DCOP), integration with the rest of KDE (common menu entries, open/save dialogs, bookmarks edition dialog, translations, bug reporting, common CLI options). and artwork (icons).

Redoing all this from scratch using Qt4 only would be quite a bit of work. Now, although KDE4 won't be available on Windows as a desktop, the libs will be available to port single KDE applications to Windows, so it should be possible to 'simply' port the KDE3 interface to KDE4 and have it compile on Windows.

That's what the Amarok guys are doing, apparently with success. And considering the audio and network requirements of Amarok, if they can do it there is no reason it can't be done for Celestia.

[dirkpitt]

Sorry for being out of the loop for so long.
Having used Maya and its powerful Mel-scripted interface previously, I think a cross-platform, conventional UI framework that is scriptable by Lua would be ideal.

I don't feel that a custom UI toolkit is the right choice

This I agree with in general. Duplicating Movie capture, Eclipse Finder, Browser etc for each platform is a waste, but relying on a cross-platform framework would mean losing out on some platform-specific features.

I do not think it would be good to attempt to write something like an add-on manager in Lua with custom OpenGL widget sets; a conventional UI toolkit seems much more appropriate for this.

I agree. Use what is already out there and is tested.

We should probably start a separate topic about how heavily Celestia should rely on Lua (Should the current on-screen UI be replaced completely by a Lua script? Should Lua be the 'glue' between the UI and Celestia, with toolbar buttons and keystrokes triggering Lua scripts?)

I favour the heavy-usage idea. Let scripts control interface layout, as well as act as the commands for buttons. This would not only offer a lot more extensibility, but also faster development and on-the-fly testing.

[Paolo]

No, I think it will take a while before a unified Qt-based GUI is ready. I'm still learning about Qt--in particular, I don't know how different it is from KDE, and thus how much work is required to turn the KDE front end into Qt.

Qt is the toolkit, KDE provides additional desktop services. For example the current KDE interface uses the kde libs for: configuration storage, single instance control (IPC through DCOP), integration with the rest of KDE (common menu entries, open/save dialogs, bookmarks edition dialog, translations, bug reporting, common CLI options). and artwork (icons).

Redoing all this from scratch using Qt4 only would be quite a bit of work. Now, although KDE4 won't be available on Windows as a desktop, the libs will be available to port single KDE applications to Windows, so it should be possible to 'simply' port the KDE3 interface to KDE4 and have it compile on Windows.

That's what the Amarok guys are doing, apparently with success. And considering the audio and network requirements of Amarok, if they can do it there is no reason it can't be done for Celestia.

May I ask you how the porting is proceeding?
I offer myself as beta tester. I suggest to create a QT folder in the src/celestia of CVS

[Christophe]

May I ask you how the porting is proceeding?
I offer myself as beta tester. I suggest to create a QT folder in the src/celestia of CVS

I'm actually porting to KDE4, not Qt4. The first steps have been to compile the development version of KDE4 and I'm now in the process of setting up the CMake build system for Celestia.

CMake has many benefits over autoconf/automake, one of them is that it is cross-platform and produces project files for VisualStudio on Windows. The down side is that it doesn't support packageconfig so the code for detecting some components has to be written manualy (e.g. lua, ogg, theora).

I'll let you know as soon as I have something that compiles.

[RocketMan@JSC]

Glad to see discussion about future upgrades and in particular going to hopefully, one UI. I agree that much work is wasted maintaining all the UI front ends. Wish I had more time to spend working with you guys, every now and then I poke in to see what's going on, but I couldn't resist putting in my thoughts on this.

I've been researching this same type topic for a 6-dof space flight simulator and I can discuss some of the architecture.

One architecture that should be considered is using wxPython as a front end to the Celestia C++ core. This design pattern has been used many times and is mature enough to be used. I've already prototyped this and it literally took hours to bind wxPython to Celestia.

Here's a pic of wxPython rendering Celestia on a AUI (Advanced User Interface) canvas with the Eclipse IDE in the background:


More info on this screenshot: http://www.celestiaproject.net/forum/viewtopic ... t=wxpython

One feature I would really like is to have multiple 3D views available via a tabbed menu like that shown in the pic.

The advantage here is using the cross platform wxWidgets and wxPython GUI frameworks. Python is a simple, full featured language to use and GUI building is made very easy using wxPython.

There are several mature tools to create python bindings to C++, most notably SWIG and Boost.python.

Thus far I've chosen Boost.python with Py++ to generate the bindings. Once you get through the learning curve, the process of creating bindings is pretty much automated. Look at Python-Ogre, which is an OpenGL 3D rendering program--there are even two competing versions--one bound with SWIG, the other Boost.python. SWIG is easier to get started but does not seem to have fully capability like Boost and requires more manual intervention for generating bindings.

WxPython will really make building and developing the UI much easier, and this could lead to more developer participation. I would agree that wxPython would be a little slower than a full C++ UI, but let's keep the number crunching in the C++ (where it should be) and very little difference will be noticed by users.

There is a wxLua package but in the end, I believe python would offer more capability and a wider variety of useful utility packages.

FWIW, we at NASA are staying away from Qt because some part of the library is not to be used for commercial purposes--so there may be some licensing issues if used in a commercal/government environment. I wish I knew more about the specifics of this, if needed I can find out.

In the end, the wxPython/C++ application would be fully capable on Windows, Linux and Macs--all using the same UI source code--that's pretty much what we're going for

Scott

[dirkpitt]

There is a wxLua package but in the end, I believe python would offer more capability and a wider variety of useful utility packages.

Interesting, so it is possible to do gui layout with just python or Lua. Python is probably a hard sell at this point considering how Lua is integrated with Celestia, but perhaps our Lua devs would be better qualified to comment.

[chris]

There is a wxLua package but in the end, I believe python would offer more capability and a wider variety of useful utility packages.

Interesting, so it is possible to do gui layout with just python or Lua. Python is probably a hard sell at this point considering how Lua is integrated with Celestia, but perhaps our Lua devs would be better qualified to comment.

It would be nice to limit the number of languages used in Celestia to just two Anyhow, wxWindows looks worth investigating. Christophe had some concerns about it's maturity on Linux. That was a few years ago though, it's possible that they may have been addressed since then.

--Chris

[RocketMan@JSC]

There is a wxLua package but in the end, I believe python would offer more capability and a wider variety of useful utility packages.

Interesting, so it is possible to do gui layout with just python or Lua. Python is probably a hard sell at this point considering how Lua is integrated with Celestia, but perhaps our Lua devs would be better qualified to comment.

It would be nice to limit the number of languages used in Celestia to just two Anyhow, wxWindows looks worth investigating. Christophe had some concerns about it's maturity on Linux. That was a few years ago though, it's possible that they may have been addressed since then.

--Chris

Yes I can understand about the dependencies and the existing Lua scripts. Alot of good work put into that capability.

I was mainly thinking about extensibility beyond what Celestia can now do now. I'm sure the same can be done with Lua. It just seems to me that Python is a little more mainstream (devs and users) and many more utilities are available for it. I'm just saying, as a whole--take a good look at what Python has to offer. It has the potential to really chew up some of the menial tasks that C++ can do but requires a large amount of code.

IMHO, if the intent is to go to a single gui framework, then one needs to look at what exactly is the target capability for Celestia. It's a very important part of the design since all users will impacted. However this happens, I hope that Celestia can draw in more users and developers. I for one would like to see more spacecraft and trajectory analysis capability--and I applaud the recent upgrades in this area (SPICE, rotations, etc). I would hate to see Celestia die on the vine and bringing in more people and more use cases will prevent that.

Scott

[Pirx]

Hi there, I am enjoying celestia for a long time now and I am watching these forums from time to time, too.

Now I am just a little bit concerned about the KDE4/QT4 efforts Christophe is making. In my opinion, it's far better to keep dependencies low. Of course it's not good to reinvent the wheel again and again, but is KDE4 really the answer? I see the danger of bloat!

Sure, providing several different GUI implementations is even more bloat, but why compare with the current situation?

I am a linux user, no windows installed for years, and even I am refusing to use some popular Linux applications due to their dependencies.

And I am not alone - a lot of linux guys think like that: Shall I really install a huge library (capabale of powering a complex nextgen desktop environment) to just use once in a while one single programm depending on it??

Hope you don't get me wrong. I am sure you will decide right. But I think the purpose of this forum is to mention those thoughts, too.

Regards, Pirx

PS.: Did you ever take a glance at FLTK, the free light Toolkit? Ah, probablly TOO light, I am afraid

[Cham]

Pirx,

I feel the same as you. I don't like much those new ideas floating around about "unifying" the interface. If Celestia is really taking the road I'm thinking about, I'll definitely leave it.

On my OS X system, I much prefer to use OS X apps only, without any dependencies on anything else. I generaly dislike MUCH all apps which doesn't feel OS X. And I certainly WONT install any special libraries just to run Celestia.

[chris]

Pirx,

I feel the same as you. I don't like much those new ideas floating around about "unifying" the interface. If Celestia is really taking the road I'm thinking about, I'll definitely leave it.

On my OS X system, I much prefer to use OS X apps only, without any dependencies on anything else. I generaly dislike MUCH all apps which doesn't feel OS X. And I certainly WONT install any special libraries just to run Celestia.

You're being much too negative about a unified UI. The idea is that the UI will look like a native OS X interface on a Mac, a native Windows interface on WinXP, etc. These toolkits have developed quite a bit since Celestia 1.0, and I think that they're really worth considering. And extra libraries will be required, but this fact should be invisible to you--you're already using the Lua library, and that doesn't cause any problems for you, does it?

There's a lot of stuff that we could implement with a cross-platform toolkit, including networking and threading, in addition to a much richer UI. For Celestia's small dev team, it's simply too much work to reimplement everything for each supported platform. That's a big reason why the UI has been so slow to develop. Every time we want to add a new UI feature, it has to be coded for four different platforms. It's a big problem for the Windows UI--I'm the only one maintaining it right now, but my hands are almost always full with rendering engine development.

--Chris

[ElChristou]

I think we should go to a unified UI and let's imagine the worst, no more native interface (which won't be the case aparently)... and what? let's design our own interface, far better than what Apple is doing!!

[Cham]

you're already using the Lua library, and that doesn't cause any problems for you, does it?

In the case of Lua, I didn't installed anything. I don't use Vincent's features (buttons, palettes, etc). I just don't like that idea either. Floating buttons and palettes ? What for !? My students are already using a beautifull book full of nice colorfull pictures and diagrams, with text information easier to read than on a computer screen.

In the futur, if I'll have to install any special libraries to run Celestia, I will MOST PROBABLY leave Celestia and its community. I may very well teach my astronomy courses with another software or just use an old version of Celestia.

In any cases, I will no longer test Celestia and makes any bug reports or create any new addon if Celestia takes that road. That's the way I feel. Sorry.

[tech2000]

I think we should go to a unified UI and let's imagine the worst, no more native interface (which won't be the case aparently)... and what? let's design our own interface, far better than what Apple is doing!!

You're right, here are enough artists to outperform appels designers..

Bye, Anders

[ElChristou]

I think we should go to a unified UI and let's imagine the worst, no more native interface (which won't be the case aparently)... and what? let's design our own interface, far better than what Apple is doing!!

You're right, here are enough artists to outperform appels designers..

Bye, Anders

Won't be so easy... but...

[ElChristou]

...In the futur, if I'll have to install any special libraries to run Celestia, I will MOST PROBABLY leave Celestia and its community. I may very well teach my astronomy courses with another software or just use an old version of Celestia.

In any cases, I will no longer test Celestia and makes any bug reports or create any new addon if Celestia takes that road. That's the way I feel. Sorry.

Don't be so pessimistic Cham, indeed lots of cross platform soft don't have a nice UI, but I think it's just because there is not the manpower of a big compagnie to polish the details behind such small teams; also don't forget in general those soft are almost 100% done by coders, whose in general are not the best designers. As Chris said, we probably won't have to redesign an entire UI using the native stuff, but even if we cannot it would be a great venture to do the work...

[Pirx]

So, to summarize it: It seems much more efficient to focus on one toolkit. Right.

But this doesn't answer the question whether KDE4libs is the right choice or not.

For sure, celestia has and will have various dependencies - thats normal and perfectly right. But in my experiences there should be a very high threshold before you are going to _depend_ on a additional huge library, especially on such a ubiquitous jaggernaut like KDE4.
Even if this isn't "breaking a butterfly on a wheel"; Cham is right with calling it a "new road celestia is going".

As I am not a contributor of celestia, I can't evaluate that from a devs PoV, but I am absolutely positive that a lot of people from outside the project will feel about it like I do.

This is not comparable with "depending on lua", "depending on a media lib", its a major change of celestias course.

Though I am afraid others might abandon interest on celestia - I won't do that. I just hope you have considered the cost-value ratio of this shift well.

Thank you for your attention!

Regards, Pirx

[dirkpitt]

Don't be so pessimistic Cham, indeed lots of cross platform soft don't have a nice UI, but I think it's just because there is not the manpower of a big campaign to polish the details behind such small teams

Cross platform UI's often tend to look weird, because the UI standards are different for different platforms. Users expect one thing on Windows, but a different thing on the Mac, etc.

The use of platform-native widgets (buttons, etc) tend to make things worse, because the sizes and shapes of buttons are different for each platform. Windows for example has rectangular buttons, but using the same button size on Macs will often cause clipping because buttons on the Mac have rounded corners.

This is one of the reasons why I think a cross-platform UI should be easily customizable by the user, e.g., by editing a textual Lua script. If editing a text file is too hard, then a pre-customized layout could be made available via download.

[Christophe]

I'd like you all to remember that Celestia is an OpenSource application. As such, even if we, as the core dev team, take the road of a unified GUI relying on a lib like Qt4, KDE4 or wxWidget, you're still free to maintain a platform dependant GUI as well.

Qt4 is now split into various libs, so even if we do use it for threading and network access; you will only have to link libQtCore and libQtNetwork and not libQtGui. Requiring Celestia to not depend on any external lib is really ridiculous, does that mean you refuse to use Spice aswell? or is it okay just because it's statically linked in?

Rather than taking such a negative approach, it'd be more constructive if some of you actually took the time to test and evaluate the various existing solutions.