-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Project properties #3667
Project properties #3667
Conversation
dabcc3e
to
e8d6bd5
Compare
9259743
to
bc6aa13
Compare
…Object in scripting doc
All other enum values have "Type" postfix, mostly to avoid conflicts with the class names in some contexts.
This is to allow the PropertiesWidget to be potentially also used in the ProjectPropertiesDialog, though I'm sure there will be some additional challenges with that.
Currently translated at 80.2% (975 of 1215 strings) Translation: Tiled/Manual Translate-URL: https://hosted.weblate.org/projects/tiled/manual/fr/
Currently translated at 82.4% (787 of 955 strings) Translation: Tiled/Reference Translate-URL: https://hosted.weblate.org/projects/tiled/reference/fr/
Currently translated at 85.8% (1043 of 1215 strings) Translation: Tiled/Manual Translate-URL: https://hosted.weblate.org/projects/tiled/manual/fr/
While we could also add a ClassProperty for the project, I'm not sure how much sense it makes right now to support setting the class of the project.
Also fixed leaking of ProjectDocument instances by the ProjectPropertiesDialog.
Need to ensure PropertiesWidget is no longer connected to the ProperyBrowser once its destructor has been called, otherwise it can crash when selectedItemsChanged is emitted.
Should be a bitflag without overlap with other flags.
* Unused parameters * Unhandled enumeration values
Rather than passing Project around by value and implementing copy/move constructor and assignment operators, the instance is now managed by std::unique_ptr and owned by ProjectDocument, which is in turn owned by ProjectModel. The ProjectDocument now owns the EditableProject, which can be used by scripts and will get invalidated as appropriate when it gets deleted, for example due to unloading the project.
Forgot to handle the nullptr here...
Thanks for the fixes. I did some testing on this version. Some example scripts: Running ProjectReadProperties.js is able to log all properties as expected Running AddProjectProperties works while Tiled is running: but then closing Tiled and reopening shows that the properties were not saved when the properties were modified via script ( I think this is where you were considering hooking into the undo stack to automatically save the project?) Deleting properties from the UI worked and persisted the deletion after restart I was also able to add properties of custom enum & class types from my existing project |
Good catch, I'll have a look into that today. Thanks for the thorough testing! |
ProjectDocument now automatically saves the project when it is changed through an undo command. To make sure the undo stack is used to make changes, some changes to the EditableProject were needed.
Your last change worked for me. I ran the script on a project with no properties and then closed Tiled without opening the Project Properties popup. When I restarted, the new properties were still there. |
Keep using "Tiled::PropertiesDock" as the context for strings that are now in the "Tiled::PropertiesWidget".
Projects now support custom properties via scripting and UI thanks to collaboration with @bjorn
Example scripts: https://gist.github.com/dogboydog/87e294ab14c17d6e2188713de9c36d15
Fix #2903