convert Cbdesign to wxWidgets AUI

[wsu-cb]

This PR is ready to be applied as-is (I hope), but I currently have this marked as draft while I see if I can fix wxWidgets/wxWidgets#25219 and remove the kludge in this PR to work around that problem.

[DLLarson]

Dang! I totally missed this PR! I just saw it in my notifications.

I'll get to it real soon.

-Dale

[DLLarson]

I'm nearly done looking through the code. But I'm having difficulty building it using the batch file. When the Ninja step is executed it fails to find the compiler and aborts. I can't find any obvious reason why.

D:\Dev\CBoard\G\cbwindows>build-all-configs.bat

D:\Dev\CBoard\G\cbwindows>echo on

D:\Dev\CBoard\G\cbwindows>rem change the following if your Visual Studio is installed somewhere else.

D:\Dev\CBoard\G\cbwindows>set VSROOTDIR="C:\Program Files\Microsoft Visual Studio"

D:\Dev\CBoard\G\cbwindows>rem execute in bat's directory

D:\Dev\CBoard\G\cbwindows>pushd D:\Dev\CBoard\G\cbwindows\

D:\Dev\CBoard\G\cbwindows>call "C:\Program Files\Microsoft Visual Studio""\2022\Community\VC\Auxiliary\Build\vcvars64.bat"
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.13.6
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

D:\Dev\CBoard\G\cbwindows>rem The build can't find the toolchain due to undefined directory in

D:\Dev\CBoard\G\cbwindows>set VCToolsRedistDir=C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.43.34808\

D:\Dev\CBoard\G\cbwindows>cmake -G Ninja -B out/build/x64-Debug -DCMAKE_BUILD_TYPE=Debug
CMake Deprecation Warning at CMakeLists.txt:3 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:11 (project):
  The CMAKE_CXX_COMPILER:

    C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.42.34433/bin/Hostx64/x64/cl.exe

  is not a full path to an existing compiler tool.

  Tell CMake where to find the compiler by setting either the environment
  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
  to the compiler, or to the compiler name if it is in the PATH.


-- Configuring incomplete, errors occurred!

D:\Dev\CBoard\G\cbwindows>if errorlevel 1 goto fail_cmake

D:\Dev\CBoard\G\cbwindows>echo cmake failed
cmake failed

D:\Dev\CBoard\G\cbwindows>goto done

D:\Dev\CBoard\G\cbwindows>popd

D:\Dev\CBoard\G\cbwindows>

I did a repair to the VS 2022 environment thinking something was borked but that had no effect. Is the build environment working for you? My CMake is version 3.29.2. Do you think that could have something to do with it?

I should also point out that I updated the VS 2022 install when VS said my version was not current. I didn't attempt a batch CB build until the update was done so I don't know if my old environment would've worked.

-Dale

[DLLarson]

I'm done reviewing the code. As usual, there isn't any real issue other than I can't build it (plus a side question I had.)

This PR looks to take the big leap of switching from MFC's docking framework to wxWidgets' framework. Correct?

-Dale

[wsu-cb]

This PR looks to take the big leap of switching from MFC's docking framework to wxWidgets' framework. Correct?

-Dale

I feel like I'm misunderstanding what you're asking because I think the title of this PR says that's what it does...

[wsu-cb]

I did a repair to the VS 2022 environment thinking something was borked but that had no effect. Is the build environment working for you? My CMake is version 3.29.2. Do you think that could have something to do with it?

I just successfully ran the build-all script with VS 2022 17.12.5 (cmake 3.29.5-msvc4). I then upgraded to VS 2022 17.13.6 (cmake 3.30.5-msvc23), and was again able to successfully run the build-all script.

Have you deleted the out directory and opened a brand new command line to perform a completely clean build?

[DLLarson]

This PR looks to take the big leap of switching from MFC's docking framework to wxWidgets' framework. Correct?
-Dale

I feel like I'm misunderstanding what you're asking because I think the title of this PR says that's what it does...

Yeah... I missed that. I worry about my brain sometimes as I just hit 70. Sorry about the confusion.

[DLLarson]

Have you deleted the out directory and opened a brand new command line to perform a completely clean build?

That was the problem. Thanks for clearing that up.

Like I said in a related post... I'm beginning to get concerned about my noggin. The first thing I should've done is clean out the environment. I usually remember to wipe the wxWidgets stuff and reload the submodules. But missed on clearing out the rest.

