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.

[LegalizeAdulthood]

The work-in-progress on the wx branch has been merged to the master branch and the wx branch deleted. This will eliminate the need to constantly rebase the wxWidgets branch onto recent changes in master.

I've added workflows to build the wxWidgets code, but these are currently failing on linux until I clean up the leftover Win32-isms in the code and make it truly cross-platform. I used the Win32 implementation as the starting point for the wxWidgets implementation. I should be able to clean up these builds in the next few days. Then any wxWidgets related changes will be tested by the continuous integration builds to make sure I'm keeping everything portable across platforms.

The existing Win32/unix code is unchanged in the win32/unix directories and the wxWidgets code is in the wx directory. A CMake option was added to build the wxWidgets version: ID_USE_WX and CMake presets were added to configure, build, test and package the wxWidgets version. The wxWidgets version currently builds on Windows but is incomplete.

[PaulTheLionHeart]

Good work. It sounds like progress is steady.

[LegalizeAdulthood]

I took a little break, but I'm getting back into it now :)

I'm going to use GitHub Copilot to help me create the replacement Plot and TextWindow controls, we'll see how it does :)

[PaulTheLionHeart]

I've been using co-pilot in MSVC++ 2022 and find it very helpful. What you are doing for text widows is easy in Windows, but I have no idea about how to do it in Linux. I guess this is where wxWidgets comes in.

[LegalizeAdulthood]

The existing implementation of the Text window is done using the raw Win32 API. Initially I was thinking that I would implement the same thing using Xlib on linux, but I decided that it was just as much effort to do that as it was to code it in wxWidgets, so I abandoned that idea.

For wxWidgets, I'll be using wxStyledTextCtrl which lets me set a style attribute for every character cell. I'll use the style attributes to select the necessary foreground/background colors to mimic a CGA text screen. This is a temporary situation until everything is migrated to native GUI dialogs and whatnot.

[LegalizeAdulthood]

All the continuous integration builds are now green. CI now builds all combinations of "default" and "wx" variants in Debug and Release configurations on Windows and linux.

[PaulTheLionHeart]

How close are we to an Id release 2.0?

[LegalizeAdulthood]

At a bare minimum, I need to do these open issues on the milestone:

• Use wxWidgets for the application framework #219
• Port WinText to wxWidgets #220
• Port Plot to wxWidgets #221

That gets the text display and the graphics display working under wxWidgets, without any of the text screens converted to actual dialogs. I think we're on track so far to get more than that done, but it's likely some things on the 2.0 milestone won't get finished. I've got a presentation at Vintage Computer Festival Midwest in mid September, so there will be a pause on some Id work to prepare for that.

[PaulTheLionHeart]

Well done. You have achieved a great deal.

[LegalizeAdulthood]

OK, in master you will currently find a TextScreen control implemented as a derived class of wxStyledTextCtrl. There is also a simple test GUI program (TestTextScreen) that hosts the control so that I can do some manual testing of the control. As of now, the control exists, but isn't yet being used by the wxWidgets Id application. I will be connecting it up once TextScreen implements the full api of the existing WinText class.

If you want to see what this looks like, run the following command from the source directory: cmake --preset wx to configure everything with wxWidgets and (on Windows) put a Visual Studio solution in ../build-wx, e.g. a sibling of the source directory. The existing Win32 code is built with the default preset, putting the VS solution in ../build-default. So it is possible to build both versions of the code from a single source tree and separate build directories.

The first time you configure the wx preset, vcpkg will download wxWidgets and the necessary dependencies as source libraries and build them, so you will have to wait for that to complete before the solution is generated.

[PaulTheLionHeart]

I pulled down the latest master and tried to run: cmake --preset wx.

I got the error, "no such preset wx"

[LegalizeAdulthood]

It most definitely exists, you can see it here.

When you look at CMakePresets.json do you not see that line in your workspace?

Do you have the wx directory?

If your current directory was on a different branch than master, when you git pull master it brings the changes from github into your local repository, but doesn't update your current directory because you've got a different branch checked out.

[PaulTheLionHeart]

I see what happened. There was a conflict in pulling down master with fpu087.cpp. So I simply created a new branch and ran cmake --preset wx. After a long time of downloading all sorts of stuff, I got an error message "Could not find the WiX candle executable". Sigh!

[PaulTheLionHeart]

I see what happened. There was a conflict in pulling down master with fpu087.cpp. So I simply created a new branch and ran cmake --preset wx. After a long time of downloading all sorts of stuff, I got an error message "Could not find the WiX candle executable". Sigh!

[LegalizeAdulthood]

You should have a VS solution you can open if it got that far :)

[LegalizeAdulthood]

I've dropped the packaging step from the wx workflow preset. The wx packages can still be created manually with cpack --preset wx

