Currently you are maintaining separate code for the GUI (menus/dialogs/etc) on each platform - Windows, KDE and Mac OS X.
I would suggest you are creating a lot of extra work for yourselves - work that could easily be avoided.
Are you aware that wxWindows supports and integrates OpenGL, and that it provides all the necessary facilities to shield the programmer from the platform-specifics of a GUI?
wxWindows also provides rich facilities for platform independent non-GUI items such as threads and sockets, and other less-likely things like a joystick interface. It also incorporates libpng, libjpg, etc.
There is also wxLua, a set of lua bindings for wxWindows, so if you wanted to allow more user interactivity in the scripting facility, you could without much effort.
I would seriously suggest converting the GUI over (I wouldn't appear to be a big job, and would save a lot of extra work and heartache in the long term). It would also allow programming effort to focus more on the application, and not worry so much about the platform.
Comments...?
Cross-platform GUI: a rod for one's own back
I asked the same question about a week ago, over here (http://ennui.shatters.net/forum/viewtopic.php?t=3627) and received a reply from Selden.
It is a tough question.
Not sure exactly how Chris, Christophe, and HankR feel about it, since they are the main developers for Win, Linux and Mac. Would be interesting to hear directly from them and from users on each of these platforms.
-Don G.
It is a tough question.
Not sure exactly how Chris, Christophe, and HankR feel about it, since they are the main developers for Win, Linux and Mac. Would be interesting to hear directly from them and from users on each of these platforms.
-Don G.
Comment from this and previous post
One either designs a program to look the same on all platforms or one designs a program to match the GUI standards on each of them.
The first path means you can continue use the program easily even when you have to move from one type of computer to another. The second makes the program easy to use by a person who's always worked on a particular type of computer platform but who is new to this particular program.
Celestia is following the second route, although it's a lot more work. That way people familiar with a particular type of user interface (whether Windows, MacOS or Linux/KDE) can start using it right away without having to puzzle out all the things that are different from what they're used to.
wxWindows gives you the platform's native look & feel, so it's exactly what you're looking for. Especially so on Mac, where the differences between that and Windows are much greater that that between Windows and modern Unix GUIs. On Mac, it will also do you a version for Mac Classic (and Carbon), so you can have it run on older Mac OS's.
I was asking since as Celestia gets bigger and bigger, it's going to take much more time and several "OS and UI specific" people to maintain specific dis-connected parts of it -- instead of having just plain old "C++ programmers" being able to maintain any part of it.
Precisely so, and using/changing to wxWindows would be a lot easier than you expect.
Firstly, wxWindows is very similar to Microsoft's MFC (as comes with Visual C++). Given that more programmers are familiar with MFC than any other GUI, this is a major plus point.
The conversion route is to take the Windows version, and convert the Windows API dependent sections to wxWindows. Then compile for the other platforms with very little modification.
wxWindows also allows for a mixture of native and cross-platform code (e.g. it gives you access to HWND and other platform parameters), so you can do the migration gradually if you wanted to.
-
- Developer
- Posts: 944
- Joined: 18.07.2002
- With us: 22 years 4 months
- Location: Lyon (France)
I already know of wxWindows. I'm not really fond of it for several reason.
One of them is that it is very similar to Microsoft's MFC, which is IMHO a good example of bad API design. MFC are not that bad considering that they are over 10 years old, but by today's standard they look prehistoric.
Another drawback is that under Linux only one toolkit is supported, and it is GTK which doesn't support things like font anti-aliasing, GTK apps look really dated today and out of place in KDE or Gnome.
Beside the toolkit, they are other things that make an application a part of a desktop environment, things like standard Open/Save/Configuration windows, standard shortcuts and bookmarks management, session management... none of these would be easy to get using wxWindows.
But wxWindows could still be a good way to integrate Windows and Mac development, and may be one day Linux too once GTK2 and/or Qt are supported as backends.
One of them is that it is very similar to Microsoft's MFC, which is IMHO a good example of bad API design. MFC are not that bad considering that they are over 10 years old, but by today's standard they look prehistoric.
Another drawback is that under Linux only one toolkit is supported, and it is GTK which doesn't support things like font anti-aliasing, GTK apps look really dated today and out of place in KDE or Gnome.
Beside the toolkit, they are other things that make an application a part of a desktop environment, things like standard Open/Save/Configuration windows, standard shortcuts and bookmarks management, session management... none of these would be easy to get using wxWindows.
But wxWindows could still be a good way to integrate Windows and Mac development, and may be one day Linux too once GTK2 and/or Qt are supported as backends.
Christophe
One of them is that it is very similar to Microsoft's MFC, which is IMHO a good example of bad API design. MFC are not that bad considering that they are over 10 years old, but by today's standard they look prehistoric.
I would rate ease of maintenance and global familiarity over the aethetics of API design. wxWindows goes beyond MFC, and tackles many things a lot better than MFC.
Another drawback is that under Linux only one toolkit is supported, and it is GTK which doesn't support things like font anti-aliasing, GTK apps look really dated today and out of place in KDE or Gnome.
Modern GTK does support font aliasing (not that this is particularly relevant to Celestia as it uses its own under OpenGL). Gnome uses GTK, so you can't say that GTK looks dated compared to Gnome as they are one and the same. Also GTK isn't the only Linux GUI supported.
Beside the toolkit, they are other things that make an application a part of a desktop environment, things like standard Open/Save/Configuration windows, standard shortcuts and bookmarks management, session management... none of these would be easy to get using wxWindows.
Simply not true. They all come as standard with wxWindows.
But wxWindows could still be a good way to integrate Windows and Mac development, and may be one day Linux too once GTK2 and/or Qt are supported as backends.
GTK2 is there in Beta form. Qt is unlikely to come because of licensing issues.
-
- Developer
- Posts: 944
- Joined: 18.07.2002
- With us: 22 years 4 months
- Location: Lyon (France)
nhathaway wrote:I would rate ease of maintenance and global familiarity over the aethetics of API design.
That assumes prior familiarity with the MFC, that is not everyone's case, and not mine in particular.
nhathaway wrote:Modern GTK does support font aliasing (not that this is particularly relevant to Celestia as it uses its own under OpenGL). Gnome uses GTK, so you can't say that GTK looks dated compared to Gnome as they are one and the same.
Current Gnome uses GTK2, GTK1 apps do look dated in Gnome2 and KDE3.
nhathaway wrote:Also GTK isn't the only Linux GUI supported.
You're not referring to Motif now, are you ;-)
nhathaway wrote:Simply not true. They all come as standard with wxWindows.
Do they? I suppose the wxGTK for example implements its own Open/Save dialog and does not make use of Gnome's, am I mistaken?
nhathaway wrote:GTK2 is there in Beta form.
That's what I thought but I couldn't find it, any link?
nhathaway wrote:Qt is unlikely to come because of licensing issues.
Unix Qt is GPL, wxWindows is apparently GPL compatible so what is the issue?
Christophe