[FreeSpaceFreak]

Done with my moderately successful wxWidgets cleaning tool, I tried to build wxFRED on MSVC10. It didn't work. Compile-time errors, run-time errors, you name it. So I fixed it. Diff attached.

Warning: it has taken a blunt axe and a bulldozer to fix it.

• Upgraded the project file from wx 2.8 to 2.9, since 2.8 doesn't work on MSVC10. Theoretically it should still compile under 2.8 as well, you'll only have to change the linked libraries in the project file.
• Upgraded to Unicode. wxWidgets is planning on dropping ASCII support in the near future, and with wx 2.9 Unicode is much more convenient already.
• Removed non-existing voicefilemanager files from the project
• Removed non-functioning XML stuff from the project
• Added ../../code to the include directories

And possibly some more which I forgot already. Oh, and I only fixed Debug configuration - haven't touched Release (yet). And I haven't been able to test my changes in Linux, something's wrong with the linked wx libraries there (couldn't find wx/wxprec.h) and the FSO makefiles (i.e. autogen.sh, configure.ac, Makefile.am) are a little over my head, so I couldn't fix it. (On that note, wouldn't it be easier to have separate makefiles for wxFRED?)

Now, what does it do? Nothing. When run, it's just an empty frame. I might have thrown out some functionality with the weird XML stuff, I'm aware of that. But at least it compiles and runs now, so that's an improvement.

[attachment deleted by a ninja]

[jg18]

Done with my moderately successful wxWidgets cleaning tool, I tried to build wxFRED on MSVC10. It didn't work. Compile-time errors, run-time errors, you name it. So I fixed it. Diff attached.

As far as I know, simply getting wxFRED to compile and run is farther than anyone else has gotten in the recent past, so well done. I'll need to take a closer look at your attached diff later. By the way, if you could attach .diff files as uncompressed files, rather than in a .zip archive, that would be appreciated.

Warning: it has taken a blunt axe and a bulldozer to fix it.

I suppose you have to start with getting something working and then build up from there.

• Upgraded the project file from wx 2.8 to 2.9, since 2.8 doesn't work on MSVC10. Theoretically it should still compile under 2.8 as well, you'll only have to change the linked libraries in the project file.

Hmm, odd that 2.8 doesn't work on MSVC 2010. I've used 2.8.12 with VS2008 Professional, but I've never tried VS2010.

• Upgraded to Unicode. wxWidgets is planning on dropping ASCII support in the near future, and with wx 2.9 Unicode is much more convenient already.

Yeah, upgrading to Unicode is a good move.

• Removed non-existing voicefilemanager files from the project
• Added ../../code to the include directories

Yup, these are changes I also had to make to get it to compile, although I couldn't get it to link. This was the VS2005 project running in VS2008.

• Removed non-functioning XML stuff from the project

The XML file is an XRC file, an XML-based specification of wxFRED's GUI widgets (dialogs, buttons, etc) and their layout. It's analogous to MSVC's RC files for Windows GUI applications.

And possibly some more which I forgot already. Oh, and I only fixed Debug configuration - haven't touched Release (yet). And I haven't been able to test my changes in Linux, something's wrong with the linked wx libraries there (couldn't find wx/wxprec.h) and the FSO makefiles (i.e. autogen.sh, configure.ac, Makefile.am) are a little over my head, so I couldn't fix it. (On that note, wouldn't it be easier to have separate makefiles for wxFRED?)

I'd think that since wxFRED, like FRED 2 Open, is intimately tied with the FSO codebase, since they all use the mission data structures, separate autotools configuration scripts for wxFRED wouldn't be possible, but that's just a guess.

Now, what does it do? Nothing. When run, it's just an empty frame. I might have thrown out some functionality with the weird XML stuff, I'm aware of that. But at least it compiles and runs now, so that's an improvement.

The reason it's an empty frame is that it's missing the XRC file, as mentioned above. That said, a working project with an empty frame is indeed a better starting point than a non-working project with an XRC file.

One thing that will certainly help if you haven't done it yet is to build wxrc, which IIRC compiles the XRC file to a binary format that wxFRED can use. wxrc is in a separate MSVC project within the wxWidgets source tree. in 2.8.12, the wxrc project is in wxWidgets-2.8.12\utils\wxrc .

Thanks for looking into this.

[Iss Mneur]

• Upgraded the project file from wx 2.8 to 2.9, since 2.8 doesn't work on MSVC10. Theoretically it should still compile under 2.8 as well, you'll only have to change the linked libraries in the project file.

Hmm, odd that 2.8 doesn't work on MSVC 2010. I've used 2.8.12 with VS2008 Professional, but I've never tried VS2010.

wxWidgets 2.8 and VS2010 is how I build wxLauncher and it works just fine (2.8.10 and 2.8.11, haven't tried 2.8.12).  The bit about not being able to build wxLauncher with VS2010 has to do with CMake not generating the correct solution.

And possibly some more which I forgot already. Oh, and I only fixed Debug configuration - haven't touched Release (yet). And I haven't been able to test my changes in Linux, something's wrong with the linked wx libraries there (couldn't find wx/wxprec.h) and the FSO makefiles (i.e. autogen.sh, configure.ac, Makefile.am) are a little over my head, so I couldn't fix it. (On that note, wouldn't it be easier to have separate makefiles for wxFRED?)

I'd think that since wxFRED, like FRED 2 Open, is intimately tied with the FSO codebase, since they all use the mission data structures, separate autotools configuration scripts for wxFRED wouldn't be possible, but that's just a guess.

It would be possible but it doesn't make any sense separating the build scripts becuase of the common dependency on code.lib.

[kkmic]

So I fixed it.

Now that' some attitude 

[FreeSpaceFreak]

Hmm. On the plus side, I got the XRC menu bar to show up. The menu bar and most of the dialogs have already been constructed (good work Goober?), as pretty much one-on-one copies of the original FRED. A wxformbuilder project file is also included.

On the downside, most of the dialog boxes are broken, and even the latest version of wxformbuilder doesn't appear to be doing anything about it. It might be wx2.9 being more correct on the form buildup, I guess - the XRC files produced by formbuilder have some very fishy sections (mainly number of rows x columns not matching number of cell entries).

As for 2.8 on VC10, the project files won't convert properly for me, so can't build it. Zacam linked me to wxPack, which is supposed to work, but I'd rather stick to official releases if possible...

[Goober5000]

Taylor constructed a large number of the XRC dialogs, so credit should go to him as well.

[jg18]

Hmm. On the plus side, I got the XRC menu bar to show up. The menu bar and most of the dialogs have already been constructed (good work Goober?), as pretty much one-on-one copies of the original FRED. A wxformbuilder project file is also included.

Well done on getting it working.

On the downside, most of the dialog boxes are broken, and even the latest version of wxformbuilder doesn't appear to be doing anything about it. It might be wx2.9 being more correct on the form buildup, I guess - the XRC files produced by formbuilder have some very fishy sections (mainly number of rows x columns not matching number of cell entries).

What do you mean by broken?

If wxFormBuilder is producing invalid XRC files, that's... kind of a problem. I'd certainly hope that newer versions of wxWidgets aren't breaking compatibility with older XRC files. I've done XML editing by hand (DocBook to be precise) and wouldn't necessarily be averse to manually editing the XRC file if necessary, even if it wouldn't be my first choice. Too bad the wxWidgets Team doesn't publish an XML schema of the XRC format, which could be used to validate XRC files in conjunction with XML editors. I mean, in theory it could be reverse engineered from the published XRC examples and the wxrc source, but that would be messy and not fun, not to mention it'd need to be updated any time they change the format.

As for 2.8 on VC10, the project files won't convert properly for me, so can't build it. Zacam linked me to wxPack, which is supposed to work, but I'd rather stick to official releases if possible...

Yeah, my inclination would also be to stick to official releases. At least official releases are backed by the wxWidgets Team, even if there are known issues that go for years without being fixed. With a third-party bundle, though, you're at the mercy of whoever maintains it. In the case of wxPack, it's kind of disconcerting that it hasn't been updated in a year and a half, and the documentation and packaging are highly Windows-centric.

[Goober5000]

