Getting ready for Id 2.0 with wxWidgets

[LegalizeAdulthood]

Sound support isn't going to make it into 1.1. I'm undecided if I'm going to try a 1.2 release with sound support or just push it to some later release (maybe not even 2.0).

Moving to wxWidgets is more important than sound support and I thought the sound support would be easy, but it's not. I think ultimately the sound support is going to require a secondary sound playback thread and things are just going to be too difficult if I introduce multi-threading in 1.1.

To get ready for the next push to wxWidgets, I've added a bunch of issues for migrating all the existing user interface to wxWidgets.

I've grouped them using issue the following labels:

Label	Description
wx	Basic wxWidgets stuff
wx-control	New wxWidgets controls that need to be created
wx-dialog	New dialogs to replace existing text screens
wx-tool	New 'tools' to replace existing mouse/key interactions (see #185)

I've only assigned the bare minimum to the 2.0 release right now.

The reason I'm starting this discussion is that once I've got the basics done for the wxWidgets port in 2.0, those other issues for each piece of UI can be worked on independently by other developers. I know it's not sexy fractal code, but it's stuff that's got to be done to bring the code forward.

For the text prompt screens, I have an idea of how to shim things over using the existing FullScreenValues inputs to full_screen_prompt. I will use the metadata in the structure to add wxWidgets to a dialog box programmatically. This won't be the greatest looking UI but it will be the simplest way to bridge things over.

At some point the keyboard polling will have to be switched over to standard GUI event dispatching. Some thoughts on this are sketched out in #185.

In general this is the 'inversion of control' that happens when you switch from polling I/O (as is done currently with all the if (driver_key_pressed()), etc. stuff) to event-based control. The polling I/O will remain for a while until everything is switched over and Id more like a standard GUI program.

-- Richard

[PaulTheLionHeart]

I don't think sound support is a big deal. I agree that getting a good GUI up and running is the highest priority.

Is there a way to convert the Windows .rc files into wxWidgets? This could save a lot of effort as I have built a number of screens for ManpWIN that can easily be adapted to ID. The details can be discussed offline.

[LegalizeAdulthood]

wxWidgets has an XML markup file format for specifying dialogs. See XML Based Resource System (XRC) in their documentation. It probably takes as much work to convert an RC file by hand as it does to simply make the XRC file by hand, so I'm not sure that it really saves anything. XRC files are different enough from Windows resource scripts that you need to adjust a bunch of things by hand anyway. Most of the screens funnel through full_screen_prompt, so the intermediate stage is to programmatically construct the dialog from the FullScreenValues structures using the wxWidgets API.

Hacking the full_screen_prompt routine to write out initial XRC scripts is probably the easiest way to convert existing screens to a starting point for a dialog with an XRC script.

Ultimately, XRC files will probably be used because that is the path towards localization of user-interface text into other languages.

[LegalizeAdulthood]

BTW, for anyone unfamiliar with wxWidgets, but familiar with MFC, please see the video Porting from MFC to wxWidgets
.

[LegalizeAdulthood]

I've added a few more wxWidgets-related issues to the 2.0 milestone. My expectation is that over time more and more of the existing screens will be converted to dialogs and tool windows and so-on in subsequent 2.x releases.

The priority for 2.0 is to get the infrastructure in place to support things to be event-driven instead of polling the keyboard/mouse for input.

Experience from past projects has taught me that the GUI can sink a lot of development effort and time if you're not careful, so I don't want to stack too much onto the 2.0 milestone.

[PaulTheLionHeart]

I have only ever done GUIs using Visual studio so I take your word for it. Although it would be hard to do a partial migration to GUI based rather than key and mouse polling. I'll be guided by your experience here.

[LegalizeAdulthood]

You can do a partial migration by what we're doing now: every time the keyboard is polled, you pump all the messages in the event queue and turn any key events into keycodes in a buffer. IIRC, this is what WinFract did as well.

My intention for 2.0 is to get all everything event-based and remove the polling once and for all.