Feature: wxWidgets-based editors.

[ashalkhakov]

• trying my hand at migrating from MFC to wxWidgets
• PDA editor ported
• Windows-only for now, but cross-platform support is definitely planned
• need to manually export fbp (wxFormBuilder project) to xrc file, and then manually invoke wxrc /c --output PDAEditor_xmlresource.cpp PDAEditor.xrc
• not sure if CMakePresets.json are needed
• no idea what is doom.aps

Here's the result so far, editPDAs using the new dialog:

[DanielGibson]

Interesting! :)

I converted it to a draft PR because it obviously is still pretty far from ready.
Without looking at the source closer:

• It should build on all platforms, of course
• It should be possible to disable it on build, so dhewm3 can be built without tools (and thus without wxwidgets dependency), like it's currently the case with the MFC-based tools
• I don't think CMakePresets.json is needed, I think that's just something that Visual Studio creates to remember what arguments to pass to CMake when generating a solution, or something like that

• need to manually export fbp (wxFormBuilder project) to xrc file, and then manually invoke wxrc /c --output PDAEditor_xmlresource.cpp PDAEditor.xrc

  • Can't this be done by CMake?
• Would be good to figure out what doom.aps is and where it comes from (and thus if it needs to be in the repo or is just generated by fbp or whatever)
• Would be nice to have the more interesting editors ported as well ;)

[DanielGibson]

BTW, out of interest, why wxWidgets and not another crossplatform toolkit (like Qt or Dear ImGui)?

[FriskTheFallenHuman]

BTW, out of interest, why wxWidgets and not another crossplatform toolkit (like Qt or Dear ImGui)?

if i have to guess is because its almost like MFC in terms of usage, and there is an official guide that gives a step by step tips to migrate from MFC to wxWidgets (QT has this buts is like an abandone project from 14 years ago

[ashalkhakov]

BTW, out of interest, why wxWidgets and not another crossplatform toolkit (like Qt or Dear ImGui)?

if i have to guess is because its almost like MFC in terms of usage, and there is an official guide that gives a step by step tips to migrate from MFC to wxWidgets (QT has this buts is like an abandone project from 14 years ago

Indeed, I found a very detailed guide on porting from MFC to wxWidgets. I also have some experience with WPF and Avalonia, but they would be difficult to use with the current architecture. I was thinking about ImGui too but it's probably going to need more restructuring? I have no experience with immediate UIs.

[ashalkhakov]

Interesting! :)

I converted it to a draft PR because it obviously is still pretty far from ready. Without looking at the source closer:

Thanks! Just wanted to get a quick feedback.

* It should build on all platforms, of course

I can test it on Windows & Linux. I have an older Mac too, but I want to start with the Windows side, and the move on from there. Is this a reasonable approach? I don't have much experience setting up Mac for development.

* It should be possible to disable it on build, so dhewm3 can be built without tools (and thus without wxwidgets dependency), like it's currently the case with the MFC-based tools

What is AROS? I got confused there. I wanted to add wxWidgets code as a separate library, and then it could be linked into the executable. I think that as I move forward, I'll have less and less MFC code, and more wxWidgets code, so in the end things should become much simpler to port to Linux & Mac.

* I don't think CMakePresets.json is needed, I think that's just something that Visual Studio creates to remember what arguments to pass to CMake when generating a solution, or something like that

Thanks. I'll remove it. I had a lot of issues trying to integrate wxWidgets into the engine (the FindWxWidgets macro is trying to hijack CXX flags for some reason!). The other approach would be to compile it from source.

* > need to manually export fbp (wxFormBuilder project) to xrc file, and then manually invoke wxrc /c --output PDAEditor_xmlresource.cpp PDAEditor.xrc
  
  
  
  * Can't this be done by CMake?

It could be I think. I didn't come around a sample though, so just left it as-is for now.

* Would be good to figure out what doom.aps is and where it comes from (and thus if it needs to be in the repo or is just generated by fbp or whatever)

* Would be nice to have the more interesting editors ported as well ;)

What are the more interesting editors? I'm currently going over the script editor. I'm trying to go roughly in the order of smaller to larger effort.

[FriskTheFallenHuman]

What are the more interesting editors? I'm currently going over the script editor. I'm trying to go roughly in the order of smaller to larger effort.

• LigthEditor
• SoundEditor
• AFEditor
• DeclEditor
• ParticleEditor