[DLLarson]

I've built the code and I see the newer AUI stuff in action.

It's a huge accomplishment!

I know this is the first PR integrating the new docking framework so it's going to have some issues. You may have seen some but here's what I experienced...

1. The AUI doesn't seen to provide any "tracking" style feed back for splitters.
2. Moving or changing the layout when a board editor windows is active is very sluggish. I was using the POG 2.1.gbx to test. When I'm on the project or tile editor window it is very snappy.
3. Palette windows like the color palette don't seem to constrain the minimum size of the docking target to the minimum size of the palette. I can squish it out of view.
4. Sometimes when I move the color palette to a new dock area containing a tile palette (for instance) it divides the area in half when I'm expecting the color palette to only consume the size it requires. Other times it seems to remember its size.

I'm ready to merge this if you are.

-Dale

[wsu-cb]

That was the problem. Thanks for clearing that up.

Like I said in a related post... I'm beginning to get concerned about my noggin. The first thing I should've done is clean out the environment. I usually remember to wipe the wxWidgets stuff and reload the submodules. But missed on clearing out the rest.

Good to hear you can build. Not so good to hear you're concerned about your mental acuity.

[wsu-cb]

I'm ready to merge this if you are.

-Dale

I would hold off a little while. Let me see if I can nudge the wxWidgets team about my proposed solution to wxWidgets/wxWidgets#25219, and also take a look at the issues you observed. I have some hope of getting 25219 fixed. I'm considerably more dubious about fixing the issues you found, but let me at least look at them.

[DLLarson]

Not so good to hear you're concerned about your mental acuity.

Like the Rolling Stones sang... "What a drag it is getting old...". Seeing friends and neighbors of similar age die off really sucks. The 50th High School reunion was an eye opener.

[DLLarson]

also take a look at the issues you observed

Item (2) was the really strange one. I even attached to the CBDesign process with the debugger to get logging output thinking it was sluggish due to excessive debug messages. No joy. It was pretty much quiet after start up. I didn't see CPU spikes either.

[wsu-cb]

1. The AUI doesn't seen to provide any "tracking" style feed back for splitters.

Is this in reference to the Tile Editor splitter window? I DO see a dark gray rectangle when I drag the splitter divider there. If you set a breakpoint on ...\deps\wxWidgets\include\wx\generic\private\drawresize.h (inline) function wxDrawOverlayResizeHint(), does dragging the divider hit that function?

I checked just now, and if I set my Display scale to 125%, the tracker is still visible, so this does NOT seem to be a HiDPI issue.

Also, if you run the wxWidgets splitter sample, and use the menu to disable Live Update, do you get no tracker there as well? If that shows no tracker, then maybe I should just switch our code to use Live Update rather than fight with graphics display inconsistencies.

[wsu-cb]

3. Palette windows like the color palette don't seem to constrain the minimum size of the docking target to the minimum size of the palette. I can squish it out of view.

I couldn't completely squash the color palette out of view, but I could certainly make it so small that only the X (Close) button was visible. (Unless that's what you mean, since only the frame of the palette is visible, not the actual client area.) I have pushed a commit to make the color palette minimum size match its best size. It seems like wxWidgets does respect the minimum size, even though it does not appear to respect the maximum size setting. However, while the color palette has a clear "best size" that I can use as its minimum, it's not clear to me what to use as the minimum size for the tile palette.

[wsu-cb]

4. Sometimes when I move the color palette to a new dock area containing a tile palette (for instance) it divides the area in half when I'm expecting the color palette to only consume the size it requires. Other times it seems to remember its size.

I have no idea what to do about this. I have already given the color palette a maximum size (which is considerably less than half the typical area height), but, as noted in reference to 3., wxWidgets just doesn't seem to respect the maximum size setting, and the initial size is half the docking area. I don't have any code to preserve sizes across closing/opening the process, so it always reverts to the half-docking-area size on startup. (Preserving window layout is probably a far-in-the-future enhancement.)

Within a single process instance, I don't think I have seen the color palette increase to half the dock size once it has been shrunk, but (before I made its minimum size equal to the best size), I have seen wxWidgets increase its size to the best size in some cases. That does make me wonder if maybe I should have made the color palette minimum size be half the best width and half the best height, but I'm inclined to say that if the user is space constrained, he should just close the palette rather than shrink it.

