[Darkmage]

So where is wxFRED sitting at the moment in terms of development effort? I've seen the WXWindows templates for the UI, but other than that haven't really seen much else floating around. Is the polan to rewrite the codebase from scratch, or will we be attempting to port the Windows FRED2 code directly into wxFRED? What pros/cons are there to either approach? As far as I am aware wxFRED was designed to use the MFC quite heavily? Is this correct? Would it be simple to separate the function calls to the UI from the underlying code, or is it one big spaghetti mess?

[mjn.mixael]

wxFRED exists to create a version of FRED that is without MFC so that it will be cross platform. As for its status? Dunno.

[z64555]

hey Darkmage

Currently, I'm pretty much the lead dev on wxFRED of a team of 1 (me...) with mirakus offering some help here and there. wxFRED's development has been stalled for at least a year since I haven't been able to devote enough time in studying both the MFC and wxWidget's API's.

FRED itself uses the MFC which, as you probably know, is exclusive to Windows. FRED can be run on Linux machines via WINE, but rather poorly.

Currently, wxFRED has its GUI elements designed and ready to go, but the backend code that powers the UI needs to be constructed. My main focus is to get the main editor's viewing frame working before moving onto implementing any of the editors. The Plan(TM) intended for wxFRED is to create a core set of functions that can operate independently of the UI, so as to open the possibility of running wxFRED via batch scripts as well as *hopefully* make it API independent. I have a link to the git branch in my signature.

There's been some work on qtFRED, which uses the QT libraries as its GUI code, but its developer has gone awol shortly after he managed to the editor working by basically copying over FRED's rendering code. m|m managed to clone qtFRED onto his git repo, but has had his attention elsewhere since then.