nikitalita
commented
1 year ago Agreed, this is on the list. The GUI being implemented in the C++ module is the biggest reason why I haven't done too much with the GUI so far, as it makes iterative design a pain. The main reason that the GUI was written in C++ in the first place is so that the decompilation and resource conversion functionality would be available in the editor as well. This is of limited use now that full project recovery is implemented, and I don't think anyone actually uses it anymore, so stripping it out (entirely or partially) and replacing it with a gd + tscn implementation would be fine.
The biggest challenge here is going to be working around how resource loading works. Currently, whenever a PCK is loaded for project recovery, we remove the pack source (that has the GDRE pck loaded), create a new pack source, and then load the target pack source; when we're done recovering, we create another pack source and reload the GDRE pck. This means that the GDRE resources won't actually be on the res:// path during PCK loading and project recovery. This can probably be worked around, but it will require some design caveats, such as preloading all the gd/tscn files on initial load and making sure to prefix all the file names with something that won't be clobbered by another PCK load (like gdre_).
Resource Type
No response
Describe the problem or limitation you are having
It's currently difficult to modify the GUI because it's all written in C++.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
It would be much more intuitive if GUI elements like progress bar, PCK explorer, repacking and compilation dialogs were all editable in Godot itself if they were in
.gd+.tscnfiles and the speed-critical C++ code only connected to those through the standard means.