[DLLarson]

Is this in reference to the Tile Editor splitter window? I DO see a dark gray rectangle when I drag the splitter divider there. If you set a breakpoint on ...\deps\wxWidgets\include\wx\generic\private\drawresize.h (inline) function wxDrawOverlayResizeHint(), does dragging the divider hit that function?

I don't see the dark grey rectangle. Plus the breakpoint isn't hit:

I tried the splitter in the tile and board editor. I think the reason I notice it so much in the board editor is the sluggishness. I move the splitter and the graphics lag behind.

On the Tile Editor the repaints are so fast the panes all seem to track.

if you run the wxWidgets splitter sample, and use the menu to disable Live Update,

I'll let you know later. I have to figure out how to build it. If you have a simple command line way to build it off hand I'll take it!

-Dale

[wsu-cb]

I tried the splitter in the tile and board editor. I think the reason I notice it so much in the board editor is the sluggishness. I move the splitter and the graphics lag behind.

I don't see a splitter in the board editor, only in the tile editor. When referring to the splitter in the board editor, do you mean the division between the board editor and the docking area? If that's what you are referring to, then resizing the docking area is using Live Update, and does not use wxDrawOverlayResizeHint(). The splitter in the tile editor between the tile size selector and the zoomed tile is the one that shows the tracking rectangle.

On the Tile Editor the repaints are so fast the panes all seem to track.

if you run the wxWidgets splitter sample, and use the menu to disable Live Update,

I'll let you know later. I have to figure out how to build it. If have a simple command line way to build it off hand I'll take it!

