[Tomo]

Has anyone here actually done any wxWidgets doodling or code experimenting?

To be honest, I'm looking at Qt much more closely now - it's the framework we use at work, so I can justify playing with it on company time.
The Qt Creator IDE looks to be pretty good, and is both cross platform and free.
- Yes there are dependencies, but there must be a good way to handle that.

I've done a bit of poking into building a straight events editor, and that looks to be reasonable including an undo stack.
I'm still missing the file format specification though - and that's something I can't do alone.
- I'm now making a start in FS2 Mission File Format in the Wiki.

portej is absolutely right about using a different internal representation for editing.
- Being able to save that internal representation isn't necessary, but could be useful. For example, one could save the workspace layout, the undo stack etc.

Anyway, back on topic:
Undo pretty much requires that you build the editing program around the Undo stack - bolting one in afterwards is almost impossible. (You'll almost certainly break something)

I'm considering using the FS2 text files as the internal representation, with each individual editor in the new package pulling out the bits it needs, playing with them, and then putting them back.

I'm looking at using the built-in Qt Undo framework.
- The only question is how many descendents of QtCommand are required.

I'm guessing that we probably only really need EventTree and Text.
- The EventTree change handles the essentially tree-structure of Event.
Text is obvious, it just neds to keep track of edits to the raw lines of text, properly grouped together into 'related' changes.

[The E]

I'm still missing the file format specification though - and that's something I can't do alone.
- I'm now making a start in FS2 Mission File Format in the Wiki.

Well, I expanded that page a bit. Still needs more documenting and there are probably a few things I've missed.

[Goober5000]

To be honest, I'm looking at Qt much more closely now - it's the framework we use at work, so I can justify playing with it on company time.
The Qt Creator IDE looks to be pretty good, and is both cross platform and free.

Well, doodling is good, but we're not planning on using Qt because a) there's already a decent start at wxFRED and a lot of SCP documentation on wxWidgets; b) wxWidgets is a transparent dependency.

- Yes there are dependencies, but there must be a good way to handle that.

Well, you anticipated one of my objections; that's a positive sign.

One very important reason we're using wxWidgets is because you can embed/link the wxWidgets library in the wxFRED executable.  You can't do that with Qt; Qt requires that you install a framework or runtime environment.  Given how much trouble we already have with one dependency, namely OpenAL, we are emphatically not going to add another one.

I've done a bit of poking into building a straight events editor, and that looks to be reasonable including an undo stack.

Ok.

I'm still missing the file format specification though - and that's something I can't do alone.
- I'm now making a start in FS2 Mission File Format in the Wiki.

I don't think there was ever an official mission specification.  It's one of those things that's its own standard.