[LegalizeAdulthood]

I just did a test by faking out WiX not being installed on my system and it should be OK now. I have WiX installed on my system and it's installed on the github CI runners, so I hadn't done a test with WiX not installed.

[PaulTheLionHeart]

Do I need to pull down a new version of master?

[LegalizeAdulthood]

Yes, you'll need to pull changes from master to get those fixes.

[PaulTheLionHeart]

Getting closer... but getting build errors...

Build started at 9:09 PM...
1>------ Skipped Build: Project: RUN_TESTS, Configuration: Debug x64 ------
1>Project not selected to build for this solution configuration
2>------ Skipped Build: Project: NightlyMemoryCheck, Configuration: Debug x64 ------
2>Project not selected to build for this solution configuration
3>------ Skipped Build: Project: Nightly, Configuration: Debug x64 ------
3>Project not selected to build for this solution configuration
4>------ Skipped Build: Project: Miscellaneous, Configuration: Debug x64 ------
4>Project not selected to build for this solution configuration
5>------ Skipped Build: Project: Experimental, Configuration: Debug x64 ------
5>Project not selected to build for this solution configuration
6>------ Skipped Build: Project: Continuous, Configuration: Debug x64 ------
6>Project not selected to build for this solution configuration
7>------ Build started: Project: native-help, Configuration: Debug x64 ------
8>------ Skipped Build: Project: ascii-doc, Configuration: Debug x64 ------
8>Project not selected to build for this solution configuration
9>------ Build started: Project: libid, Configuration: Debug x64 ------
9>editpal.cpp
9>get_fract_type.cpp
9>get_toggles.cpp
9>get_toggles2.cpp
9>get_view_params.cpp
9>input_field.cpp
9>C:\Github\id\iterated-dynamics\libid\ui\get_view_params.cpp(119,91): error C2228: left of '.out' must have class/struct/union
9> C:\Github\id\iterated-dynamics\libid\ui\get_view_params.cpp(119,91):
9> type is 'OutputIt'
9> with
9> [
9> OutputIt=char *
9> ]
9>C:\Github\id\iterated-dynamics\libid\ui\input_field.cpp(194,64): error C2228: left of '.out' must have class/struct/union
9> C:\Github\id\iterated-dynamics\libid\ui\input_field.cpp(194,64):
9> type is 'OutputIt'
9> with
9> [
9> OutputIt=char *
9> ]
9>C:\Github\id\iterated-dynamics\libid\ui\get_toggles.cpp(216,68): error C2228: left of '.out' must have class/struct/union
9> C:\Github\id\iterated-dynamics\libid\ui\get_toggles.cpp(216,68):
9> type is 'OutputIt'
9> with
9> [
9> OutputIt=char *
9> ]
9>C:\Github\id\iterated-dynamics\libid\ui\get_toggles2.cpp(82,65): error C2228: left of '.out' must have class/struct/union
9> C:\Github\id\iterated-dynamics\libid\ui\get_toggles2.cpp(82,65):
9> type is 'OutputIt'
9> with
9> [
9> OutputIt=char *
9> ]
9>C:\Github\id\iterated-dynamics\libid\ui\get_fract_type.cpp(608,62): error C2228: left of '.out' must have class/struct/union
9> C:\Github\id\iterated-dynamics\libid\ui\get_fract_type.cpp(608,62):
9> type is 'OutputIt'
9> with
9> [
9> OutputIt=char *
9> ]
9>C:\Github\id\iterated-dynamics\libid\ui\editpal.cpp(2386,58): error C2228: left of '.out' must have class/struct/union
9> C:\Github\id\iterated-dynamics\libid\ui\editpal.cpp(2386,58):
9> type is 'OutputIt'
9> with
9> [
9> OutputIt=char *
9> ]
9>Done building project "libid.vcxproj" -- FAILED.
10>------ Build started: Project: test-id, Configuration: Debug x64 ------
11>------ Build started: Project: id, Configuration: Debug x64 ------
11>LINK : fatal error LNK1104: cannot open file '..\libid\Debug\libid.lib'
10>LINK : fatal error LNK1104: cannot open file '....\libid\Debug\libid.lib'
11>Done building project "id.vcxproj" -- FAILED.
10>Done building project "test-id.vcxproj" -- FAILED.
12>------ Skipped Build: Project: INSTALL, Configuration: Debug x64 ------
12>Project not selected to build for this solution configuration
========== Build: 1 succeeded, 3 failed, 20 up-to-date, 8 skipped ==========
========== Build completed at 9:09 PM and took 03.539 seconds ==========

[LegalizeAdulthood]

These are all calls to the libfmt library, but everything is working properly on master, both for me and for github CI, so my conclusion is that you have some changes in your local workspace. Do you have changes on those files? What does git status report?

