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.

[LegalizeAdulthood]

Since 1.0 had a target release date of VCFMW 19 in September, 2024, I'm going to set the release date for 2.0 to VCFMW 20 in September, 2025 :)

This will give me plenty of time to get more than just a bare bones wxWidgets version working and it's more likely that I'll have a good chunk of the UI moved to wxWidgets.

[PaulTheLionHeart]

Bring it on.

[LegalizeAdulthood]

Looks like I can implement a CGA text window completely with wxStyledTextCtrl, so yay! I won't end up writing a custom control after all, assuming a little experimenting validates this out.

[PaulTheLionHeart]

Great news. Let me know how you go.

[LegalizeAdulthood]

I've moved the completion date for the 2.0 milestone to November 2nd. Originally the idea was to complete it in time for VCFMW and give a talk on the progress made over the past year, but they don't allow repeat talk topics. So I've moved it out a little further to allow for more time than just the bare bones wxWidgets implementation.

Beyond the bare minimum, I'd like to have the tool framework in place and everything migrated to using tools and responding to events instead of doing polling I/O. There is a way to keep limping along with the existing polling I/O and that's what will be implemented first.

[PaulTheLionHeart]

Good call.

[LegalizeAdulthood]

Inversion of control (switching from polling I/O to event-driven I/O) is a really big change, so I've approached the problem incrementally. I'm refactoring the existing code to bring the polling out of inner loops and higher up in the call chain. So far, I've worked through the following "standalone" engines:

• ant automaton fa40a94
• bifurcation 4827150
• cellular automata b1223a5
• diffusion 279b8f6
• frothy basin ebb8936

This is how I'm going to incrementally transform the code so that ultimately at the level of id_main there is only a single place where keyboard I/O checks are performed and keystrokes are dispatched to the active computation. At that point it's essentially the same as event dispatching in a GUI program.

It is also addressing the long-standing desire I've had to separate computation of fractal images from user interface. As I go, I'm moving any code that does keyboard polling to libid/ui and keeping the core computation in libid/fractals or libid/engine. Once keyboard and mouse processing are completely isolated in the UI directory, we'll be much closer to multi-threaded support and networked rendering support. As I go, I've been adding more image tests to ensure that I'm not messing things up too badly :). There may be some small interaction bugs that are creeping in, but ultimately they will be sorted out before 2.0 is released.

[LegalizeAdulthood]

It is also addressing the long-standing desire I've had to separate computation of fractal images from user interface.

In case anyone is curious about the big picture, I'm pursuing a transformation of the code into what's called hexagonal architecture, where the core of the application is at the center and it is surrounded by "adapters" that talk to the outside world. The GUI is one such adapter. A network interface for distributed rendering could be another adapter. A batch processor with console output could be another adapter. A mobile device UI would be another adapter.

[PaulTheLionHeart]

This sounds liken a well thought out approach.