Anyway, back on topic:
Undo pretty much requires that you build the editing program around the Undo stack - bolting one in afterwards is almost impossible. (You'll almost certainly break something)

I completely agree with this.  In fact that would be one of my top two design priorities if FRED were to be rebuilt.  (The other priority would be correct handling of embedded comments.)

I'm considering using the FS2 text files as the internal representation, with each individual editor in the new package pulling out the bits it needs, playing with them, and then putting them back.

Hmm, that's starting to make a bit of sense.  That would help with the commenting system too.

I'm looking at using the built-in Qt Undo framework.

WxWidgets has something similar.


Anyway, what sort of code qualifications do you have?

[portej05]

One very important reason we're using wxWidgets is because you can embed/link the wxWidgets library in the wxFRED executable.  You can't do that with Qt; Qt requires that you install a framework or runtime environment.  Given how much trouble we already have with one dependency, namely OpenAL, we are emphatically not going to add another one.

It is in fact a damn good reason to develop an installer/updater, but it is not a good reason to statically link everything.
Statically linking things is not a good idea unless the system is never going to change (i.e. embedded systems).

EDIT: Additionally, the way your response reads suggests that there hasn't been an evaluation of framework alternatives, rather that it was a case of `this one statically links'.

(The other priority would be correct handling of embedded comments.)

That appears to have been a hack to start with.

[Goober5000]

It is in fact a damn good reason to develop an installer/updater, but it is not a good reason to statically link everything.
Statically linking things is not a good idea unless the system is never going to change (i.e. embedded systems).

I assume this references your thread in the internal.   But isn't that taken care of if all releases are built from scratch, i.e. no release build is ever linked with a wxWidgets library made on another computer?

EDIT: Additionally, the way your response reads suggests that there hasn't been an evaluation of framework alternatives, rather that it was a case of `this one statically links'.

I haven't evaluated Qt personally, but you and karajorma had an extensive discussion on this recently.

[portej05]

An example rulebook for sexps (note: this is not complete by any stretch of the imagination, is not valid XML (reallyreallyreally dumb writer) and doesn't handle argument types just right yet), but it took 40minutes to produce, and could be done automatically now.

[attachment deleted by Tolwyn]

[Tomo]

Anyway, what sort of code qualifications do you have?

In C++, sweet FA - just starting to learn it, transitioning from Delphi.

I've been building and maintaining (primarily) in-house applications in Delphi for a few years, but have now come to the decision that I need to change to C++ as Delphi is no longer widely supported.

So I'm partially looking for challenges to force me to learn, as the stuff I'm maintaining at work is in Delphi and there's no point in porting it.

portej - loving your (not!)XML. Entities? We don't *need* no stinkin' entities!
I fixed the > and < SEXP entries for you - attached - so it'll open in any parser.

More seriously, that looks easily usable as either a 'compiled in' or 'load at runtime' datafile.
- The latter would allow FRED to be updated to have new SEXPs without recompiling, the former removes the need to distribute the file.

[attachment deleted by Tolwyn]

[karajorma]

I haven't evaluated Qt personally, but you and karajorma had an extensive discussion on this recently.

We didn't discuss it that much but as far as I'm concerned the decision has been made already an it was wxWidgets. Spicious has already ported the standalone GUI to wxWidgets. The new launcher is wxWidgets. It would be pretty odd to make the project dependant on two different GUI toolkits (thereby requiring coders to learn both) without a pretty damn good reason for it.

So far I haven't heard one of those and the fact that we'd have to require users to install a framework of some sort or add .dlls is a huge black mark against Qt.

[Goober5000]

It would be pretty odd to make the project dependant on two different GUI toolkits (thereby requiring coders to learn both) without a pretty damn good reason for it.

Hmm, another good reason.  I danced around it but didn't quite realize it.

[portej05]

portej - loving your (not!)XML. Entities? We don't *need* no stinkin' entities!
I fixed the > and < SEXP entries for you - attached - so it'll open in any parser.

I did warn ya It was more proof of concept than anything else. If I was doing it seriously I would have used a proper writer, not just cout << "<sexp "
I set myself a challenge of 30mins to get to that result, it took only slightly longer, but getting an XML framework in there would have taken longer.

More seriously, that looks easily usable as either a 'compiled in' or 'load at runtime' datafile.
- The latter would allow FRED to be updated to have new SEXPs without recompiling, the former removes the need to distribute the file.

That is the entire point. It needs a fair bit lot more work before it gets to that point, but otherwise that's the aim.

[karajorma]

What I'm not getting is why this system wouldn't work for both FS2 and FRED?

[portej05]

It's likely that this would not be anywhere near as efficient enough - it's still an idea in progress, it's nowhere near ready for thinking about getting into the engine.

The best example of this is that I haven't figured out how to handle the arguments yet - the OPF series vs the OPR series for nested sexps - if this was a totally clean approach there are some neat ways to do it, but this isn't a totally clean approach.
But can you see how much simpler the code would be - the amount of data stored in the code would be massively reduced with this kind of approach.

[Tomo]

It would be pretty odd to make the project dependant on two different GUI toolkits (thereby requiring coders to learn both) without a pretty damn good reason for it.

Hmm, another good reason.  I danced around it but didn't quite realize it.

YAL is Qt, and at present it looks like it's working fine under Windows and Linux, possibly with a few issues under Mac OSX still to be corrected.
(I lost track of the threads on the Mac support)

Right now, there's a standalone running in wx, and that's it.  The standalone was ported multiplatform first as it's stated to be relatively easy. (As far as porting ever can be)

For me, there are two core reasons for going to Qt:

1) There's already a released free, LGPL licensed cross-platform RAD IDE that everyone in the community can use.
This means we only need to support a single project file for all platforms and all community members.

2) The IDE and Qt framework is widely used in commercial software.
Thus many community members can justify learning it on company time, and there are many commercial entities paying for the framework to be maintained and supported.

Oh, and Qt 4 can be statically linked if you want, with the '-static' flag. I think this is a relatively new option though.

[portej05]

For me, there are two core reasons for going to Qt:

1) There's already a released free, LGPL licensed cross-platform RAD IDE that everyone in the community can use.
This means we only need to support a single project file for all platforms and all community members.

There're even plugins for VS that make things a little easier.
There isn't a good, free IDE for wx.
The only odd thing to get used to is the MO Compiler (moc), but that's just a prebuild step.

2) The IDE and Qt framework is widely used in commercial software.
Thus many community members can justify learning it on company time, and there are many commercial entities paying for the framework to be maintained and supported.

It's also got Nokia behind it, and the commercial use aspect is certainly appealing.