Edit ...\deps\wxWidgets\build\cmake\samples\CMakeLists.txt so that the wx_add_sample(splitter line becomes wx_add_sample(splitter DEPENDS wxUSE_SPLITTER IMPORTANT). Then run the standard build. That should create .../out/build/x64-Debug/deps/wxWidgets/lib/vc_x64_lib/splitter.exe.

[DLLarson]

When referring to the splitter in the board editor, do you mean the division between the board editor and the docking area?

Yes. That's the splitter I meant.

[wsu-cb]

When referring to the splitter in the board editor, do you mean the division between the board editor and the docking area?

Yes. That's the splitter I meant.

So then I would expect no tracker, but rather immediate resize.

[wsu-cb]

I don't understand why the first two runs of the check jobs failed, but the third succeeded.

[DLLarson]

Then run the standard build. That should create .../out/build/x64-Debug/deps/wxWidgets/lib/vc_x64_lib/splitter.exe.

I didn't get the sample.exe even though it did create the obj.

I also deleted the out folder to do a full build with the same result.

-Dale

[wsu-cb]

Then run the standard build. That should create .../out/build/x64-Debug/deps/wxWidgets/lib/vc_x64_lib/splitter.exe.

I didn't get the sample.exe even though it did create the obj.

Based on where those .objs are, I think they are from deps/wxWidgets/src/generic/splitter.cpp, which is the implementation of the splitter window (which is necessary, but not sufficient), rather than deps/wxWidgets/samples/splitter/splitter.cpp, which is the sample. However, I can't explain why you didn't also get the sample.

[DLLarson]

Unless that's what you mean, since only the frame of the palette is visible, not the actual client area.)

Yes. That's want occurred. I shouldn't use absolute statements when squishy ones are more appropriate.

it's not clear to me what to use as the minimum size for the tile palette.

That one is tougher. Probably a min height the shows at least the drop down box. and a width that also shows some portion of the drop down combo box.

[DLLarson]

Within a single process instance, I don't think I have seen the color palette increase to half the dock size once it has been shrunk, but (before I made its minimum size equal to the best size), I have seen wxWidgets increase its size to the best size in some cases. That does make me wonder if maybe I should have made the color palette minimum size be half the best width and half the best height, but I'm inclined to say that if the user is space constrained, he should just close the palette rather than shrink it.

The docking stuff in windows was very tricky to work with too. Perhaps over time it will reveal more of itself. I see that the wxAUI stuff was a commercial product developed for a data analysis app:

https://www.kirix.com/labs/wxaui.html

The app's source code is available and could provide some insights into how the framework is used for some edgy cases:

https://github.com/kirixresearch/strata

They have a prebuilt version of the application on the web site:

https://www.kirix.com/strata/download

Interestingly when I move a splitter it draws the tracking image in the wrong place. I don't think it has any of the code that influence rendering for HiDPI platforms. The final copyright year is 2022 in its about box so perhaps it has been improved in the source repository. There have been many commits for it since 2022.

-Dale

[DLLarson]

I don't understand why the first two runs of the check jobs failed, but the third succeeded.

It's a mystery to me as well. I remember looking into workflow build failures a long time ago and it was related to timing issues on GitHub's part. But I'm not sure anymore.

I found the failure logs and it show this:

[1326/1504] Building RC object GP\CMakeFiles\CBPlay.dir\Cbplay.rc.res
FAILED: GP/CMakeFiles/CBPlay.dir/Cbplay.rc.res 
C:/PROGRA~1/CMake/bin/cmcldeps.exe RC D:\a\cbwindows\cbwindows\GP\Cbplay.rc GP\CMakeFiles\CBPlay.dir\Cbplay.rc.res.d GP\CMakeFiles\CBPlay.dir\Cbplay.rc.res "Note: including file: " "C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.43.34808/bin/Hostx64/x64/cl.exe" C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x64\rc.exe -DGPLAY -DUNICODE -D_AFX_SECURE_NO_WARNINGS -D_ATL_SECURE_NO_WARNINGS -D_CRTDBG_MAP_ALLOC -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_WARNINGS -D_DEBUG -D_UNICODE -D__WXMSW__ -I D:\a\cbwindows\cbwindows\GP\. -I D:\a\cbwindows\cbwindows\GP\..\GShr -I "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.43.34808\atlmfc\src\mfc" -I D:\a\cbwindows\cbwindows\out\build\x64-Debug\deps\wxWidgets\lib\vc_x64_lib\mswud -I D:\a\cbwindows\cbwindows\deps\wxWidgets\include -DWIN32 -D_DEBUG /fo GP\CMakeFiles\CBPlay.dir\Cbplay.rc.res D:\a\cbwindows\cbwindows\GP\Cbplay.rc
Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384

Copyright (C) Microsoft Corporation.  All rights reserved.

D:\a\cbwindows\cbwindows\GP\Cbplay.rc(3) : fatal error RC1015: cannot open include file 'resource.h'.

[1327/1504] Building RC object GM\CMakeFiles\CBDesign.dir\Cbdesign.rc.res
FAILED: GM/CMakeFiles/CBDesign.dir/Cbdesign.rc.res 
C:/PROGRA~1/CMake/bin/cmcldeps.exe RC D:\a\cbwindows\cbwindows\GM\Cbdesign.rc GM\CMakeFiles\CBDesign.dir\Cbdesign.rc.res.d GM\CMakeFiles\CBDesign.dir\Cbdesign.rc.res "Note: including file: " "C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.43.34808/bin/Hostx64/x64/cl.exe" C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x64\rc.exe -DUNICODE -D_AFX_SECURE_NO_WARNINGS -D_ATL_SECURE_NO_WARNINGS -D_CRTDBG_MAP_ALLOC -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_WARNINGS -D_DEBUG -D_UNICODE -D__WXMSW__ -I D:\a\cbwindows\cbwindows\GM\. -I D:\a\cbwindows\cbwindows\GM\..\GShr -I D:\a\cbwindows\cbwindows\out\build\x64-Debug\deps\wxWidgets\lib\vc_x64_lib\mswud -I D:\a\cbwindows\cbwindows\deps\wxWidgets\include -DWIN32 -D_DEBUG /fo GM\CMakeFiles\CBDesign.dir\Cbdesign.rc.res D:\a\cbwindows\cbwindows\GM\Cbdesign.rc
Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384

Copyright (C) Microsoft Corporation.  All rights reserved.

D:\a\cbwindows\cbwindows\GM\Cbdesign.rc(3) : fatal error RC1015: cannot open include file 'resource.h'.

[wsu-cb]

Then run the standard build. That should create .../out/build/x64-Debug/deps/wxWidgets/lib/vc_x64_lib/splitter.exe.

I didn't get the sample.exe even though it did create the obj.

Based on where those .objs are, I think they are from deps/wxWidgets/src/generic/splitter.cpp, which is the implementation of the splitter window (which is necessary, but not sufficient), rather than deps/wxWidgets/samples/splitter/splitter.cpp, which is the sample. However, I can't explain why you didn't also get the sample.

After running the sample build, run cmake --build out/build/x64-Debug -t splitter. I think that will get you the sample, but I will have to do more digging to figure out how to get the samples to build as part of the default target.

[wsu-cb]

I don't understand why the first two runs of the check jobs failed, but the third succeeded.

It's a mystery to me as well. I remember looking into workflow build failures a long time ago and it was related to timing issues on GitHub's part. But I'm not sure anymore.

I found the failure logs and it show this:

I saw that logs said the failed builds couldn't find */resource.h, but that didn't explain to me why the first two runs couldn't find */resource.h, and yet the third run could.

[DLLarson]

cmake --build out/build/x64-Debug -t splitter

This gave me an error if I just ran it after the batch file finished. It did work if I added various targets of this command to the batch file. Now I have four different splitter.exe's.

I can see the two different modes of using the splitter with Live Update being the most aggressive.

If the sluggishness is due to constant repainting of the board image we may have to default to non-Live Update.

The sluggishness is quite pronounced on my beast of a gaming rig so it's gonna be a lot worse on a normal PC. My machine has an i9-14900KS (24 hard cores, 32 soft cores), 64 GB of RAM and a screaming RTX 4080 Super nVidia GPU. It's not slow and can easily handle most 3D games out there.

Perhaps some profiling would reveal the root cause of issue.

-Dale

[wsu-cb]

wxWidgets has accepted my fix for wxWidgets/wxWidgets#25219, so I have updated the submodule and removed the work-around. I have also improved the palette minimum sizes.

So this PR is ready now.

[DLLarson]

Fantastic! I guess you're now part of the wxWidgets team.

I'll look at it this weekend.

-Dale

[DLLarson]

I finished looking at the changed code. It looks fine to me. The build worked fine as well.

The dock sizing is much improved! I only had one odd thing where when I detached the color palette from the dock so it would float, the window was bigger that the min size of the palette:

I shrank it down to fit the actual size and redocked it. All times after that it worked how I expected (what I was used to in the MFC version).

The Pog board repaints still make the splitter sluggish but that I expected. We'll see how this improves once the bitmaps are not converted from their MFC origins.

I'll merge when you give the final OK.

-Dale

[wsu-cb]

I'll merge when you give the final OK.

I did not overlook or forget your message; the problem is I currently have very mixed feelings. In addition to the floating palette size issue you noticed, I have found two other problems, one with the File MRU list, and another with Ctrl-Tab active window switching, I have been trying to fix all of those before merging this, but all of them have proven to require some effort. On the one hand, it would be nice to get this merged into master, but on the other hand, I like to avoid the noise of bug fixes in the master history.

I think I would still wait to merge this until I can fix some more bugs, but the current state could certainly be merged if you (or, to be ridiculously optimistic, someone else) want to do some development work based on this,

[DLLarson]

Hi Bill,

I have been trying to fix all of those before merging this, but all of them have proven to require some effort. On the one hand, it would be nice to get this merged into master, but on the other hand, I like to avoid the noise of bug fixes in the master history.

Since nothing is perfect and bug free I think it's OK to merge the current work and fix the bug(s) in other PR(s). Otherwise the original PR starts getting diluted with efforts not related to the original PR intent. Of course if the code doesn't work without the fixes then they should be fixed or worked around.

As time goes on I imagine we'll run into additional aberrations as more of the code is transferred to wxWidget clean implementation. If the side bugs can be easily dealt with then just fix them. If it's something that's a bigger problem and a show stopper then it should be fixed as part of the PR.

Otherwise, the "bugs" can be dealt with on their own PR in a more focused effort.

At least this is the way I see it. Jumping down a rabbit hole for a cosmetic bug (rather than a foundational bug) just hurts progress velocity when later you may gain some new insights that more easily address the problem.

But I'm not in a good position to judge the specifics. I trust you for that assessment because you're deep into the code.

-Dale

[DLLarson]

Hi Bill,

Just checking in to see if I'm supposed to merge this.

-Dale

[wsu-cb]

Just checking in to see if I'm supposed to merge this.

I'm still working on getting wxWidgets updates accepted as part of fixing some things here, but it's taking long enough that I suppose you should merge this.