other interesting ones is

• DoomEdit (this is the biggest one since its a bit of a mess)
• GuiEdit
• MaterialEdit
  and Probably the ScriptDebugger

[DanielGibson]

Ok, I didn't know of such a guide, I only saw https://wiki.wxwidgets.org/WxWidgets_For_MFC_Programmers which seems to give some general suggestions (and links some IBM tutorial that's not available anymore).

I wonder how similar MFC and Wx really are, because looking at the diff, it still seems to require lots of changes to the code.

ImGui is also different from MFC, but IMO it's pretty simple to use. Ages ago I ported the Light Editor to Dear ImGui in a Doom 3 BFG-based project: https://github.com/OpenTechEngine/OpenTechBFG/blob/master/neo/tools/editors/LightEditor.cpp
RBDoom3BFG has an updated version of that (and also the AfEditor): https://github.com/RobertBeckebans/RBDOOM-3-BFG/tree/master/neo/tools/imgui

Anyway, while Dear ImGui clearly is different from MFC, I didn't have to completely rewrite the code. The code that uses MFC of course had to change, but the helper functions and classes (like LightInfo) only needed small adjustments, and of course the code interacting with the engine and its types (idVec3, idDict, idEntity, the idEditEntities interface) also stayed pretty much the same.
Most of the MFC code (all those OnFoo functions, the message map, etc) has been replaced with this function:
https://github.com/OpenTechEngine/OpenTechBFG/blob/51b5c6408b3b9d735a41e6df133c665013aae812/neo/tools/editors/LightEditor.cpp#L469-L616

[DanielGibson]

I can test it on Windows & Linux. I have an older Mac too, but I want to start with the Windows side, and the move on from there. Is this a reasonable approach? I don't have much experience setting up Mac for development.

That's ok, I don't have a Mac either. The automated builds from Github at least tell us if it still compiles, and if it works on Windows and Linux that should be a good enough start.

What is AROS?

Some obscure operating system, don't worry about it

I wanted to add wxWidgets code as a separate library, and then it could be linked into the executable. I think that as I move forward, I'll have less and less MFC code, and more wxWidgets code, so in the end things should become much simpler to port to Linux & Mac.

Sounds generally sensible, it would just be nice if there was a CMake option like WX_TOOLS (like there is currently TOOLS for the MFC-based tools) that allows building dhewm3 without any dependency on wxWidgets, for people who just wanna play and not use the tools, and also for platforms where building for wxWidgets is too hard (like potentially AROS).

[ashalkhakov]

@FriskTheFallenHuman Thanks for the heads-up!

@DanielGibson

Ok, I didn't know of such a guide, I only saw https://wiki.wxwidgets.org/WxWidgets_For_MFC_Programmers which seems to give some general suggestions (and links some IBM tutorial that's not available anymore).

I was talking about this and there's this talk by the same author.

ImGui is also different from MFC, but IMO it's pretty simple to use. Ages ago I ported the Light Editor to Dear ImGui in a Doom 3 BFG-based project: https://github.com/OpenTechEngine/OpenTechBFG/blob/master/neo/tools/editors/LightEditor.cpp RBDoom3BFG has an updated version of that (and also the AfEditor): https://github.com/RobertBeckebans/RBDOOM-3-BFG/tree/master/neo/tools/imgui

Didn't know about this and thank you for bringing this up. In the end I just want the live coding ability for Dhewm 3 on my Linux box, ImGui would also work.

The other thing we could try is separate out the UI part. The engine would expose some API (e.g. JSON-RPC), and it could react to commands sent by editors. Thoughts?

Anyway, while Dear ImGui clearly is different from MFC, I didn't have to completely rewrite the code. The code that uses MFC of course had to change, but the helper functions and classes (like LightInfo) only needed small adjustments, and of course the code interacting with the engine and its types (idVec3, idDict, idEntity, the idEditEntities interface) also stayed pretty much the same. Most of the MFC code (all those OnFoo functions, the message map, etc) has been replaced with this function: https://github.com/OpenTechEngine/OpenTechBFG/blob/51b5c6408b3b9d735a41e6df133c665013aae812/neo/tools/editors/LightEditor.cpp#L469-L616

I'll try porting to ImGui, it's very light-weight. The only thing it's lacking is a source code editor: I wanted to have the ability to live code the scripts, seems like we'll have to use Scintilla for instance, or some such, or leave code editing to a separate tool.