[PaulTheLionHeart]

When I pulled down Master, there was a conflict with FPU087.cpp and it was only a comment. But I couldn't get it to resolve. This has been an ongoing problem for me when I try to merge. So I simply created another branch and everything looked okay. the CMake --preset wx worked fine and I was able to find the MS VC++ solution file okay. Everything looked okay until I did the build.

[LegalizeAdulthood]

I'm not sure what you mean by 'created another branch'; you should be attempting to build master, not a branch.

When you make a branch, the branch is now detached from any updates on master.

[PaulTheLionHeart]

When I pull master down I get a conflict. The only way I can see to resolve it is to delete my whole repository and start again. I simply can't get my head around solving conflicts in GIT.

[PaulTheLionHeart]

I'm lost! How do I get myself out of this mess without blowing my whole Id entry away and starting again?

Microsoft Windows [Version 10.0.19045.6216]
(c) Microsoft Corporation. All rights reserved.

C:\Users\Paul>cd \github\id\iterated-dynamics

C:\Github\id\iterated-dynamics>git checkout master
libid/math/fpu087.cpp: needs merge
error: you need to resolve your current index first

C:\Github\id\iterated-dynamics>git rebase master
libid/math/fpu087.cpp: needs merge
error: cannot rebase: You have unstaged changes.
error: additionally, your index contains uncommitted changes.
error: Please commit or stash them.

[LegalizeAdulthood]

We should probably find a time to get together on the fractal chats discord and do an audio call with screen share to sort this out.

[PaulTheLionHeart]

Great idea. I am available 11 am my time on Friday. That should be Thursday evening for you. The time here is 1:20 PM Wednesday. Hopefully we can work out a suitable time from this.

[LegalizeAdulthood]

Assuming you are in Canberra (AEST) time zone, that would be 7pm my time which is fine with me.

[PaulTheLionHeart]

Great, I'll see you in just over 2 hours time.

[PaulTheLionHeart]

I'm still trying to log into Discord on my PC

[PaulTheLionHeart]

Hi Richard,

Many thanks for today. It was great working together in real time.

Unfortunately, when my laptop locked up, I lost all the logs from the command prompt. It's a real pity as I wanted to review them for learning about what happened.

Also, I tried to setup wxWidgets and got the same failure as before:

C:\Github\id\iterated-dynamics>cmake --preset wx
Preset CMake variables:

CMAKE_TOOLCHAIN_FILE:FILEPATH="C:/Github/id/iterated-dynamics/vcpkg/scripts/buildsystems/vcpkg.cmake"
ID_PROJECT_NAME:STRING="Iterated Dynamics wx"
ID_USE_WX:BOOL="TRUE"
VCPKG_MANIFEST_FEATURES="wx"

CMake Error at C:/Github/id/build-wx/CMakeFiles/3.29.0-rc4/CMakeSystem.cmake:6 (include):
include could not find requested file:

C:/Github/id/iterated-dynamics/vcpkg/scripts/buildsystems/vcpkg.cmake

Call Stack (most recent call first):
CMakeLists.txt:31 (project)

-- Selecting Windows SDK version 10.0.22621.0 to target Windows 10.0.19045.
CMake Warning at packaging/CMakeLists.txt:6 (message):
Could not find the WiX executables needed to build an installer; skipping
packaging.

-- Configuring incomplete, errors occurred!

C:\Github\id\iterated-dynamics>

[LegalizeAdulthood]

when we cloned the repository we didn't set up the git submodules; you should be able to get going again with these commands:

git submodule init
git submodule update

this will setup the vcpkg submodule so you can obtain dependencies.

[PaulTheLionHeart]

Great Thanks. By the way, we can still restore all the deleted repositories if we want to. I do a weekly backup of the C:\ drive where Github is located. However, it might be just as good to start with a clean slate.

[LegalizeAdulthood]

Your call, if you restore it from backup you'll need to clean it up again :)

[PaulTheLionHeart]

The trade-off is that I can learn from all the mistakes I made in the past vs having a clean slate to learn from. Hmmmm. I'm sure I will still learn lots and it is good to have a "clean" repository. So let's leave it. I think it will be more productive to learn to merge the outstanding pull requests. Also Id will then be more perturbation-focused :)

[LegalizeAdulthood]

Things have been a little slow lately and I've just been doing some mechanical code cleanups in my IDE. However, my September distractions are nearly over (going on a small trip this weekend) and I hope to get back on track to getting a full wxWidgets version working.

[PaulTheLionHeart]

It will be good to get back into Id. I have been obsessed with getting BLA integrated into ManpWIN. I'll have to update my repository so you can try BLA for yourself using it.he beauty is that perturbatio9n+BLA is almost independent of iteration count and depth of zoom. It is staggering how fast it can be.