Taylor and I both used DialogBlocks to edit the XRC.  It unfortunately requires a registration fee.  (I think at one point I may have offered to cover the registration fee for any SCP member who wants to use it, so I'll keep that offer open.)

[Spicious]

Trying to support both 2.8 and 2.9 seems like a disaster just waiting to happen.

[Nuke]

any chance throwing in some scripting support? would be useful for creating plugins for fred, and automating some repetitive operations.

[FreeSpaceFreak]

What do you mean by broken?

The rows x columns thing produces runtime errors... It can be fixed in wxformbuilder, but it needs to be done manually. I did it for the asteroids editor, but something else in the hierarchy (probably a missing wxFlexGridSizer or something) is now causing several panes to show up on top of each other. It's looking just fine in wxformbuilder, but when compiled it's a mess.

If wxFormBuilder is producing invalid XRC files, that's... kind of a problem. I'd certainly hope that newer versions of wxWidgets aren't breaking compatibility with older XRC files. I've done XML editing by hand (DocBook to be precise) and wouldn't necessarily be averse to manually editing the XRC file if necessary, even if it wouldn't be my first choice. Too bad the wxWidgets Team doesn't publish an XML schema of the XRC format, which could be used to validate XRC files in conjunction with XML editors. I mean, in theory it could be reverse engineered from the published XRC examples and the wxrc source, but that would be messy and not fun, not to mention it'd need to be updated any time they change the format.

It's probably all fixable in wxformbuilder, don't think we really need an other program for it (like DialogBlocks). It will only require some care - someone needs to go through the dialogs after compilation and fix everything that needs repairing.

Trying to support both 2.8 and 2.9 seems like a disaster just waiting to happen.

Bah, I did that for the cleaning thing I wrote... The issues I ran into is that for 2.8 compatibility, you need the wxT() or _T() macros around each literal (2.9 doesn't need those anymore), and the command-line description uses a different string encoding (which I solved with a simple version number check, #if (wxMAJOR_VERSION >= 3 || (wxMAJOR_VERSION == 2 && wxMINOR_VERSION == 9)) ).
But in the long run, you're right, we'd probably better switch over to 3.0 and stick with it for a while, I guess.

any chance throwing in some scripting support? would be useful for creating plugins for fred, and automating some repetitive operations.

I'd been thinking about a built-in text editor with copy+paste, that should help some with the repetitive stuff... Scripting, ehh, we'll see.

Attached diff makes the XRC menus work, so you can check out the dialogs. I also fixed Release configuration (the Inferno configurations I haven't touched yet). Sorry I had to zip it up, it's too big otherwise.

[attachment deleted by ninja]

[jg18]

What do you mean by broken?

The rows x columns thing produces runtime errors... It can be fixed in wxformbuilder, but it needs to be done manually. I did it for the asteroids editor, but something else in the hierarchy (probably a missing wxFlexGridSizer or something) is now causing several panes to show up on top of each other. It's looking just fine in wxformbuilder, but when compiled it's a mess.

*snip*

It's probably all fixable in wxformbuilder, don't think we really need an other program for it (like DialogBlocks). It will only require some care - someone needs to go through the dialogs after compilation and fix everything that needs repairing.

Even if it's fixable in wxFormBuilder, it sounds like a pain to do, not to mention error-prone. Besides, if Goober's willing to pay for a registered copy of DialogBlocks... And since I'm a student, you can get it for ~50% off.

Trying to support both 2.8 and 2.9 seems like a disaster just waiting to happen.

Bah, I did that for the cleaning thing I wrote... The issues I ran into is that for 2.8 compatibility, you need the wxT() or _T() macros around each literal (2.9 doesn't need those anymore), and the command-line description uses a different string encoding (which I solved with a simple version number check, #if (wxMAJOR_VERSION >= 3 || (wxMAJOR_VERSION == 2 && wxMINOR_VERSION == 9)) ).
But in the long run, you're right, we'd probably better switch over to 3.0 and stick with it for a while, I guess.

I agree that trying to support multiple versions of wxWidgets is not a good idea. I'd be inclined to move past 2.8, although that'd make releasing on Linux more complicated, since then people couldn't use the 2.8 packages that are available in many distros' repos.

any chance throwing in some scripting support? would be useful for creating plugins for fred, and automating some repetitive operations.

I'd been thinking about a built-in text editor with copy+paste, that should help some with the repetitive stuff... Scripting, ehh, we'll see.

It's too early at this point to know what new features might be added to wxFRED. I'd say that scripting support isn't necessarily out of the question.

Attached diff makes the XRC menus work, so you can check out the dialogs. I also fixed Release configuration (the Inferno configurations I haven't touched yet). Sorry I had to zip it up, it's too big otherwise.

Okay, thanks. I'll need some time before I can look at it, although it'd likely need to pass muster with Goober before it or some form of it could be committed.

Thanks again for working on this.

[Goober5000]

Since one of the points of using wxWidgets is to remain compatible across multiple platforms, I'd be in favor of using the older, more commonly supported versions.

[jg18]

Hmm, fair enough. I suppose we could start with using 2.8, and then if there's a feature or bug fix in 2.9+ that we must have, then we can consider whether to switch.

[Iss Mneur]

Though, by the time that wxFRED is actually available for general use, 2.8 will not be the "common" version.  So I don't know if going with the older currently well supported 2.8 really makes that much more sense.

[Goober5000]

If it's "currently" well supported, then that's what we should "currently" design to.  Then we can cross the upgrade bridge when we come to it.

[jg18]

I'm inclined to agree with Iss. Even under the best of circumstances, wxFRED would not be ready for release until many months from now. Targeting what's currently well supported when there won't be anything releaseable any time soon doesn't make much sense to me. Furthermore, from what I've seen of 2.9, upgrading code written for 2.8 would take a non-trivial amount of work (and I might be understating that), although I don't know the details offhand.

Besides, my first steps on this project don't even involve coding but rather understanding how to use FRED and how FRED works, internally and externally, with internally meaning how FRED's state changes in response to FREDder actions, as well as how FRED implements some of the more complex GUI widgets like the 3-D grid. (That also means I wouldn't need a registered copy of DialogBlocks for a while. [Although the price can always go up... ])

[Goober5000]

I'm inclined to agree with Iss. Even under the best of circumstances, wxFRED would not be ready for release until many months from now. Targeting what's currently well supported when there won't be anything releaseable any time soon doesn't make much sense to me.

This touches on the usability factor that we discussed in the internal thread.   We need to target what's well-supported because we want wxFRED to be accessible to a wide population.  We don't want to target the cutting edge because few people will be there with us.

This will remain true even taking into consideration the months until the wxFRED release.  Only a small percentage of the wxFRED userbase will upgrade their systems or otherwise be able to take advantage of the latest and greatest.

WxFRED's goals are different from a commercial game's goals or a media pack's goals.  We are not concerned about having the latest and greatest.  We are concerned about being available to, and usable by, a large number of platforms.

[jg18]

This touches on the usability factor that we discussed in the internal thread.   We need to target what's well-supported because we want wxFRED to be accessible to a wide population.  We don't want to target the cutting edge because few people will be there with us.

This will remain true even taking into consideration the months until the wxFRED release.  Only a small percentage of the wxFRED userbase will upgrade their systems or otherwise be able to take advantage of the latest and greatest.

WxFRED's goals are different from a commercial game's goals or a media pack's goals.  We are not concerned about having the latest and greatest.  We are concerned about being available to, and usable by, a large number of platforms.

Just to make sure we're all clear on what's under discussion, the only users who are affected by the decision of which version of wxWidgets to use are those who depend on third-party builds of the wxWidgets libraries, namely Linux users using the pre-compiled wxWidgets packages in their distros' repositories. Windows and Mac users are unaffected, since the wxFRED team would always include their own build of the wxWidgets libraries with the downloads for those platforms (assuming that the wxFRED build system would be similar to wxL's).

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.

In any case, as I mentioned just above your post, "my first steps on this project don't even involve coding but rather understanding how to use FRED and how FRED works." After I get a better understanding of FRED and consequently of the needs of the project, I'll be in a better position to say whether wxFRED needs 2.9+, and if so, why.

[Goober5000]

The way I originally set up the wxFRED project in 2004, and the way I think is best to distribute it, is as a static library embedded in the executable.  In other words, there wouldn't be a separate DLL or library; the wxFRED executable itself would contain all the necessary wxWidgets dependencies.