[jg18]

If static linking were used for wxFRED on all platforms, as you seem to be recommending, then the usability concern that you raised before would disappear, no?

[FreeSpaceFreak]

There would only be a usability issue for those Linux users who want to build their own binaries, I guess - and they are smart enough to get the correct version of wxWidgets, too. I'm all for static linking - FSO's dynamic linking with OpenAL is enough of a tech support issue as it is.

Have there been thoughts about the wxFRED backend yet? Re-use the "giant unwieldy" -FRED code as much as possible, or take the opportunity to make it more object-oriented?

[pecenipicek]

as far as i see this stuff, anyone savvy enough to compile by himself under linux, can handle compiling an additional lib/installing a dev-package of said lib.


also, wxwidgets does not conflict with FSO's license i take it?

[niffiwan]

I'd be interested in hearing from Linux users, especially SCP coders using Linux, on whether having to build wxWidgets from source to use wxFRED would be reasonable. Having to build libraries from source yourself is certainly not unheard of on Linux, even if it might be unusual. The issue might be too off-topic for this thread, however. Also note that wxWidgets 2.8 binary packages are not necessarily available in every distro's repo, so there may be Linux users who will have to build wxWidgets from source no matter what.

Building from source can range from slightly irritating (i.e. the OS no longer deals with updates for you) to extremely painful (when you trigger a cascade of dependencies that also need to be built from source).  From my playing tonight, wxWidgets 2.9 is probably towards the OK end - while my 10.04 system doesn't have gtk2.4 that wxWidgets requires, my 11.10 VM has gtk3.2 (not supported yet) and gtk2.24 (which let a configure complete OK)

Of course, if you distribute a statically linked wxFred binary then this is all moot anyway.

[ni1s]

Might it perhaps be a good idea to reevaluate if WX  is the framework to be had? Qt4 appears to be at leats on par with WX nowadays, and more importantly its development and UI layout tools are readily available.

[Iss Mneur]

Might it perhaps be a good idea to reevaluate if WX  is the framework to be had? Qt4 appears to be at leats on par with WX nowadays, and more importantly its development and UI layout tools are readily available.

WX is what SCP has experience with, it is what wxLauncher is done with, which are now our primary reasons to use wxWidgets.  (Personally, I like the look and feel of wxWidgets apps better than qt ones as well).

Qt4 at the time the original decision was made had a license that conflicted with FSO's which would require that QT be distributed separately like OpenAL.  That is it would not allow for static linking against FRED because of our license.

also, wxwidgets does not conflict with FSO's license i take it?

No. wxWidgets has an exception in its license that allows it to be staticly linked with code that is under any license, propriety, odd ball (FSO), or otherwise.

Have there been thoughts about the wxFRED backend yet? Re-use the "giant unwieldy" -FRED code as much as possible, or take the opportunity to make it more object-oriented?

Yes, SCP has discussed it on internal.  I will not elaborate beyond stating SCP is discussing the merits of both approaches.  There is a general leaning to "cleaning it up", though what exactly will entail is still up for debate.

[Darkmage]

IF SCP leans towards rewriting wxFred to use non-FRED code. Would they attempt to structure wxFred to support other game engines other than FreeSpace2? VegaStrike could benefit massively from a 3D game level editor and I have been investigating a similar effort to writing a Fred2 knockoff for crossplatform use.

[Goober5000]

IF SCP leans towards rewriting wxFred to use non-FRED code. Would they attempt to structure wxFred to support other game engines other than FreeSpace2?

There is a huge leap in complexity between these two concepts.  So probably not.

[Cyborg17]

Not to mention that VegaStrike almost certainly doesn't use sexps or use the same mission file format.  So you'd basically have an editor where you could place things and name them and then save them in the wrong format.

[Darkmage]

Actually I am looking to implement a SEXP style scripting system into vegastrike. Massaging the output of FRED2 to match what Vegastrike expects isn't the hardest thing to do from what I know of both engines. I'm more curious at this stage about where wxFred is at, and whether I should bother using it or just blatantly ripoff the FRED UI and make my own program.

[AdmiralRalwood]

Massaging the output of FRED2 to match what Vegastrike expects isn't the hardest thing to do from what I know of both engines.

Actually, speaking as someone who semi-recently went all over the mission-saving code, altering the output format of FRED2 is a very involved process (unless you want to do something relatively trivial, like swapping two sections, or changing a label).