[DanielGibson]

just a quick note about source code editor: there are third-party solutions for ImGui, for example https://github.com/BalazsJako/ImGuiColorTextEdit
(I think @FriskTheFallenHuman has some experience with that one)

[DanielGibson]

The other thing we could try is separate out the UI part. The engine would expose some API (e.g. JSON-RPC), and it could react to commands sent by editors. Thoughts?

I don't really like it TBH.
For the simplest tools (like the PDA editor) it might work, but even the light editor requires displaying a texture, which would require to either duplicate lots of code into the UI part (so it can load game data) or to send pictures over RPC.
It would also make the code more complicated and for each change you'd have to adjust both the external UI part and dhewm3 itself.

I'll try porting to ImGui

Thanks! :)

To support that I will start porting the light editor (and for that provide the general infrastructure to open ImGui editor/tool windows) today, maybe based on my imgui-docking branch. That branch uses the "docking" version of Dear ImGui, which (among other things) allows dragging ImGui windows (that usually are just rendered within dhewm3s window) out of the dhewm3 window, so they turn into separate windows. It's almost like magic ;)
(Only disadvantage: That feature doesn't work with Wayland, because Wayland doesn't allow specifying where to place a newly created window. Maybe one day it will, but until then it I think it should work fine with XWayland, and it generally works on Windows and Mac and maybe other systems). ocornut/imgui#2109 has some videos of the docking branch in action

[ashalkhakov]

The other thing we could try is separate out the UI part. The engine would expose some API (e.g. JSON-RPC), and it could react to commands sent by editors. Thoughts?

I don't really like it TBH. For the simplest tools (like the PDA editor) it might work, but even the light editor requires displaying a texture, which would require to either duplicate lots of code into the UI part (so it can load game data) or to send pictures over RPC. It would also make the code more complicated and for each change you'd have to adjust both the external UI part and dhewm3 itself.

Point taken.

I'll try porting to ImGui

Thanks! :)

To support that I will start porting the light editor (and for that provide the general infrastructure to open ImGui editor/tool windows) today, maybe based on my imgui-docking branch. That branch uses the "docking" version of Dear ImGui, which (among other things) allows dragging ImGui windows (that usually are just rendered within dhewm3s window) out of the dhewm3 window, so they turn into separate windows. It's almost like magic ;) (Only disadvantage: That feature doesn't work with Wayland, because Wayland doesn't allow specifying where to place a newly created window. Maybe one day it will, but until then it I think it should work fine with XWayland, and it generally works on Windows and Mac and maybe other systems). ocornut/imgui#2109 has some videos of the docking branch in action

Great! I'll keep my branch against master for now, just to get the ball rolling, and we could coordinate this further when I submit a new PR with the proposed changes.

[DanielGibson]

Great! I'll keep my branch against master for now, just to get the ball rolling, and we could coordinate this further when I submit a new PR with the proposed changes.

Wow that was a fast reply :D

See the update in my previous comment, I'd suggest starting with a ImGui sample application because it allows for faster iteration :)
And if you meant the ImGui master branch: Sure, makes sense, moving code to the docking branch later is simple anyway, it needs very little changes because ImGui does almost all of the heavy lifting!

[DanielGibson]

Ok, due to hitting a bug in the ImGui docking branch (it's fixed upstream now) this took a bit longer than expected, but here is my imgui-tools branch integrating the Light Editor:
https://github.com/DanielGibson/dhewm3/tree/imgui-tools
It's still a bit unfinished and hacky, the light editor probably only works properly if the MFC tools are disabled. It's used by starting a level, setting g_editEntityMode 1 and shooting at a light.

My imgui-docking branch is also updated (force-pushed) to that latest imgui code.

[ashalkhakov]

@DanielGibson Thanks a ton! I'm almost done with the Dear Imgui version. I want to polish a few things before submitting a new PR.

A few things I don't understand how to do properly:

• How to plug it into the engine loop (worked around it ATM, will need to take a look at the imgui-tools branch-- thanks!)
• How to handle modal dialogs (would be very nice to keep the existing structure i.e. classes in place, to make testing easier)

A few things that would be good to have, but not critical:

• layout (everything is done via fixed layout ATM)

[ashalkhakov]

Closing in favor of #649.