Oh, and Qt 4 can be statically linked if you want, with the '-static' flag. I think this is a relatively new option though.

Please, NO!
I've outlined static linking and my objections to it before (mainly on the internal thread), and most of the issue revolves around linking with other libraries (think what happens when a prebuilt component is distributed built against a different CRT to the one you're building against and you allocate and free memory between them), which is VERY likely to occur.

[Tomo]

What I'm not getting is why this system wouldn't work for both FS2 and FRED?

The real reason is that FS2 needs to know what the SEXP means - how to evaluate it, and how to handle the effects of a SEXP becoming true.

At present this has that massive CASE statement at its core - very efficient when comparing against constants, but quite slow if it compared against a runtime-generated SEXP array.

So FS2 should stay with the constants.

However, FRED does not care what a SEXP means - it's not a simulator.

In fact, the XML style portej just suggested would allow FRED to load a different "SEXP-FLAG" config file depending on the target.
- So you could use the same build of Fred for "Retail", "3.6.10" or "3.6.11alpha" depending on the target FreeSpace2.

This would mean that you could use a 'newer' build of FRED (with associated bug fixes) to create missions for older FS2 versions, without needing to know what is and isn't supported by that version.

Right now, we have to release new builds of FRED with every new build of FS2 Open, which feels very clumsy.

portej's suggestion removes that need, as only a small configuration file required to 'update' your FRED.
Thus new builds of FRED are only required when features/bugfixes specifically for FRED become available - the shared bit would be POF code.

The prerequisite for this is the ability to quickly and easily generate that config file - portej appears to have (almost) solved that problem now.

Oh, and Qt 4 can be statically linked if you want, with the '-static' flag. I think this is a relatively new option though.

Please, NO!
I've outlined static linking and my objections to it before (mainly on the internal thread), and most of the issue revolves around linking with other libraries (think what happens when a prebuilt component is distributed built against a different CRT to the one you're building against and you allocate and free memory between them), which is VERY likely to occur.

I don't like it either, just saying that it's possible!

Installation of the Qt libraries is simply a case of copying the required Qtxxx.dll files into the same folder as the executable.
It doesn't need to be registered like OpenAL did.

I've done a bit of testing with 'breaking' installations, and the error messages I got were excellent:
"The application failed to start because QtCore.dll was not found. Reinstalling the application may fix the problem."

So the support is pretty easy.

[portej05]

Installation of the Qt libraries is simply a case of copying the required Qtxxx.dll files into the same folder as the executable.

i.e. provide an installer/updater with FRED

It doesn't need to be registered like OpenAL did.

OpenAL needs to be registered?
I just copied the two dlls into the same directory as FSO (on my new windows installation).

[The E]

In fact, the XML style portej just suggested would allow FRED to load a different "SEXP-FLAG" config file depending on the target.
- So you could use the same build of Fred for "Retail", "3.6.10" or "3.6.11alpha" depending on the target FreeSpace2.

This would mean that you could use a 'newer' build of FRED (with associated bug fixes) to create missions for older FS2 versions, without needing to know what is and isn't supported by that version.

Oh, This I really like. Would go a long way toward building a kind of "FreeSpace Studio" application.

[karajorma]

Funny cause I absolutely despise it.

Having the same version of FRED support different SEXPs depending on an external file is a recipe for disaster.

[The E]

Okay, this is going to come out as overly hostile. I apologize in advance for any hurt feelings.

The way I see it, there are currently two initiatives going on. One is to build a replacement for FRED that uses wxWidgets and is cross-platform. A good idea, and worth pursuing, but I and other people feel that there is a missed opportunity here, as well as some concerns about the choice of Framework. wxWidgets does not have a free IDE that allows WYSIWIG editing of the interface, which at least for me is a major drawback.

What I and a few others would like to do is to build a sort of FS IDE, which offers a unified interface to all aspects of FS modding. And frankly, you and Goober naysaying every idea and concept that is developed for this is not helping.

I'm fully aware of your history of working on this project, but why don't you let us work on it, and see what works and what doesn't.

[karajorma]

Don't you find it telling that the two people doing the most naysaying are the two who know FRED the best?

I dislike this idea because it means more work for me to add SEXPs. I dislike it because it is a support nightmare (support via a text file for FRED can easily result in people having up to date FS2 builds which then crash out horribly as soon as you try to open the same mission in FRED). And I dislike it because it is a massive amount of work for what will end up as a pretty minor gain when all is said and done. Time that could have been spent on much more important things.

On top of which the whole "Shut up if you don't like it" thing doesn't work when you're talking about something that would have major implications on the entire project. Especially as the two people you're telling to shut up and let you divorce the code and FRED projects are the ones who would end up having to work on the newly split version once it was done.