[portej05]

In tonights IRC, the issue of cross-platform FRED came up.
I've had a look through the code for FRED, and some of the code in 'code' that FRED depends on, and there seems to be a massive reliance on FRED being a windows application.
For example, one snippet of code I've seen is (note, only in a Win32 build and also that this seems to be peppered around a bit):

Code: [Select]

#ifdef WIN32
// FRED doesn't need this
if ( !Fred_running && !Is_standalone ) {

and the way FRED attaches the code rendering in the library is by using os_set_window((uint)this->GetSafeHwnd());

How much of a windows application is FRED really, what kind of reliance does FRED have with being on Windows, what is happening with wxFRED, and what is the future of FRED? (please don't take this the wrong way)

[karajorma]

wxFRED is pretty much moribund. I don't think anyone has touched it in years. FRED is a Windows only application because it uses the Microsoft Foundation Classes (MFC) for its GUI. The idea of wxFRED was to move over to another GUI system in order to remove this unnecessary platform dependence.

The only reason it didn't work is that the SCP don't have enough coders with the willpower to actually do it. Once someone made a start on it the others would soon join in. Funnily enough (probably as a result of the same conversation) Wanderer was asking me earlier today if anyone would mind using QT instead of wxWidgets. Well I certainly don't mind.

[portej05]

It's not just that it uses MFC, but I was more interested in how much of an assumption that 'code' made on how FRED was put together in terms of the various bits and pieces.

[Tomo]

QT would be a good choice of GUI handler package - it's quite nice to work with, and plays very well with Open GL.

However, porting any application to a different GUI handler is a pain in the proverbial, so it is not going to happen quickly.

On the other hand, once ported it would mean that a lot more people could work on the FRED code, as they wouldn't need MFC to compile it.

[karajorma]

Personally I'd suggest migrating the standalone GUI first as a test. It's a lot smaller and thus would be a good thing to practice on.

[Goober5000]

Wanderer was asking me earlier today if anyone would mind using QT instead of wxWidgets. Well I certainly don't mind.

I would.   I set things up so that wxWidgets is all set up and ready to go.  Plus I got a whole bunch of tools to work with it.  If I ever get a lot of free time available (like this past Christmas, except ST:R took priority) that's what I plan to work on.

Plus wxWidgets interfaces directly with the OS API, whereas I think QT is a wrapper API.

[portej05]

What tools are you using Goober?

Any cross-platform toolkit will have to wrap the OS API somehow - there's no way around it when they're so different.

[Goober5000]

What I meant was that wxWidgets is more of a "thin abstraction" to the OS GUI.  (Check out the wikipedia pages or here, for example.)

I have the DialogBlocks and ImageBlocks tools, as well as wxWidgets itself.  There is also the wxFRED MSVC project all set up and ready to go within SVN.

Another major advantage of wxFRED vs. a hypothetical qtFRED is that wxFRED doesn't require the user to install any toolkits himself.

[portej05]

From the Qt page:
http://www.qtsoftware.com/products

Qt uses the native graphics APIs of each platform it supports, taking full advantage of system resources and ensuring that applications have native look and feel.

hmm, I dunno - my major GUI programming experience is with MFC, and a dabble in Qt, so I'm probably not the best to talk to about this!

[portej05]

Did you buy DialogBlocks?

[Goober5000]

Yes.

[shiv]

I don't care if you use QT, GTK or anything other.

Eveyrthing I want is just a finishend wxFRED or QTFRED.

If you feel confident enough, you should start work on making FRED usable on GNU/Linux then as Karajorma said:

The only reason it didn't work is that the SCP don't have enough coders with the willpower to actually do it. Once someone made a start on it the others would soon join in.

I'd love to use Linux FRED, because mostly the only reason that keeps me with Windows is FRED

[portej05]

shiv: The point is that FRED has to be completely rewritten in a different framework in order to work under linux/MacOSX.
We need to sort out which framework we're going to use before we commit any code.
Rewriting FRED is a big undertaking.

Goober: Is the current idea just to remake FRED, or could there be some input from the FREDder crowd into a new UI design?
Is the unlicenced/evaluation wxWidgets stuff enough to work with?

[Goober5000]

For now, the idea is to simply remake the existing FRED using the new toolkit -- a straight port.  If people are interested in additional GUI features, there's nothing preventing anyone from making suggestions, but that's true even now in the MFC version.  (Advanced features have been added in the past, such as subcategorization for sexps.)

The main thing to keep in mind for the new FRED is to double-check each feature as it's implemented.  There are a lot of "horrifying lines of code" in FRED, and the more we can eliminate them, the easier FRED will be to work with in the future.  One very important feature that needs adding, for example, is a proper Undo system.

WxWidgets, being open-source/freeware, already comes fully-featured; there is no evaluation version.  There is an evaluation version of DialogBlocks, but it's more than sufficient for FRED until we get a large number of dialogs implemented.

If you have MSVC6, you can get started with wxWidgets right now using the instructions in this thread.  They're a few years out of date, but should still work well enough to get started.  There's also a large amount of groundwork already present in SVN.  I'd be happy to have a chat with you via IRC or IM to get you up and running.

[karajorma]

Does wxWidgets integrate with VC2008? Cause I seem to get mixed information on it depending on where I look.

[shiv]

shiv: The point is that FRED has to be completely rewritten in a different framework in order to work under linux/MacOSX.
We need to sort out which framework we're going to use before we commit any code.
Rewriting FRED is a big undertaking.

I'd love to help you, but I can't do much - I know only basics of C# language.
However you can count on me if you need suggestions or any Linux stuff help
May we talkon IM or IRC or something?
FRED for Linux is very important thing for me and many people would be thankfull to you if you help with making FRED work with Linux/MacOS.

And what about making FRED (even for Windows) rewritten? Installing QT libraries for Windows wouldn't be a big problem I suppose and we'd keep that way compability with every platform.

Anyway I don't know FRED2_Open source code so I don't want to say stupid things about it. So forgive me if I said something wrong.

[karajorma]

The idea of going over to wxWidgets is that it would work for all three platforms. All that would be required would be a recompile on each platform, same as we do now for FS2_Open.

If QT does require an install of some sort in order to work (especially on Windows) then I'm against it. We already have enough PITA issues with OpenAL to go adding another one with QT if we don't need to.

[portej05]

There is an evaluation version of DialogBlocks, but it's more than sufficient for FRED until we get a large number of dialogs implemented.

This is the bit that worries me.

I don't know why you guys don't bundle the OpenAL dependency in the installer package.

[karajorma]

It used to change quite often and we didn't want to overwrite newer versions with old ones.

[portej05]

I also reckon we've got a golden opportunity to redesign the UI, rather than just copy the UI