Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: moving visual controls from .cpp to .gd + .tscn #130

Open
UserUnknownFactor opened this issue Apr 30, 2023 · 1 comment
Open
Labels
enhancement New feature or request

Comments

@UserUnknownFactor
Copy link

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 + .tscn files and the speed-critical C++ code only connected to those through the standard means.

@UserUnknownFactor UserUnknownFactor added the enhancement New feature or request label Apr 30, 2023
@nikitalita
Copy link
Collaborator

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_).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants